Microsoft hat im August 2025 eine Änderung angekündigt, die für Administratoren relevant ist, die Teams PowerShell in automatisierten Prozessen nutzen. Konkret betrifft es Entra ID-Apps, die ohne Benutzeranmeldung Teams-Cmdlets ausführen. Das Ziel dieser Anpassung ist klar: Die Sicherheit und die Einhaltung von Richtlinien für administrative Einheiten sollen gestärkt werden. Für Dich als Administrator bedeutet das, bestehende Service Principals zu prüfen und gegebenenfalls zusätzliche Berechtigungen zu vergeben, damit Deine Automatisierungen weiterhin funktionieren.
Hintergrund und Architektur
Die Änderung basiert auf einem neuen Authentifizierungsmodell für App-Only-Zugriffe auf Teams. Bislang reichte es aus, einer App die Teams-Administratorrolle zuzuweisen. Ab sofort müssen zwei zusätzliche Microsoft Graph-Berechtigungen vorhanden sein: RoleManagement.Read.Directory und GroupMember.Read.All. Diese sind notwendig, um die Integrität der administrativen Einheiten zu wahren und gleichzeitig Gruppenmitgliedschaften auslesen zu können.
Warum ist das wichtig? Viele Unternehmen nutzen Azure Automation oder andere Orchestrierungsplattformen, um Teams-Strukturen regelmäßig zu prüfen oder Berichte zu generieren. Diese Prozesse laufen im Hintergrund, ohne dass ein Benutzer aktiv angemeldet ist. Genau hier greift das App-Only-Modell. Ohne die neuen Berechtigungen schlagen solche Skripte künftig fehl, weil die API-Aufrufe nicht mehr autorisiert sind.
Konzept zur Umsetzung
Der erste Schritt ist die Identifikation der betroffenen Apps. Du musst herausfinden, welche Service Principals in Deinem Tenant die Teams-Administratorrolle besitzen. Diese Rolle ist ein Indikator dafür, dass die App wahrscheinlich Teams-Cmdlets in App-Only-Mode ausführt. Die Abfrage erfolgt über das Microsoft Graph PowerShell SDK. Dabei wird zunächst die Rollen-ID für „Teams Administrator“ ermittelt und anschließend alle aktiven Zuweisungen ausgelesen.
Das folgende PowerShell-Snippet zeigt den Kern der Logik:
$TeamsAdminRole = Get-MgDirectoryRoleTemplate | Where-Object {$_.displayName -eq "Teams administrator"} | Select-Object -ExpandProperty Id[array]$ActiveAssignments = Get-MgBetaRoleManagementDirectoryRoleAssignmentSchedule -Filter "(RoleDefinitionId eq '$($TeamsAdminRole)')" -ExpandProperty RoleDefinition, Principal, DirectoryScope -AllDie Ergebnisse enthalten die Service Principal IDs, die Du später für die Berechtigungszuweisung benötigst. Ergänzend kannst Du einen Bericht erzeugen, der neben der ID auch den Anzeigenamen und den App-Typ enthält. So behältst Du den Überblick, welche Automatisierungen betroffen sind.
Berechtigungen hinzufügen
Nachdem die betroffenen Apps identifiziert sind, folgt die eigentliche Anpassung. Du musst den Service Principals die beiden neuen App-Rollen des Microsoft Graph hinzufügen. Der Graph selbst ist als Service Principal mit der App-ID 00000003-0000-0000-c000-000000000000 im Tenant vorhanden. Die Zuweisung erfolgt über den Befehl New-MgServicePrincipalAppRoleAssignment.
[array]$Permissions = "RoleManagement.Read.Directory", "GroupMember.Read.All"
$GraphApp = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'"
ForEach ($App in $Apps) {
ForEach ($Permission in $Permissions) {
$Role = $GraphApp.AppRoles | Where-Object {$_.Value -eq $Permission}
$AppRoleAssignment = @{
PrincipalId = $App
ResourceId = $GraphApp.Id
AppRoleId = $Role.Id
}
Try {
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $App -BodyParameter $AppRoleAssignment -ErrorAction Stop
} Catch {
Write-Host ("Fehler beim Zuweisen von {0} an {1}" -f $Permission, $App)
}
}
}Die Logik ist bewusst robust gestaltet: Sie prüft jede Berechtigung einzeln und fängt Fehler ab, um den Prozess nicht zu unterbrechen. Damit stellst Du sicher, dass alle relevanten Apps die erforderlichen Rechte erhalten.
Sicherheitsaspekt und Governance
Die Einführung dieser zusätzlichen Berechtigungen ist kein Selbstzweck. Sie adressiert ein zentrales Problem: die unkontrollierte Ausweitung von App-Rechten. Indem Microsoft die Leserechte für Rollen und Gruppen explizit macht, wird verhindert, dass eine App mehr Informationen erhält, als für ihren Zweck notwendig ist. Für Dich bedeutet das, dass Du Deine Automatisierungen weiterhin nutzen kannst, ohne die Sicherheitsarchitektur des Tenants zu kompromittieren.
Fazit
Die Anpassung ist technisch überschaubar, aber strategisch relevant. Du stellst sicher, dass Deine Automatisierungen nicht ausfallen, indem Du die neuen Berechtigungen vergibst. Gleichzeitig profitierst Du von einer klareren Trennung der Rechte und einer verbesserten Governance. Der Aufwand ist minimal: ein einmaliger Scan der Service Principals und die Zuweisung von zwei App-Rollen. Der Nutzen hingegen ist groß, denn Du vermeidest Ausfälle in produktiven Prozessen und erfüllst die neuen Sicherheitsanforderungen von Microsoft.
Ausblick: Es ist wahrscheinlich, dass Microsoft weitere Schritte in Richtung granularer Berechtigungen für App-Only-Zugriffe geht. Für Dich als Administrator bedeutet das, dass Du Deine Skripte und Automatisierungen regelmäßig auf neue Anforderungen prüfen solltest. Eine proaktive Überwachung der Message Center-Ankündigungen und eine enge Verzahnung mit dem Microsoft Graph SDK sind dabei entscheidend. Wer hier frühzeitig reagiert, spart Zeit und vermeidet operative Risiken.
Externe Quellen
| Quelle | Thema/Bezug | URL |
|---|---|---|
| Microsoft Learn | Teams PowerShell und App-Only Authentifizierung | https://learn.microsoft.com/powershell/teams |
| Microsoft Graph Docs | AppRoleAssignments und Berechtigungen | https://learn.microsoft.com/graph/api |
| Practical365 (Tony Redmond) | Entra ID Apps und Teams Cmdlets | https://practical365.com |
| Heise.de | Microsoft 365 Sicherheitsupdates | https://www.heise.de |

