Jetzt kommt starker Tobak. Das Berechtigungsmodell in Exchange 2010 wurde komplett überarbeitet. Es bietet nun schier unbegrenzte Möglichkeiten festzulegen wer, was, wo darf. Diese ungeheuere Flexibilität, die uns Microsoft hier anbietet, fordert ihren Tribut in Sachen Verständlichkeit / Umfang. Dieser Artikel versucht das neue Modell so praxisnah wie möglich zu erläutern.
Das gesamte Konzept baut auf Rollen auf und heißt deshalb auch “Role Based Access Control (RBAC)”. Sowohl Berechtigungen für Enduser (z.B. darf der User neue Verteilerlisten erstellen) als auch Administrator Berechtigungen werden in RBAC definiert. Genau dieser Umstand sort für ein wenig Verwirrung. Wir schauen uns zuerst den Enduser an. Um einem User mehr Berechtigungen zu geben, geht man wie folgt vor:
1. Erstellen einer neuen “Role Assignment Policy”
2. Erstellen eines neuen “Management Role Assignments”
3. Die “Role Assignment Policy” wird mit der Mailbox assoziiert.
Das folgende Diagramm beschreibt den Prozess:
Schaubild 1
Wir sehen, eine Rolle (End User Management Role) besteht aus “Management Role Entries” –> (A bis E). Das sind im Grunde genommen nur Exchange Cmdlets mit den dazugehörigen Parametern. D.h. eine Rolle in RBAC besteht aus einem Set von Cmdlets, die ausgeführt werden dürfen. Genauer noch: Cmdlets und die speziellen Parameter. So könnte z.B. in einer Rolle definiert sein, dass das Cmdlet “Set-Group” ausgeführt werden kann, aber nicht z.B. der Parameter XYZ gesetzt werden darf.
Es gibt Rollen die speziell auf End-User zugeschnitten sind und so gibt es für jede Rolle ein Property namens “IsEndUserRole”, das dann ggf. auf TRUE steht. Auch im Namen sind die Enduser Roles gekennzeichnet – sie beginnen mit “My…” (get-ManagementRole my* geht auch):
Wie wir im Schaubild 1 sehen, kann man sich zu jeder Rolle auch die entsprechenden Role-Entries anzeigen lassen, per:
Get-ManagmentRole myDistributionGroups | Get-ManagementRoleEntry
Nun zu unserem Szenario: Exchange 2010 erweitert OWA um das “Exchange Control Panel (ECP)” über das der User viele Einstellungen an seiner Mailbox (und noch einiges mehr) machen kann. Per Default sieht das z.B. aus:
Auf der linken Seite sehen wir die Navigationspunkte. Genau an dieser Stelle erlaubt uns OWA 2010 auch neue Verteilerlisten zu erstellen und zu managen – wenn man die entsprechenden Rechte dazu hat. Genau diese wollen wir uns nun besorgen: Wir erstellen also per
New-RoleAssignmentPolicy meineAssignPol1
eine neue Assignment Policy. Danach müssen wir eine Rolle (z.B. MyDistributionGroups) mit der AssignmentPolicy assoziieren. Dazu erstellt man ein neues “Management Role Assignment":
New-ManagementRoleAssignment –name meinAssignment1 –Role “MyDistributionGroups” –Policy “meineAssignPol1”
Anschließend muss die AssignmentPolicy einer Mailbox zugewiesen werden:
Set-Mailbox ex10test1 –RoleAssignmentPolicy meineAssignPol1
Nachdem alles ordnungsgemäß ausgeführt wurde kommt man gar nicht mehr aufs ECP:
Das war nicht ganz unser Ziel. Was ist passiert? Jede Mailbox hat per Default eine RoleAssignmentPolicy zugewiesen. Diese beinhaltet die Rolle “MyBaseOptions”, die bestimmte Grundfunktionalitäten erlaubt. D.h. wenn man sich eine neue AssignmentPolicy erstellt, muss man dieser auch immer (zusätzlich) die Rolle “MyBaseOptions” zuweisen:
New-ManagementRoleAssignment –name meinAssignment1 –Role “MyBaseOptions” –Policy “meineAssignPol2”
Und schon haben wir wieder Zugriff aufs ECP – und nicht nur dass: nun können wir auch Gruppen managen:
So sollte man vorgehen. Durch das Erstellen von RoleAssignmentPolicies kann man mehreren Usern die gleichen Permissions geben. Man kann aber auch direkt Berechtigungen vergeben:
New-ManagementRoleAssignment “ex10test1-Voicemail” –User ex10test1 –Role “MyVoiceMail”
Dieses direkte RoleAssignment weist dem User ex10test1 die Rolle “MyVoiceMail” zu. Das ist in etwas so, wie wenn man File-Permissions auf einem File Server pro User vergibt und nicht per Security Gruppe. Irgendwann wird es un-managebar.
Administratoren und Spezial User
Im “Admin-Bereich” werden Management Role Groups erstellt, denen Rollen zugewiesen werden. Wir erstellen eine Role Group, die das Recht hat Transport Rules zu managen:
New-Rolegroup –Name “myFirstRoleGroup” –Role “Transport Rules” –Members ex10test1
Wir starten die EMC mit den Credentials von ex10test1:
Wir sehen nur den Organization Configuration Zweig und den Recipient Configuration Zweig – unter Organization Configuration ist nur “Hub Transport” zu sehen. Interessant ist auch, wie die Properties einer Usermailbox mit unseren eingeschränkten Rechten aussehen:
(man beachte die kleinen Schlösser)
Unserer neuen Rolegroup “MyFirstRoleGroup”, die Transport Rules managen darf, können wir weitere Mitglieder hinzufügen:
add-RolegroupMember “MyFirstRoleGroup” –Member ex10test2
und zusätzliche Rollen zuweisen:
New-ManagementRoleAssignment –Name “myfirstrolegroup-journaling” –SecurityGroup myfirstrolegroup –Role Journaling
Wie man sieht erfolgt das Zuweisen neuer Rollen wie im ersten Fall bei den Endusern über RoleAssignments.
Einige Rollen werden mitgeliefert:
http://technet.microsoft.com/en-us/library/dd638077.aspx
Ebenso wie einige Role Groups:
http://technet.microsoft.com/en-us/library/dd351266.aspx
Scopes
Scopes geben im RBAC an, für welchen Bereich (z.B. eine OU) die definierten Rechte gelten. Ein neuer Scope wird z.B. so erstellt:
New-ManagementScope “alleAusHeidelberg” –RecipientRestrictionFilter { City –Eq “Heidelberg” }
Wir erstellen nun wieder eine RoleGroup, aber diesmal unter Angabe es eben erstellten Scopes:
New-RoleGroup manageHeidelbergUsers –Members ex10test1 –Roles “Mail Recipients” –CustomRecipientWritescope “alleAusHeidelberg”
D.h. also, der user “ex10test1” ist nun Mitglied der RoleGroup “ManageHeidelbergUsers”, die Recipients modifizieren darf, die im “City” Feld “Heidelberg” stehen haben. Das wollen wir dann auch gleich mal überprüfen. Wir machen die EMC wieder unter den Credentials von ex10test1 auf:
Der User “ex7test1” hat ein leeres “City” Feld. Versuche ich hier per ex10test1 einen neuen ZIP Code einzutragen, bekomme ich die Meldung, dass dieses Objekt außerhalb meiner Befugnisse liegt. “Testuser1” hat Heidelberg als Stadt eingetragen, hier darf ich schreiben:
Impersoniert
So, was bedeutet das nun konkret? Wie arbeitet RBAC? Dazu schauen wir uns einmal an, was passiert, wenn per Exchange 2007 EMC eine neue Transport Rule angelegt wird. Ich habe für den entsprechenden Container im AD “auditing” eingeschaltet. Wie wir in folgendem Screenshot sehen, wurde die neue Transport Rule vom “Administrator” angelegt:
Nun, die gleiche Aktion von der Exchange 2010 EMC aus:
Wie man sieht, wird die Transport Rule hier vom Exchange Server Objekt angelgt. Exchange bzw. RBAC authorisiert mich also – es werden tatsächlich keine ACLs mehr im AD gesetzt.
Fazit
Ich könnte mir vorstellen, dass mit SP1 die GUI Version kommt und alles übersichtlicher macht. Die Tatsache, dass keine ACLs mehr geschrieben werden wird bei Migrationsscenarien weniger Ärger bringen. Die ungeheuere Flexibilität ist für größere Unternehmen sicherlich sehr gut – allerdings wird einiges an Planung nötig sein. Es lohnt sich auf jeden Fall sich mit RBAC zu beschäftigen und macht auch wirklich Spass.
Posts
