通过

Office365 Benutzerrollen

  • 项目

Während ich an dem PowerShell-Artikel für Gruppen in AAD gearbeitet hab, sind mir die Kommandos zu Rollen aufgefallen, und schon entstand ein neuer Artikel. Bitte nicht verwechseln mit dem Azure-Feature "Role Based Access Control RBAC". Dazu kommt noch ein Blogartikel. Versprochen!

Rollen kennt der ein oder andere vielleicht aus seinem Office365-Portal. Geht man dort (als Admin-User) auf Benutzer und auf Rollen, dann tauchen dort verschiedene vordefinierte Rollen auf:

  • kein Admin (ok, das ist streng genommen keine Rolle, dient nur dem Zurücksetzen)
  • Globaler Admin (darf alles)
  • Eingeschränkter Admin (darf etwas weniger)

Unter "eingeschränkter Admin" gibt's dann noch:

  • Benutzerverwaltungsadministrator
  • Dienstadministrator
  • Kennwortadministrator
  • Rechnungsadministrator
  • Exchange-Administrator
  • SharePoint-Administrator
  • Skype for Business-Administrator

Wer mehr über die einzelnen Rollen wissen möchte, der klickt im O365-Portal an der Stelle, wo diese Benutzerrollen angezeigt werden, auf den Link für weitere Informationen.

Schaut man sich die PowerShell-Cmdlets an, dann gibt es dort (natürlich) auch ein entsprechendes Feature:

get-msolRole

Das liefert auch eine Liste, die entspricht in Teilen der obigen (halt auf englisch), aber auch ein paar mehr, schließlich werden diese Benutzerrollen im AAD verwaltet, und das ist neben O365 auch noch für anders zuständig, zum Beispiel Azure ("Directory Readers" oder so...). Dass es sich in der O365-GUI und in der PowerShell (und auch im Azure Management Portal) um die gleichen Benutzer handelt, sieht man, wenn man etwas daran ändert und dann in den anderen Quellen nachsieht, zum Beispiel den Vornamen oder so.

Will man einem Benutzer eine bestimmte Rolle zuweisen, so geht das ähnlich wie bei den Gruppen am besten über die ObjectID des Benutzers und der Rolle. Wir versuchen mal, dem Benutzer "Versuch3" die Rolle des Benutzerverwaltungsadministrators (User Account Administrator) zuzuweisen. Also auf, erst mal Objekte sammeln:

$role = get-msolRole -roleName "User Account Administrator"

und

$user = get-msoluser -searchstring "Versuch3"

Und jetzt ist es eigentlich ganz einfach:

add-msolRoleMember -RoleObjectID $role.ObjectID -RoleMemberObjectID $user.ObjectID

Das war's auch schon. Der Benutzer "versuch3" darf zukünftig Benutzerkonten administrieren! Schauen wir mal nach, wer das alles sonst noch darf:

get-msolRoleMember -roleObjectId $role.objectID

Und umgekehrt, was darf der Benutzer denn sonst noch so?

get-msoluserRole -ObjectId $user.ObjectID

Das Ergebnis kann man, wie oben schon erwähnt, auch in der Verwaltung von O365 sehen (oder entsprechend im Azure Management Portal).

Jetzt ist es ja nicht so, dass in der IT jemand immer nur einen einzigen Job hat (oder gibt es so jemanden?). Meistens muss man sich ja um mehrere Dinge kümmern. Dann bekommt man quasi mehrere Rollen, und das geht hier auch. Befördern wir doch unseren Benutzer "Versuch3" mal zum "Exchange Administrator"...

add-msolRoleMember -RoleName "Exchange Service Administrator" -RoleMemberObjectID $user.ObjectID

Das war's auch schon. Man beachte, dass ich hier diesmal nicht die "RoleObjectID", sondern den "RoleName" verwendet habe. Ist eigentlich egal, Ich persönlich arbeite lieber mit den IDs, dann hätte ich halt vorher noch mit get-msolRole die ObjectId raussuchen müssen. Die Abfrage nach dem Ergebnis für den Benutzer (s.o.) liefert jetzt beide Rollen zurück, und auch die O365-Ansicht passt.

Und weil es so einfach war, machen wir den Benutzer auch gleich noch zu einem unserer "Directory Readers", einer Azure-Rolle:

add-msolRoleMember -RoleName "Directory Readers" -RoleMemberObjectID $user.ObjectID

Wir schauen kurz per PowerShell nach, 3 Rollen werden angezeigt. Prima. Wir schauen in O365 nach... Mist! Da steht jetzt was von "Die Rolle des Benutzers kann auf dieser Seite nicht bearbeitet werden". Wieso? Na, die Antwort liegt auf der Hand: Das O365-Portal kann halt nur mit O365-Rollen umgehen. Wenn ich Benutzern auch noch andere Rollen zuweise, dann muss ich halt schauen, wo ich bleibe. Und wieder einmal zeigt sich die Überlegenheit der Kommandozeile gegenüber der GUI... Den Rest der Meldung im O365-Portal sollte man übrigens nicht so für bare Münze nehmen...

Die gute Nachricht: Wenn ich den Benutzer aus der nicht-O365-Rolle wieder entferne, dann klappt's auch wieder mit der GUI:

remove-msolRoleMember -RoleName "Directory Readers" -RoleMemberObjectID $user.ObjectID

Was lernen wir daraus? Am besten die PowerShell verwenden, wann immer es geht. :-)