Teams Berechtigungen und Tasks Bug

Am 19.2.2021 habe ich durch einen Kundeneinsatz ein "besonderes Verhalten" bemerkt, das ich ihnen nicht vorenthalten möchte.

Update: Microsoft konnte beide Fehler reproduzieren, hat zwei getrennte Bug aufgemacht und nun ist es auch in der Roadmap für März 2021.

Es hat wohl etwas länger gedauert aber Mitte April 2021 sollte der Fix ausgerollt werden.

Auslöser

Wie so häufig sind es unscheinbare Probleme von Anwendern, die das bessere Verständnis fördern. Der Fall war wie folgt gelagert und sie können ihn einfach nachstellen

  • Benutzer1 legt ein neues Team an
    Er ist damit automatisch Besitzer des Teams und der dahinter liegenden Microsoft 365 Gruppe
  • Benutzer1 lädt Benutzer2 ein
    Der Benutzer2 ist ganz normales Mitglied im Teams und der Office Group

Beide Anwender können gemäß ihrer Berechtigungen fast alles machen aber eine Unstimmigkeit gibt es:

  • Benutzer1 kann keinen Planner im Teams anlegen, obwohl er "Besitzer" ist.
  • Benutzer2 kann problemlos einen Planner anlegen

Das hat natürlich meine Neugierde geweckt. Nun kann man natürlich mal schauen, wo die Tasks eines Teams liegen, denn alle andere Funktionen kann der Besitzer ja ausführen, z.B. Kanäle anlegen etc.

Where are the files kept in Planner?
Planner plans are associated with Microsoft 365 Groups, and the files for Microsoft 365 Groups are stored in an associated SharePoint document library. To find your Planner files, select the three dots to the right of the plan name (...), then choose Files.
Quelle: https://support.microsoft.com/en-us/office/answers-to-top-microsoft-planner-questions-d1a2d4e6-a4d7-408c-a48a-31caaa267de5

Die Tasks liegen also in der Office 365 Group.

Startberechtigungen

Ich habe also zuerst wieder die Schritte nachvollzogen, wie beschrieben und entsprechend sahen dann die Berechtigungen aus.

Schritt Teams Admin Portal Microsoft Teams Client

Neues Team anlegen

Zuerst habe ich je ein Teams über das Teams Admin Portal und über den Teams Client angelegt ohne weitere Mitglieder zu addieren


Mitglieder

Berechtigungen im Admin Center

Ein direkter Vergleich der Berechtigungen und Mitglieder im Teams Admin Center zeigt keine Auffälligkeiten. Die Anzeige im Client Client stimmt mit der Anzeige hier überein und beide Teams scheinen "gleich" zu sein.

Kontrolle im Office 365 Portal

Auch der erste direkte Vergleich der Gruppen im Office 365 Admin Portal zeigt keine Auffälligkeiten.

Der Text "ACL" ist fett, da ich darauf gefiltert habe.

Berechtigungen im Office 365 Admin Center

Jetzt wird es interessant, denn wenn ich mir die "Members" anschaue, dann gibt es einen sichtbaren Unterschied: Bei dem über das Admin Portal angelegten Team fehlt der Besitzer in der Mitglieder-Liste.

"Eigentlich" sollte das ja nichts ausmachen, denn ein Besitzer hat ja mehr Berechtigungen als ein Mitglied.

Exchange Admin Center

Zur Sicherheit habe ich noch mal direkt in Exchange nachgeschaut und auch hier sehen Sie das gleiche Bild.

Nur wer mit dem richtigen Werkzeug (Exchange Admin Center, Office 365 Admin Center oder Azure AD Portal) schaut, kann die Unterschiede erkennen. Im Teams Admin Panel ist diese Information nicht zu sehen.

Task anlegen

Die fehlende "Mitglieds-Rechte" des Benutzers bemerkt er eigentlich gar nicht bis er einen Task-Bereich in einem Kanal anlegen will. Dann bekommt der Besitzer, der nicht zugleich Mitglied ist, eine Fehlermeldung

"Wir konnten die Einstellungen für die Registerkarte nicht speichern. Bitte versuchen Sie es erneut"

Das Problem löst sich aber auch bei einem weiteren Versuch nicht. Hier noch mal als Bild:

Eine genauere Fehlermeldung gibt es leider nicht.

Keine Korrektur durch Anwender

Die Lösung des Problems besteht in der Korrektur der Mitgliedschaften der Office 365 Gruppe, die letzten den Unterbau von Tasks in einem Microsoft Team sind. Tasks dürfen nur von "Mitgliedern" angelegt werden. Personen, die nur Besitzer aber selbst nicht Mitglied sind, dürfen keine Tasks einrichten.

Wenn Sie nun denken, dass Sie als Besitzer des Teams dies selbst korrigieren können dann irren Sie: Solange es nur genau einen Besitzer gibt, kann sich dieser per Teams Client nicht selbst addieren und auch nicht herabstufen:

Ich kann natürlich eine andere Person zu einem weiteren Besitzer machen. Dann könnte ich mich selbst, der bislang "nur Besitzer" ist, zum Mitglied herabstufen.

STOP: Ganz schlechte Idee: Bei meinem Test konnte ich mich dann zwar selbst zum Mitglied herabstufen, aber im Ergebnis wurde ich komplett aus dem Teams entfernt!!

Es hat den Anschein, dass der Teams Client in dem Fall einfach nur den "Besitzer"-Eintrag entfernt aber nicht damit rechnet, dass die gleicher Person bei den Mitgliedern fehlt.

Ich müsste dann schon den anderen Besitzer bitten, mich wieder als Mitglied über den Teams Client hinzuzufügen.

Korrektur als Admin

Das Problem tritt ja sowieso nur auf, wenn jemand per Teams Admin Portal unter https://admin.teams.microsoft.com/teams/manage/ ein Team anlegt und hier vergisst, den Besitzer zusätzlich auch noch mal als Mitglied zu addieren. Per GUI können die den "Fehler" dann im Office 365 Admin Portal, Exchange ECP oder Azure Portal korrigieren.

Sie können die Unstimmigkeit nicht im Teams Admin Center korrigieren. Dort ist ein Benutzer entweder Benutzer oder Besitzer aber nie beides.

Wenn Sie mehr als ein paar Gruppen haben, dann bietet sich ein Report oder Massenänderungen per Powershell an. Sie können dazu die Exchange PowerShell oder die AzureAD Powershell nutzen. Hier ein Beispiel mit der Exchange Online PowerShell:

# Fix-UnifiedGroupMember
#
# Reports and fixes missing owners as members in unified groups
#
# 20210222  Initial Version

param (
   [switch]$addmember = $false
)

if (!(get-command connect-exchangeonline -ErrorAction silentlycontinue)){
   Write-Error "Please install Exchange Online Powershell first"
   break 
}
elseif (!(get-command get-unifiedgroup -ErrorAction silentlycontinue)){
   Write-host "Conneting to Exchange Online"
   Connect-ExchangeOnline
}

Write-Host "Loading Unified Groups"
foreach ($team in (get-unifiedgroup -resultsize unlimited )) {
   Write-host "Processing Group $($team.PrimarySmtpAddress)"
   $ownerlist = Get-UnifiedGroupLinks -Identity ([string]$team.PrimarySmtpAddress) -LinkType owner
   if (!$ownerlist) {
      Write-Host " No Owner found!" -foregroundcolor yellow
   }
   else {
      $memberlist = Get-UnifiedGroupLinks -Identity ([string]$team.PrimarySmtpAddress) -LinkType member
      foreach ($owner in $ownerlist) {
         Write-host "  Check Owner $($owner.PrimarySmtpAddress)" -NoNewline
         if ($memberlist.PrimarySmtpAddress -contains $owner.PrimarySmtpAddress) {
            Write-Host " is Member" -foregroundcolor green
         }
         else {
            Write-Host " No Member" -foregroundcolor yellow -NoNewline
            if ($addmember) {
               Write-Host " Adding Owner as Member"
               Add-UnifiedGroupLinks `
                  -Identity ([string]$team.PrimarySmtpAddress) `
                  -LinkType member `
                  -Links ([string]$owner.PrimarySmtpAddress)
            }
            else {
               Write-Host " ReportOnly"
            }
         }
      }
   }
}

Das Skript ist so ausgelegt, dass es ohne Parameter nur einen Bericht auf den Bildschim gibt. Erst mit dem Parameter "-addmember" werden alle fehlenden Besitzer auch als Mitglied addiert.

Analog können Sie das Skript natürlich auch mit der AzureAD-Powershell umsetzen.

Richtiges Provisioning

Ich war schon etwas überrascht, dass so ein Fehlverhalten nicht schon früher erkannt und prinzipiell behoben wurde. Wenn ich eine Office 365 Gruppe über den Teams Client anlege, dann werden im Hintergrund durchaus die Berechtigungen richtig vergeben. Auch die Anlage einer Microsoft 365 Gruppe über das Exchange Admin Center funktioniert.

Ich habe dann noch mal ein Test per Exchange PowerShell gemacht. Damit lege ich zwar erst einmal kein Microsoft Team sondern "nur" eine Microsoft 365 Gruppe an, aber das Ergebnis ist korrekt

PS C:\> New-UnifiedGroup ACLTestPS1 -DisplayName  ACLTestPS1

Name                                            DisplayName GroupType PrimarySmtpAddress
----                                            ----------- --------- ------------------
ACLTestPS1_b147653a-ced3-474c-a15e-fe6e00f5acf2 ACLTestPS1  Universal ACLTestPS1@msxfaq.net


PS C:\> Get-UnifiedGroupLinks -Identity ACLTestPS1 -LinkType owner

Name  RecipientType
----  -------------
admin UserMailbox


PS C:\> Get-UnifiedGroupLinks -Identity ACLTestPS1 -LinkType member

Name  RecipientType
----  -------------
admin UserMailbox

Dann habe ich noch direkt ein Team frisch über die Teams-PowerShell angelegt:

PS C:\>Connect-MicrosoftTeams

PS C:\> New-Team -DisplayName ACLTeamPS

GroupId DisplayName Visibility Archived MailNickName Description
------- ----------- ---------- -------- ------------ -----------
96798419-cdb4-4dc6-abe4-d98b58b54bd8 ACLTeamPS Private False msteams_21985c ACLTeamPS

PS C:\> Get-UnifiedGroupLinks -Identity ACLTeamPS -LinkType owner

Name  RecipientType
----  -------------
admin UserMailbox


PS C:\> Get-UnifiedGroupLinks -Identity ACLTeamPS -LinkType member

Name  RecipientType
----  -------------
admin UserMailbox

Auch hier ist zu sehen, dass der ausführende Benutzer sowohl als Besitzer als auch als Mitglied addiert wird.

Zwischenstand

Nach allen Analysen ist das für mich ein Fehler im Teams Admin Center, den Sie aber einfach umgehen können. Sie können über drei andere Weboberflächen und zwei PowerShell-Umgebungen Gruppen und Teams anlegen, die alle korrekt provisioniert sind. Nur die Anlage eines Teams über das Team Admin Center macht dies erst einmal "falsch" und sie können es im Teams Admin Center auch nicht korrigieren.

Da kann man dann nur hoffen, dass der Administrator bei der Anlage von Teams über das Admin Portal den Besitzer auch noch als Mitglied addiert. Dass aber ein Benutzer, der so nur zum Besitzer geworden ist, beim Herabstufen durch einen anderen Besitzer aus dem Teams entfernt wird, ist unerwartet. Ich habe das Verhalten an Microsoft gemeldet und es wurden in wenigen Stunden zwei Bugs zur Nachverfolgung generiert:

  • Bug1: "Demoted owner dropped from team, since was they were never a member"
  • Bug2 "Teams creating in Admin Portal and Planner"

An der Lösung wird schon gearbeitet und es gibt auch schon einen Eintrag in der Roadmap mit Zieldatum März 2021

Ich bin mal gespannt, wann es dann ankommt und vor allem wie die Lösung umgesetzt wird. Wird jeder Owner zusätzlich als Member addiert oder bekommt Planner ein Update, dass Owner auch die Rechte bekommen. Das würde dann aber nicht das Prolem lösen, dass ein Besitzer beim Ändern zum Member aus dem Teams geworfen wird.

Weitere Links