ADMIN
2021
05
2021-05-01T12:00:00
Hybrid Cloud
SCHWERPUNKT
098
Hybrid Cloud
Cloud
PowerShell für Microsoft 365
Generalschlüssel für die Cloud
von Florian Frommherz
Veröffentlicht in Ausgabe 05/2021 - SCHWERPUNKT
Kommen verschiedene Komponenten von Microsoft 365 im Unternehmen zum Einsatz, muss sich der Admin mit unterschiedlichen Portalen abmühen, um Dienste wie Teams, SharePoint oder Exchange zu verwalten. Deutlich einfacher wird die Administration mit einem Arsenal an Skripten und den passenden PowerShell-Modulen. So lassen sich viele wiederkehrende Tätigkeiten bequem aus einer Kommandozeile steuern.
Viele Unternehmen nutzen Microsoft Teams, wenn es um Unternehmenskollaboration geht. Das System setzt auf Microsoft-365-(M365)-Gruppen, um in Exchange, SharePoint und sich selbst Berechtigungen zu vergeben und in Letzterem auch Funktionen zu steuern. Die M365-Gruppen sind dabei in Azure AD hinterlegt und werden dort verwaltet – inklusive der Mitgliedschaften für interne sowie externe Benutzer. Daher wollen wir mit den Gruppen starten.
Microsoft-365-Gruppen steuern
Sie erstellen eine neue M365-Gruppe, die dann als Team dient, auf unterschiedlichen Wegen. Entweder gehen Sie über die Exchange-PowerShell via:
Connect-ExchangeOnline -userPrincipalName <Benutzer@Beispiel.com>
New-UnifiedGroup
-DisplayName "<Gruppenname>"
-Alias "<Alias der Gruppe>"
-Owner <Benutzer@Beispiel.com>
Oder Sie nutzen die Azure-AD-PowerShell-Module:
Viele Unternehmen nutzen Microsoft Teams, wenn es um Unternehmenskollaboration geht. Das System setzt auf Microsoft-365-(M365)-Gruppen, um in Exchange, SharePoint und sich selbst Berechtigungen zu vergeben und in Letzterem auch Funktionen zu steuern. Die M365-Gruppen sind dabei in Azure AD hinterlegt und werden dort verwaltet – inklusive der Mitgliedschaften für interne sowie externe Benutzer. Daher wollen wir mit den Gruppen starten.
Microsoft-365-Gruppen steuern
Sie erstellen eine neue M365-Gruppe, die dann als Team dient, auf unterschiedlichen Wegen. Entweder gehen Sie über die Exchange-PowerShell via:
Connect-ExchangeOnline -userPrincipalName <Benutzer@Beispiel.com>
New-UnifiedGroup
-DisplayName "<Gruppenname>"
-Alias "<Alias der Gruppe>"
-Owner <Benutzer@Beispiel.com>
Oder Sie nutzen die Azure-AD-PowerShell-Module:
Connect-AzureAD
New-AzureADMSGroup -DisplayName "<Gruppenname>" -MailNickname "<Alias der Gruppe>" -GroupTypes "Unified" -MailEnabled $true -SecurityEnabled $true
Der Gruppentyp "Unified” kennzeichnet die M365-Gruppen, die neben der Berechtigungsvergabe und dem Mailing auch für Teams und Yammer zum Einsatz kommen. Die Azure-AD-PowerShell unterscheidet zwischen den Cmdlets "New-AzureADGroup" und "New-AzureADMSGroup" für traditionelle beziehungsweise M365-Gruppen.
Haben Sie die Exchange-Online-PowerShell-Cmdlets nicht installiert, erledigen Sie dies in einer PowerShell-Sitzung als Administrator mit Install-Module ExchangeOnlineManagement
. Danach importieren Sie das Modul als normaler Benutzer via Import-Module Exchange-OnlineManagement
.
Einen Unterschied zwischen dem Exchange- und dem Azure-AD-Weg der Gruppenerstellung sollten Sie kennen: Nehmen Sie die Exchange-Route, erstellen Sie eine zugehörige Mailbox für die Gruppe direkt, während Sie via Azure AD (AAD) zunächst das Anlegen im Directory und danach die Mailboxerstellung einleiten, nachdem AAD und Exchange synchronisiert sind.
Um beispielsweise für eine neue Vertriebsaktion Kollegen aus einer anderen Kampagne, die bereits Mitglied eines Teams sind, einfach zu übernehmen und als Mitglieder des neuen Teams hinzuzufügen, nutzen Sie:
Get-AzureADGroupMember -ObjectId e45712da-4a52-422c-94c3-b158d366945a | % { Add-AzureADGroupMember -ObjectID 378f9975-143d-418d-b735-96ab403e75f9 -RefObjectId $_.ObjectId }
Dieser Befehl liest zunächst die Mitglieder der alten Kampagne und schreibt sie dann in das neue Team (identifiziert durch die ObjectID). In der Foreach-Schleife (beginnt mit "%") wird jedes Mitglied betrachtet und als RefObjectID übergeben.
Besonders wichtig in Teams sind Gruppenbesitzer (Owner), die im Lebenszyklus traditioneller Gruppen etwa aus dem Windows-AD keine zentrale Rolle spielen. Die Besitzer können das Team nämlich in Teams im Detail konfigurieren und sind Ansprechpartner bei Reviews von Mitgliedern:
Add-AzureADGroupOwner -ObjectId 7615d111-e04b-493a-9992-dca9493828fd -RefObjectId (Get-AzureADUser -SearchString <Benutzer@Beispiel.com>).ObjectId
Get-AzureADGroupOwner -ObjectId 7615d111-e04b-493a-9992-dca9493828fd
Gruppen, die weniger als einen Besitzer aufweisen, sollten Sie genauer betrachten – und weitere Besitzer finden und definieren:
Get-AzureADMSGroup -Filter "groupTypes/any(c:c eq 'Unified')" -All:$true | ? { (Get-AzureADGroupOwner -ObjectId $_.Id).Count -lt 1 } | Export-CSV C:\temp\missing-owners.csv
Gastzugang zum Tenant verwalten
Bevor Sie aber viele Teams und Gruppen anlegen, sollten Sie sich mit den Tenant-Einstellungen vertraut machen. Der Gastzugang für Externe ist in Microsoft Teams mittlerweile als Grundkonfiguration erlaubt. Wenn Sie M365-Gruppen oder Teams für Externe unzugänglich machen wollen, erledigen Sie das über eine AAD-Einstellung, die sie einmalig als "Template" kopieren und dann auf die Gruppen anwenden. Das geht auch umgekehrt, wenn Sie per Tenant-Einstellung den Gastzugriff verbieten, aber einzelnen Teams externe Mitglieder erlauben wollen:
$template = Get-AzureADDirectorySettingTemplate | ? {$_.displayname -eq "group.unified.guest"}
$preventGuests = $template.CreateDirectorySetting()
$preventGuests["AllowToAddGuests"]=$false
Anschließend wenden Sie das Setting auf die Gruppen an, die keine externen Mitglieder mehr umfassen sollen:
Get-AzureADMSGroup -Filter "groupTypes/any(c:c eq 'Unified')" -All:$true | ? {$_.displayName -like "<Finanzen*>" } | % {New-AzureADObjectSetting -TargetType Groups -TargetObjectId $_.Id -DirectorySetting $preventGuests }
Der Befehl sucht zunächst alle M365-Gruppen mit dem Präfix "Finanzen" und wendet dann die Einstellungen an.
Gruppen über Label steuern
Etwas eleganter und besser automatisiert geht es mit "Labels" aus dem Security-und-Compliance-Center. Diese Labels sind an vielerlei Orten in der Microsoft Cloud einsetzbar und dienen nicht nur der Verschlüsselung von E-Mails, sondern auch der Klassifizierung und zur Einschränkung von Mitgliedschaften in Teams. Damit die Labels im Azure AD für Gruppen zum Einsatz kommen können, müssen Sie die Labels zunächst einschalten:
$template = Get-AzureADDirectorySettingTemplate | ? {$_.displayname -eq "group.unified"}
$copy = $template.CreateDirectorySetting()
$copy["EnableMIPLabels"] = $true
New-AzureADDirectorySetting -DirectorySetting $copy
Anschließend erstellen Sie ein neues Label mit dem entsprechenden Cmdlet aus den Exchange-Online-PowerShell-Modulen. Die Kommandos müssen sich aber zunächst mit dem Information-Protection-(IP)-Endpoint verbinden:
Connect-IPPSSession -UserPrincipalName <compliance-admin@frickelsoftnet.onmicrosoft.com>
Sie nehmen hier die Rolle eines Compliance-Admins ein und definieren ein neues Label:
New-Label -DisplayName "FSFTTopSecret" -Name "<Frickelsoft streng geheim>" -Tooltip "<Dies ist eine vertrauliche Datei>" -LabelActions '{"Type":"protectgroup","SubType":null,"Settings":[{"Key":"privacy","Value":"private"},{"Key":"allowemailfromguestusers","Value":"false"},{"Key":"allowaccesstoguestusers","Value":"false"},{"Key":"disabled","Value":"false"}]}'
Das Kommando setzt sich aus zwei Teilen zusammen: zunächst dem eigentlichen Erstellen des Labels, dann dem Teil der Zusatzinformationen in "LabelActions", die die Regeln des Labels zu Gruppenmitgliedschaften und die Erlaubnis für externe Gäste definieren. In unserem Beispiel dürfen Gruppen, die wir mit dem Label klassifizieren, nur mit Erlaubnis des Besitzers betreten werden ("privacy: private") und externe Mitglieder sind nicht gestattet ("allowaccesstoguestusers: false"). Für das Deployment packen Sie das Label (in der Praxis oft gemeinsam mit anderen Labels) in eine Label-Policy:
New-LabelPolicy -Name "<Name der Richtlinie>" -Labels "<Geheime Dateien>"
Die Synchronisation von Exchange und dem Compliance-Center nach Azure AD stoßen Sie dann wie folgt an:
Execute-AzureADLabelSync
Die Label sollte nach einigen Minuten im Azure AD angekommen sein.
Es wird Zeit, eines der Label endlich an eine bestehende oder neue M365-Gruppe zu heften. Für die Verbindung von Label und Team brauchen Sie die eindeutige ID des Labels. Den Überblick über alle Labels und deren "immutableID" erhalten Sie mit der PowerShell:
Get-Label | ft ImmutableID, Name
Die über den Befehl ausgegebene Tabelle liefert die Zuordnung der IDs zu den Label-Namen. Die ID des richtigen Labels nutzen Sie dann mit dem Property "LabelID", wenn Sie das Team neu erstellen oder modifizieren:
New-AzureADMSGroup -DisplayName "<Gruppenname>" -MailNickname "<Alias der Gruppe>" -GroupTypes "Unified" -MailEnabled $true -SecurityEnabled $true -LabelId f460a5b0-8d8e-4ac1-bb92-afb9ea22f9da
Sind Sie den Schritten gefolgt und haben die "LabelActions" gemäß unserem Beispiel erstellt, sollte das nun mit einem Label versehene Team keine neuen Mitglieder von anderen Tenants mehr akzeptieren.
Langfristige Gruppenverwaltung
Um AAD-Gruppen langfristig valide zu verwalten, lohnt sich eine Lifecycle-Policy, die dann alle oder ausgewählte Gruppen unterstützt. Im folgenden Beispiel sollen die ausgewählten Gruppen nach 180 Tagen erneuert werden müssen. Gruppen, die keine Owner haben, werden an die Benachrichtigungs-E-Mail gemeldet:
New-AzureADMSGroupLifecyclePolicy -GroupLifetimeInDays 180 -ManagedGroupTypes "Selected" -AlternateNotificationEmails "<Benutzer@Beispiel.com>"
Alternativ können Sie auch "None" oder "All" für "ManagedGroupTypes" angeben. Dann werden keine oder alle M365-Gruppen dem Lifecycle unterzogen. Zurückgegeben wird die Policy-ID, die Sie dann an Gruppenobjekte anheften können:
Get-AzureADMSGroup -SearchString "Project" | % { Add-AzureADMSLifecyclePolicyGroup -Id 5d69168d-b3e4-410a-b0a5-c729703ebc86 -GroupID $_.Id }
SharePoint inspizieren
Microsoft Teams nutzt für die Speicherung der abgelegten Daten im Hintergrund SharePoint. Es erlaubt den sicheren Zugriff auf alle Dokumente und Ressourcen für die Kollaboration. Natürlich kommt SharePoint Online vielerorts auch ohne Teams zum Einsatz – entweder als Team- und Kollaborationsplattform oder als persönlicher Datenspeicher via OneDrive. Eine Inventarisierung starten Sie mit dem SharePoint-PowerShell-Modulen [1] und verbinden sich via:
Connect-SPOService -Url <https://frickelsoftnet-admin.SharePoint.com>
Eine Übersicht der Sites erhalten Sie mit Get-SPOSite -Limit all
. Sie sehen dann neben den URLs auch den genutzten Speicher und – wo verfügbar – die Besitzer der Sites. Sie werden feststellen, dass sich nicht für alle Sites Besitzer finden. Genauer betrachtet, ist das Feld "Owner" aber in den Details aufgeführt:
Get-SPOSite -Identity <https://frickelsoftnet.SharePoint.com/sites/Projekt> | fl
Das Owner-Feld trägt eine GUID, die auf einen Benutzer oder Gruppe hinweist, hat aber einen besonderen Suffix: "_o". Bei genauerer Betrachtung existiert das Phänomen bei allen Sites, die aus M365-Gruppen oder Teams entstanden sind. Schneiden wir den Suffix ab und fragen das AAD nach einer Gruppe mit der resultierenden, korrekten GUID, findet sich der Gruppenname:
Get-SPOSite -Identity <https://frickelsoftnet.SharePoint.com/sites/Projekt> | SELECT Owner | % { Get-AzureADGroup -ObjectID ($_.Owner).TrimEnd("_o") }
Damit lässt sich schnell ein Befehl für alle Sites bauen. Die M365- und Teams-Sites erkennen Sie daran, dass sie aus einem SharePoint-Template resultieren, das "Group*" im Namen trägt:
Get-SPOSite -Limit all | % { if($_.Template -like '<GROUP*>') { $owner = Get-SPOSite -Identity $_.URL | SELECT -ExpandProperty Owner; $owner = (Get-AzureADGroup -objectID $owner.TrimEnd("_o")). displayName } else { $owner = $_.Owner} Write-Host $_.URL $owner }
Alternativ lässt sich die Gruppe, die dem Team und damit Microsoft SharePoint zugrundeliegt, auch im Attribut "GroupID" in den Details der SPO-Site auslesen – ohne das Suffix.
Mit wem Zusammenarbeit erlaubt ist, bestimmen Sie entweder auf Tenant- oder auf Site-Ebene. Die Tenant-Einstellung beschreibt das Attribut "SharingCapability":
Get-SPOTenant | SELECT SharingCapability
Die möglichen Werte sind "Disabled" für ausgeschaltetes externes Sharing und rein interne Nutzung sowie "ExistingExternal-UserSharingOnly" für die Kollaboration mit existierenden Gästen und "External-UserAndGuestSharing" für existierende sowie neue Gäste, die per SharePoint-E-Mail-OTP eingebunden werden. Die Sharing-Einstellungen für Sites können von der Tenant-Einstellung abweichen, weshalb sich ein Blick in die Site lohnt:
Get-SPOSite -Identity <https://frickelsoftnet.SharePoint.com/sites/Projekt> -Detailed | SELECT SharingCapability
Besonders die Einstellung "ExternalUserAndGuestSharing" bindet Partner und Lieferanten außerhalb der eigenen Organisation mit einem E-Mail-One-Time-Passcode ein, der per E-Mail zum Nutzer gelangt. Für den Externen legen Sie dann ein SharePoint-Konto an. Nutzen Sie ein verwaltetes Azure AD und möchten das Erstellen von SharePoint-eigenen Accounts unterbinden, können Sie den SharePoint-Tenant per PowerShell dazu zwingen, Azure-AD-B2B-Einladungen zu verschicken – notfalls auch per E-Mail-OTP:
Set-SPOTenant -EnableAzureADB2BIntegration $true
Set-SPOTenant -SyncAadB2BManagementPolicy $true
Set-SPOTenant -CustomizedExternalSharingServiceUrl <https://sharing.frickelsoft.net/external-access>
Die Funktion ist bei Microsoft noch in den finalen Entwicklungszügen, findet sich aber bereits in der "Public Preview". Mit der Aktivierung bestehen keine Unterschiede der externen Accounts zwischen Azure AD und SharePoint mehr und die SharePoint-eigene OTP-Lösung ist damit hinfällig.
Aktivitäten mitschreiben
Die passenden Lizenzen vorausgesetzt, können Sie mit dem Compliance-Center in M365 Alarme generieren, wenn Dinge in Ihrem Tenant geschehen, die Sie entweder nicht möchten oder zumindest genauer im Blick halten wollen. Diese Alerts sind so aufgebaut, dass Sie definieren, bei welcher Aktion der Alarm ausgelöst wird und wer eine Benachrichtigung erhält. Sie können den Alarm auch nur dann ausführen lassen, wenn jemand Bestimmtes die Aktion tätigt. Einen Überblick über existierende Alarme gibt Ihnen:
Get-ActivityAlert | ft Description,Name
Ein einfaches Beispiel wäre, wenn ein Anwender eine SharePoint-Seite oder -Datei mit einem Externen teilt. Wenn Sie genauer hinsehen möchten, wenn User Jenny eine neue Einladung generiert, legen Sie den Alarm so an:
New-ActivityAlert -Name "<Externer Sharing-Alert>" -Operation sharinginvitationcreated -NotifyUser <alarms_m365@frickelsoft.net>, <florian@frickelsoft.net> -UserId <jenny@frickelsoft.net> -Description "<Erzeugt einen Alarm, wenn Jenny eine Sharing-Einladung erzeugt."
Sind Sie daran interessiert zu erfahren, wenn ein Nutzer Sarah ein Team löscht, nutzen Sie folgenden neuen Alert:
New-ActivityAlert -Name "Team deletion Alert" -Operation teamdeleted -NotifyUser <alarms_m365@frickelsoft.net>, <florian@frickelsoft.net> -UserId sarah@frickelsoft.net -Description "<Löscht Sarah eine M365-Gruppe oder -Team, erfolgt ein Alarm.>"
Die E-Mail, die dann in Ihrem Postfach landet, verweist auf das Compliance-Admin-Center, über das Sie weitere Nachforschungen anstellen können.
Das AAD-Log beinhaltet die Gruppenänderungen ebenfalls und das AAD-Preview-Modul (eingerichtet per Import-Module AzureADPreview
) lässt Sie darin spezifisch suchen:
Get-AzureADAuditDirectoryLogs -Filter "initiatedBy/user/userPrincipalName eq <Benutzer@ Beispiel.com>' and ActivityDisplayName eq 'Delete group'"
Sind Sie dann an den letzten Änderungen der Gruppe interessiert, bevor sie gelöscht wurde, können Sie das vorherige Kommando erweitern und die Objekt-ID der Gruppe extrahieren. Sie fügen einfach "| SELECT -ExpandProperty TargetResources | SELECT ID" an. Diese Objekt-ID (im Beispiel "1c9c09d7-4b3c-4f37-b2cf-e3b8ad0a2ecf") können Sie dann in der Suche nach Audit-Einträgen wie folgt einsetzen:
Get-AzureADAuditDirectoryLogs -Filter "targetResources/any (tr:tr/id eq '1c9c09d7-4b3c-4f37-b2cf-e3b8ad0a2ecf')" | ft ActivityDisplayName, ActivityDateTime
Soweit das Auditlog reicht (in Azure-AD-Premium Tenants 30 Tage zurück), sehen Sie dann einen Verlauf von Änderungen, die die Gruppe erfahren hat: von dem Erstellen über neue Owner sowie neue Mitglieder und Updates zu den Attributen bis hin zur Löschung.
Fazit
Wir haben uns ein wenig in Microsoft 365 umgesehen und mit M365-Gruppen, Teams und externen Mitgliedern sowie Vertraulichkeitslabels gearbeitet. Um M365 im Griff zu haben, kommen Sie um die PowerShell nicht herum. Nur gibt es leider kein allumfassendes "PowerShell-Master-Modul", das die wichtigsten Funktionen umfasst.
So sind Administratoren weiterhin auf die Module von AzureAD, Azure-ADPreview, Exchange-Online-Management, SharePoint Online, Microsoft Teams und so weiter angewiesen. Es lohnt sich daher immer, ein Skript-Repository in einer guten Entwicklungsumgebung wie Visual Studio Code oder einen cleveren Texteditor wie Notepad++ anzulegen.
(jp)