RBAC - Role Based Access Control

Bislang hatten Exchange Administratoren immer die Wahl zwischen Teufel und Weihwasser. Während bei Exchange 5.5 die Administration über die Exchange DIR.EDB gesteuert wurde, waren in Exchange 2000/2003 die administrativen Gruppen, der Server und natürlich die OUs der Empfänger relevant und ein Stück weit die Zugriffrechte auf die Systemaufsicht zur Überprüfung von Mailadressen. Exchange 2007 hat auf die administrativen Gruppen verzichtet und über die Gruppe "Exchange Recipient Operatoren" dem Administrator in der Regel weitreichende Berechtigungen im Bezug auf die Exchange Eigenschaften gegeben. Aber alle Tätigkeiten wurden vom Administrator mit seinen individuellen Berechtigungen ausgeführt. Wer sein normales Konto daher zum Administrator gemacht hat, hat irgendwann auch Kontakt mit den Eigenheiten des AdminSDHolder gemacht.

Mit Exchange 2007 wurde die PowerShell erstmals strategisch genutzt. Der Einsatz einer lokalen grafischen Verwaltung, die ihrerseits die PowerShell-Funktionen aufruft oder auch direkte PowerShell-Kommandos funktionieren aber nur einfach, so lange der ausführende Benutzer auf dem Computer im gleichen Forest der Exchange Organisation ist. Die Befehle wurden immer auf dem PC mit den Rechten des Benutzers ausgeführt, d.h. die Commandlets haben letztlich per LDAP, WMI etc. die Einstellungen durchgeführt. Dies sind natürlich denkbar schlechte Startvoraussetzungen für den Betrieb von Exchange in der "Cloud".

Das wird mit Exchange 2010 komplett anders. Dank der Möglichkeiten mit PowerShell 2.0 ist es sehr einfach, Befehle "remote" ausführen zu lassen. Der Administrator kann auf einer beliebigen Workstation daher die entsprechenden Commandlets starten, welche tatsächlich aber auf einem anderen Server ausgeführt werden können.

Der dort aktive Prozess kann aber mit Wissen um den Benutzer eine eigene Konfiguration nutzen, um nur für diesen Benutzer zugelassene Commandlets mit den ausgewählten Parametern zuzulassen. Und genau diesen Weg geht Exchange 2010. Über Managementrollen wird festgelegt, welcher Benutzer oder Gruppe die Befehle ausführen darf. Allerdings geht es von Hause aus nicht bis auf die Werte der Parameter herunter, d.h. wenn jemand die Quotas und Datenbanken beim Anlegen eines Benutzers (SET-MAILBOX) verwenden darf, dann kann über das Berechtigungsmodell keine Validierung der Parameter erfolgen.

Aus meiner Sicht ist PowerShell ein wichtiger und richtige Weg, zukünftig Windowsprogramme und Dienste zu steuern. Und die Trennung von Ausführung und Beauftragung kann ich nur unterstützen.

Die Grundlagen

Die Zusammenhänge von RBAC sind mehrstufig und bestehen aus folgenden Komponenten

  • Administrativer Benutzer
    Wer "administriert", muss sich mit einem entsprechenden Konto am Active Directory anmelden. Insofern ist die Existenz mindestens eines Benutzers zwingend. Es ist ratsam, wenn sich nicht ihren normalen täglichen Account verwenden, mit dem Sie auch im Internet Recherchieren, Dokumente schreiben und Mails beantworten. (Siehe Adminkonzept)
  • Benutzergruppe
    Auch wenn man eine Funktion nur an genau einen Benutzer zuweisen möchte, sollten Sie immer über Windows Sicherheitsgruppen gehen, um Berechtigungen zu verwalten. Als benötigen Sie für die Gruppierung von Benutzern eine entsprechende Gruppe
  • Rollen
    Auf der anderen Seiten werden "Rollen" definiert, welche jede für sich eine Sammlung von PowerShell-Befehle darstellt.
  • Rollenzuweisungen als Bindeglied
    Zuletzt fehlt noch ein Objekt, welches die Gruppen auf der einen Seite zu den Rollen der anderen Seite verbindet. Das sind dann die "Role Assignments."

Oder das ganze als Bild

Auf dem Bild sehen Sie aber auch, dass die Rollenzuweisung (Role Asignment) nur genau ein Feld hat, welches auf eine Gruppe und auf eine Rolle verweist. Da es aber problemlos möglich ist, auch mehrere Rollenzuweisungen anzulegen, kann man problemlos einer Gruppe auch mehrere Rollen zuweisen. Und dann Benutzer in mehreren Gruppen enthalten sein können, versteht sich von selbst. Insofern ist die Zuweisung recht flexibel.

Role-based access control
http://www.microsoft.com/exchange/2010/en/us/management-tools.aspx

Konfiguration der Rollen

Seit Exchange 2010 gibt es in der Toolbox eine grafische Möglichkeit die Rollen und Rollenzuweisungen zu verwalten.

Seien Sie aber nicht überrascht, wenn Sie keine MMC sehen sondern per Browser auf das Exchange Control Panel auf die Adresse https://servername.domain.tld/ecp/default.aspx?p=AdminRoleGroups&exsvURL=1 geleitet werden.

Hier können Sie über den Einstieg der Rollengruppen bestimmen, welche Rollen auf Welchen Scope diese Gruppe ausführen darf. Die Mitglieder der Gruppe werden wieder wie gehabt verwaltet.

Tipp:
Prüfen Sie, ob nicht eine der vielen bereits vorhandenen Gruppen und Rollen für ihre Anforderungen ausreichend ist. Es ist relativ problemlos, weitere Gruppen anzulegen und über die Rollenzuweisung auf einen Scope und eine Rolle zu beschränken. Das Einrichten weiterer Rollen sollte erst nach einer gründlichen Planung erfolgen. Vor allem sollten Sie die Standardrollen und Gruppen nicht ändern (abgesehen vom Addieren von Mitgliedern) und bei der Einrichtung neuer Rollen immer auch das passende "GET-Commandlet" addieren.

Sie haben auch immer noch die Möglichkeit, per PowerShell die entsprechenden Befehle durchzuführen..

Gruppen

Zuerst bietet sich die Verwaltung der Gruppen an, welche für die Delegierung von Rollen später verwendet werden.

[PS] C:\>Get-RoleGroup

Name                          AssignedRoles                 RoleAssignments               ManagedBy
----                          -------------                 ---------------               ---------
Organization Management       {Active Directory Permissi... {Active Directory Permissi... {E2010.local/Microsoft Exc...
Public Folder Management      {Mail Enabled Public Folde... {Mail Enabled Public Folde... {E2010.local/Microsoft Exc...
Recipient Management          {Distribution Groups, Mail... {Distribution Groups-Recip... {E2010.local/Microsoft Exc...
View-Only Organization Man... {Monitoring, View-Only Con... {Monitoring-View-Only Orga... {E2010.local/Microsoft Exc... UM Management                 {UM Mailboxes, UM Prompts,... {UM Mailboxes-UM Managemen... {E2010.local/Microsoft Exc...
Help Desk                     {User Options, View-Only R... {User Options-Help Desk, V... {E2010.local/Microsoft Exc...
Records Management            {Audit Logs, Journaling, M... {Audit Logs-Records Manage... {E2010.local/Microsoft Exc...
Discovery Management          {Legal Hold, Mailbox Search}  {Legal Hold-Discovery Mana... {E2010.local/Microsoft Exc...
Server Management             {Database Copies, Database... {Database Copies-Server Ma... {E2010.local/Microsoft Exc...
Delegated Setup               {View-Only Configuration}     {View-Only Configuration-D... {E2010.local/Microsoft Exc...
Hygiene Management            {ApplicationImpersonation,... {ApplicationImpersonation-... {E2010.local/Microsoft Exc...
...

Die Mitglieder eine Gruppe kann man sich mit "Get-RoleGroupMember" anzeigen lassen und mit Add-RoleGroupMember und Remove-RoleGroupMember verändern. Da es sich dabei aber einfach um Gruppen im Active Directory handelt, können Sie auch die gewohnten Werkzeuge dafür verwenden.

Wer später die Anwendung bestimmter Berechtigungen auf OUs beschränken will, muss diese Scopes erst anlegen

Get-ManagementScope

New-ManagementScope -name "VIP users" -RecipientRestrictionFilter {memberofgroup -eq "cn=VIPs,ou=VIP,dc=domain,dc=com"} 

Normalerweise gibt es keine vordefinierte Scopes.

Die Rollen selbst sind dann wieder vordefiniert (gekürzt)

[PS] C:\>Get-ManagementRole
Creating a new session für implicit remoting of "Get-ManagementRole" command...

Name                                             RoleType
----                                             --------
Recipient Policies                               RecipientPolicies
Active Directory Permissions                     ActiveDirectoryPermissions
Address Lists                                    AddressLists
Audit Logs                                       AuditLogs
....

Schaut man sich eine Rolle dann mal genauer an, sieht man auch die damit verknüpften Commandlets (gekürzt)

[PS] C:\>Get-ManagementRole myname | fl


RunspaceId                  : 1b3ac201-9643-4207-a586-95643c21d3a8
RoleEntries                 : {(Microsoft.Exchange.Management.PowerShell.E2010) Set-User -FirstName -Identity -Initials
                               -LastName -Notes, (Microsoft.Exchange.Management.PowerShell.E2010) Get-Mailbox -Identity
                              }
RoleType                    : MyProfileInformation
ImplicitRecipientReadScope  : Self
ImplicitRecipientWriteScope : Self
ImplicitConfigReadScope     : OrganizationConfig
ImplicitConfigWriteScope    : OrganizationConfig
IsRootRole                  : False
IsEndUserRole               : True
MailboxPlanIndex            :
Description                 : This role enables individual users to view and modify their full name and their notes fie
                              ld. This is a custom role created from the "MyProfileInformation" parent role.
IsDeprecated                : False
...

Oder gleich nur die Role Entries

[PS] C:\>(Get-ManagementRole myname).roleentries

PSSnapinName                            Name                                    Parameters
------------                            ----                                    ----------
Microsoft.Exchange.Management.PowerS... Set-User                                {FirstName, Identity, Initials, Last...
Microsoft.Exchange.Management.PowerS... Get-Mailbox                             {Identity}

Wobei die Einträge selbst wieder eigene Objekte sind, die mit Commandlets erstellt, verändert und angezeigt werden können:

Get-ManagementRoleEntry "Mail Recipients\*" 

Add-ManagementRoleEntry "VIP Editor\Set-User" -Parameters Office,Phone,Mobilephone,Department,Manager

Die Zuweisung erfolgt dann über die RoleAssignments, von denen es schon bei der Standardinstallation 163 Einträge gibt

[PS] C:\>Get-ManagementRoleAssignment

Name                           Role              RoleAssigneeName  RoleAssigneeType  AssignmentMethod  EffectiveUserNam
                                                                                                       e
----                           ----              ----------------  ----------------  ----------------  ----------------
View-Only Configuration-Del... View-Only Conf... Delegated Setup   RoleGroup         Direct            All Group Mem...
Legal Hold-Discovery Manage... Legal Hold        Discovery Mana... RoleGroup         Direct            All Group Mem...
Mailbox Search-Discovery Ma... Mailbox Search    Discovery Mana... RoleGroup         Direct            All Group Mem... User Options-Help Desk user Options      Help Desk         RoleGroup         Direct            All Group Mem...

Sie sehen also, dass dies schon ein ganz komplexe Materie werden kann. für die meisten kleinen und mittleren Umgebungen, die aber sowieso keine Delegierung von administrativen Berechtigungen durchführen, funktioniert der Standard erstaunlich gut.

RBAC Manager

Microsoft hat "fast" nur die PowerShell als Verwaltungsweg vorgesehen. Sieht man mal von der Verwaltung der Gruppenmitgliedschaften per MMC oder die Verwaltung per ECP ab, bleibt die PowerShell übrig.

Auf Codeplex gibt es einen "Rbac Manager"

http://rbac.codeplex.com

Änderungen werden aber sofort aktiv. Es lohnt sich also eine TestUmgebung zum Üben und Verifizieren.

"Selbstmanagement"

Über OWA kann ein Anwender aber auch "seine eigenen Daten" ändern. Per Default ist dies sogar erlaubt.

Exchange legt dazu eine "Default Role Asignment Policy" an, die jedem Benutzer zugewiesen ist und ebenfalls über ECP eingesehen und verwaltet werden kann

Wenn Sie diese "Selbstverwaltung" global ausstellen wollen, dann müssen Sie einfach die Checkbox bei "myContactInformation" entfernen. Alternativ können Sie natürlich zusätzliche Richtlinien erstellen und dem Postfach dann zuweisen.. Die bestehende Richtlinie können Sie per PowerShell einfach abfragen: (gekürzt)

[PS] C:\>get-RoleAssignmentPolicy

IsDefault         : True
Description       : This policy grants end users permissions to set their Outlook Web App options and perform other sel
                    f-administration tasks.
RoleAssignments   : {MyDistributionGroupMembership-Default Role Assignment Policy, MyBaseOptions-Default Role Assignmen
                    t Policy, MyContactInformation-Default Role Assignment Policy, MyTextMessaging-Default Role Assignm
                    ent Policy, MyVoiceMail-Default Role Assignment Policy}
AssignedRoles     : {MyDistributionGroupMembership, MyBaseOptions, MyContactInformation, MyTextMessaging, MyVoiceMail}
Name              : Default Role Assignment Policy
DistinguishedName : CN=Default Role Assignment Policy,CN=Policies,CN=RBAC,CN=E2010Org,CN=Microsoft Exchange,CN=Services
                    ,CN=Configuration,DC=E2010,DC=local

Mit "New-RoleAssignmentPolicy" können sie auch hier weitere unterschiedlichen Vorgaben einrichten, die sie dann beim Benutzer verbinden können. Bei jedem Benutzer gibt es auch dazu ein eigenes Property:

[PS] C:\>Get-Mailbox | ft name,role*

Name                                                        RoleAssignmentPolicy
----                                                        --------------------
Administrator                                               Default Role Assignment Policy
DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334B... Default Role Assignment Policy
mailboxuser                                                 Default Role Assignment Policy
Archiv user                                                 Default Role Assignment Policy

Hintergründe

Wie viele andere Dinge sind auch die RBAC-Rollen und Zuweisungen im AD gespeichert, genauer in der Konfiguration Partition. Per ADSIEDIT können sie recht einfach mal "reinschauen".

Achtung
Bitte ändern Sie hier keine Einträge unter umgehung der Exchange PowerShell oder GUI.

Die komplette Konfiguration von RBAC liegt unter der Exchange Organisation in der Active Directory Configuration Partition und ist damit im gesamten Forest repliziert.

In den vier Containern "Policies", "Role Assignments", "Roles" und "Scopes" liegen die entsprechenden Einträge. Sie wie weiter oben schon gesehen haben, gibt es die entsprechenden Rollen, bei denen die einzelnen Befehle hinterlegt sind.

Im Active Directory gibt es dann für einige der Rollen schon entsprechende Sicherheitsgruppen, die über die "Role Assignments" miteinander verknüpft werden

Eine Person ist also idealerweise Mitglied einer entsprechenden Sicherheitsgruppe, welche dann über eine Verknüpfung mit der entsprechenden Rolle verbunden ist. Damit wird definiert, welche Befehle der Client letztlich ausführen darf.

Die Einstellungen, was ein Benutzer selbst machen darf, steht natürlich beim Benutzerobjekt.

dn: CN=mailboxuser,cn=users,DC=msxfaq,DC=de

msExchRBACPolicyLink: CN=Default Role Assignment Policy,CN=Policies,CN=RBAC,
    CN=Orgname,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de

Auch auch hier gilt: Bitte per PowerShell administrieren.

RBAC umgehen

Wer es drauf anlegt, kann natürlich auch RBAC umgehen indem Sie direkt auf dem Server arbeiten und die erforderlichen Extensions einfach nachladen. Dann greifen aber keinerlei administrative Rollen oder Prozesse. Aber als Administrator sollten Sie dann sowieso wissen, was sie tun. Dieser "Umweg" ohne RBAC ist aber z.B. erforderlich, wenn Sie per RBAC nicht mal mehr RBAC selbst verwalten können.

RBAC ganz vermeiden

Wer lieber selbst die komplette Business-Logik der PowerShell selbst schreiben will und weiterhin per LDAP die Felder direkt modifiziert, sollte wirklich Exchange in aller Tiefe können. Offiziell "supportet" ist es nicht und da es in Exchange 2007/2010 keinen Exchange RUS mehr gibt, kann auch kein Hintergrundprozess unstimmigkeiten korrigieren. Das möchte ich an den Adresslisten beispielhaft aufzeigen.

Nehmen wir an, sie haben eine Adressliste "AL Sales" in der alle Personen enthalten sein sollten, in deren "Abteilung" der Begriff "Sales" steht, dann ist dies in Exchange schnell konfiguriert. Direkt bei der Anlage der Adressliste werden Sie gefragt, ob Exchange die Liste gleich anlegen soll und danach ist die Adressliste nutzbar und gefüllt. Den wenigsten Administratoren ist aber bekannt, dass im Hintergrund noch mehr passiert.

Nehmen wir nun an, dass die Adressliste konfiguriert ist und Sie per LDAP bei einem anderen Mitarbeiter in die Abteilung nun ein "Sales" schreiben. Wenn Sie nur das machen, dann wird der Anwender niemals in der Adresslisten auftauchen, obwohl der entsprechende Empfängerfilter natürlich stimmt. Das Problem ist, dass Exchange zur Laufzeit nicht mit dem "teuren" Filter sucht, sondern das Feld "ShowInAddressbook" nutzt, welches ebenfalls mit gepflegt werden müsste.

Die "Lösung ist ganz einfach" und sie haben sogar drei Optionen:

  • Pflege per Set-Mailbox
    Das einfachste ist natürlich, die Einträge wieder mit der Exchange PowerShell vorzunehmen. Nur kann man damit leider nicht alle AD-Properties pflegen und woher sollen Sie wissen, welches Feld in einer Adressliste verwendet wird ?. Dennoch hat ein einfacher Aufruf von Set-Mailbox auch den Effekt, dass fehlende Einträge nachgezogen werden.
  • Update-Recipient
    Diese Commandlet ist speziell für den Einsatz von Metadirectories mitgeliefert worden, um die "fehlenden" Einträge zu addieren
    Ex2007: http://technet.microsoft.com/en-us/library/bb738148(EXCHG.80).aspx
    Ex2010: http://technet.microsoft.com/de-de/library/bb738148.aspx
  • Update-Addresslist
    Wenn Sie den Verdacht haben, dass ihre Adressliste nicht korrekt ist, können Sie ein Update über dieses Commandlet ausführen.

Wer es nicht glaubt, kann sich folgendes kleines Video einfach mal anschauen, bei dem ich die Abteilung eines Benutzers per AD users&Computers ändere.

rbac.mp4

http://www.youtube.com/watch?v=i1tY0kLaewE

Bug bis Exchange 2010 SP1 RU3: „Add--MailboxPermissions“ ignoriert Scopes

Software ist nicht immer fehlerfrei und auch RBAC ist das keine Ausnahme. Per RBAC können Commandlets für Personen nur für bestimmte OUs frei gegeben werden. Dazu ist es natürlich erforderlich, dass RBAC im Hintergrund diese Parameter auch prüft. Genau das scheint bei dem wichtigen Comandlet "Add-MailboxPermission" nicht passiert zu sein. Auch wenn per RBAC eingestellt ist, das jemand nur für bestimmte Benutzer einer OU diese Rechte anpassen darf, so kann er es dennoch für alle Objekte.

Laut dem MSXFAQ-Leser Herbert Killermann, der dieses Verhalten entdeckt hat, wurde dies von Microsoft im Rahmen eines Supportcalls auch bestätigt und soll mit Exchange 2010 SP1 Rollup 3 gefixt werden. Bis dahin sollten Sie sehr vorsichtig damit sein, diese Befehl per RBAC an andere Personen zu delegieren. Kein Problem haben damit Firmen, die zwar RBAC benutzen aber ihrerseits über ein Provisioning (z.B. Quest ActiveRoles o.ä.) diese Aktionen indirekt ausführen lassen.

  • 2489130 A RBAC role assignee can unexpectedly change mailbox properties that are outside the management role group scope in an Exchange Server 2010 environment

RBAC und Lync

Exchange ist nicht das einzige System, welches mit RBAC arbeiten. Auch Lync 2010 nutzt schon komplett RBAC zur Verwaltung. Auch hier gibt es die "Rollengruppen", welche mit einem CS beginnen und an die verschiedene Commandlets gebunden sind.

Wer eigene "Rollen" definiert, wird in der Regel eine dieser Gruppen als Template nehmen und die nicht erwünschten Commandlets entfernen, optional einen Scope einschränken und dann die Personen in der Gruppe aufnehmen.

Die "Arbeit" macht dann wieder der Server mit seinen Berechtigungen.

Weitere Links