Exchange Permission Model

Die Sicherheitslücken Anfang 2019 (Siehe auch Exchange Fail Jan 2019 - CVE-2018-8581) haben das Augenmerk auch auf die Berechtigungen der Exchange Server gelenkt. Es wird oft zwischen einem "Shared" und einem "Split"-Permission Modell unterschieden. Diese Seite soll die Unterschiede besser heraus arbeiten, damit Sie sich für das richtige Modell entscheiden können.

Sicher - sicherer - noch sicherer

Exchange ist sehr eng mit dem Active Directory integriert und damit sind auch entsprechende Rechte verbunden. Es gibt aus meiner Sicht nun drei Optionen, wie eine Software und Administration erfolgen kann.

Administration Service Bewertung genutzt von

Durch Administrator direkt an den AD-Objekten

Liest die Daten nur aus

Klassisch

Aus Sicht des Servers ist diese Konfiguration natürlich sicher, da der Server hier nur "Lesen" muss. Das Risiko sind natürlich die Administratoren, die mir ihren üblichen Rechten mehr oder weniger alles ändern können. Das geht auch an der Exchange Business Logik vorbei per LDAP, VBScript und wurde damals auch intensiv genutzt.

  • Exchange 2000
  • Exchange 2003

Indirekt über den Server

Liest und schreibt Daten

Shared Permission Model

Mit Exchange 2007 hat Microsoft nicht nur den Sprung auf 64bit gemacht, sondern auch die Verwaltung komplett geändert. Ein Administrator nutzt Exchange Commandlets und das Control Panel um die Einstellungen durch den Server durchführen zu lassen. Der Exchange Server hat damit deutlich Mehr Berechtigungen auf die Konfiguration und Empfänger.

Der normale Administrator muss also gar nicht mehr das Recht haben, bestimmte Properties an den Exchange Konfigurationsobjekten oder Empfängern zu schreiben. Der Exchange Code kann zudem die Gütigkeit der Daten prüfen und damit Falscheinstellungen von vorneherein unterbinden.

Mit Exchange 2010 wurde das Verfahren mit durch RBAC - Role Based Access Control noch weiter verbessert. Letztlich ist der Exchange Server die autoritative Instanz und hat entsprechend Berechtigungen.

Das war auch ein Aspekt, warum die Sicherheitslücke CVE-2018-8581 (Exchange Fail Jan 2019 - CVE-2018-8581) so schwerwiegend war. Über die Berechtigung zur Pflege von Verteilerlisten und Gruppen auf der Domäne kann Exchange auch die Mitglieder von administrativen Gruppen, hier ist die Gruppe der Domänen-Administratoren besonders interessant, verändern.

  • Exchange 2007
  • Exchange 2010
  • Exchange 2013
  • Exchange 2016
  • Exchange 2019

Durch Admin

Liest die meisten Daten

Split Permission Model

Der Name sagt ja schon, welches Modell hier zur Anwendung kommt. Der Exchange Server hat deutlich weniger Berechtigungen und kann insbesondere administrative Objekte nicht mehr verändern und ACLs schreiben. Das sichert ihre Umgebung gegen Fehler in Exchange ab aber öffnet natürlich wieder eine Tür beim Administrator.

Wenn Exchange bestimmte Berechtigungen nicht hat, dann sind für einige Aktionen natürlich andere Wege erforderlich

Optional aktivierbar

Das klassische Modell steht mit Exchange 2007 und höher natürlich nicht mehr zur Verfügung und die Koexistenz mit Exchange 2003/2000 ist seit Exchange 2013 schon lange Geschichte. Da im Februar 2019 auch der Support für Exchange 2007 schon lange ausgelaufen ist, gehe ich für die weitere Beschreibung davon aus, dass sie mindestens Exchange 2010 oder höher einsetzen.

Wer die Wahl hat...

Wenn Sie das Exchange Setup ausführen, dann werden Sie relativ früh gefragt, ob Sie das "Split Permission Modell" umsetzen wollen. An der Stelle, an der sich bei der ersten Installation von Exchange für einen Organisationsnamen entscheiden müssen, wird die Checkbox mit eingeblendet.

Per Default ist die Auswahl nicht aktiv und so können und sollten Sie davon ausgehen, dass die überwiegende Zahl der Exchange Installationen im "Shared permission Model" laufen und das seit über 12 Jahre auch immer gut war. Die Beschreibung erklärt auch, dass diese Einstellung eigentlich für größere Firmen interessant ist bei denen Der Administrator von Exchange und der Administrator der Empfänger nicht die gleiche Person sind.

Sie lesen hier aber auch, dass es dann den Exchange Administratoren nicht mehr möglich ist, z.B. neue Postfächer, Verteiler oder Kontakte anzulegen. Sie müssen also ihren "Provisioning-Prozess" neu definieren. Benutzer, Verteiler und Kontakte müssen dann über einen anderen Weg von einem entsprechend im Active Directory berechtigten Personenkreis angelegt werden, ehe Sie dann ein Exchange Recipient Administrator entsprechend weiter provisionieren kann.

Der letzte Satz dürfte damit für die meisten mittleren und kleinen Firmen zutreffen: Wenn die Personen eh beide Tätigkeiten verrichten, dann macht es wenig Sin diese Rechte zu trennen. Etwas irritierend kam dann im Feb 2019 dazu, dass Microsoft auf einem Security Warning in etwa folgendes schrieb:

"Attackers cannot compromise a Domain Admin account if an OnPrem deployment follows Microsoft’s security best practice guidance and has implemented Active Directory Split Permissions "
Quelle: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190007.  Stand 10 Feb 2019

So eine Aussage ist missverständlich, weil viele Leser meinten, dass es "Best Practice" wäre, das Split Permission Modell zu nutzen. Das stimmt so aber nicht. Microsoft unterstützt beide Modelle vollumfänglich und gibt auch keinen einen Vorzug. In Hinblick auf die Security Lücke in EWS (Siehe Exchange Fail Jan 2019 - CVE-2018-8581) kann man natürlich sagen, dass all die Firmen mit dem "Split Permission Model" hier nicht verwundbar waren. Ich möchte aber nicht wissen, wie häufig genau diese Firmen angreifbar waren, weil andere Lücken die Kompromittierung des Administrators erlaubt haben. Beim Split Permission Modell muss er ja direkt per LDAP die Objekte anlegen und ändern können weil Exchange es nicht mehr kann.

Es gibt aus meiner Sicht keinen Gewinner oder eine bessere Wahl. Beide Modelle haben ihre individuellen Vorteile und Nachteile.

Split Permission aktivieren

Das Setup per GUI erlaubt ihnen die Auswahl des Security Model nur während der Eingabe der Organisation. Dies ist allerdings ein einmaliger Prozess bei der Installation des ersten Exchange Servers in einem neuen Forest. Ich bin ziemlich sicher, dass die meisten Administratoren sich an dieses Fenster nicht mal erinnern können, es sei denn Sie haben mal eine Testumgebung aufgebaut oder in einen neuen Forest migriert.

Sie können aber auch bei einer bestehenden Installation das Permission Modell immer wieder umstellen. Microsoft beschreibt dies selbst sehr ausführlich:

You can also enable or disable Active Directory split permissions after you've installed Exchange 2013 by rerunning setup.exe from the command line. To enable Active Directory split permissions, set the ActiveDirectorySplitPermissionsparameter to true. To disable it, set it to false. You must always specify the PrepareAD switch along with the ActiveDirectorySplitPermissions parameter. If you have multiple domains within the same forest, you must also either specify the PrepareAllDomains switch when you apply Active Directory split permissions or run setup with the PrepareDomain switch in each domain. If you choose to run setup with the PrepareDomain switch in each domain rather than use the PrepareAllDomains switch, you must prepare every domain that contains Exchange servers, mail-enabled objects, or global catalog servers that could be accessed by an Exchange server.
Quelle: https://docs.microsoft.com/en-us/exchange/understanding-split-permissions-exchange-2013-help

Dem Exchange Server ist es letztlich für den laufenden Betrieb erst mal egal, ob er weniger oder mehr schreiben kann, weil er im Regelfall sowieso nicht schreibt. Das passiert ja nur, wenn ein Administrator per RBAC den Exchange mit einem der folgenden auffordert, neue Objekte anzulegen oder bestehende Objekte zu löschen. Auch dazu hat Microsoft eine eigene Warnung formuliert

After you enable Active Directory split permissions, Exchange administrators and servers will no longer be able to create security principals in Active Directory, and they won't be able to manage distribution group membership. These tasks must be performed using Active Directory management tools with the required Active Directory permissions. Before you make this change, you should understand the impact it will have on your administration processes and third-party applications that integrate with Exchange 2013 and the RBAC permissions model.
Quelle: https://docs.microsoft.com/en-us/exchange/configure-exchange-2013-for-split-permissions-exchange-2013-help

Folgende Commandlets funktionieren daher nicht mehr:

New-Mailbox
New-MailContact
New-MailUser
New-RemoteMailbox
Remove-Mailbox
Remove-MailContact
Remove-MailUser
Remove-RemoteMailbox
Add-DistributionGroupMember
New-DistributionGroup
Remove-DistributionGroup
Remove-DistributionGroupMember
Update-DistributionGroupMember

Aber genau die Berechtigungen, die für diese Commandlets den Exchange Servern gegeben werden müssen sind auch der Grund, dass Exchange Server z.B. die Gruppe der Domänen-Administratoren und andere sensible Gruppen ändern können. Exchange hat sich beim "Shared Permission Modell" nämlich auch die entsprechenden Berechtigungen auf den Admin Gruppen über das AdminSDHolder-Objekt gegeben.

Empfehlung

Eine klare Empfehlung auszusprechen ist nicht einfach. Der Split-Permission Model ist natürlich sicherer, wenn Sie die Berechtigungen der Exchange Server einschränken wollen. Ich kann schon verstehen, dass in größeren Firmen es kritisch gesehen wird, wenn eine Gruppe wie "Exchange Server" oder "Exchange Trusted Subsystem" sehr weitreichende Rechte auf AD-Objekte hat. Microsoft hätte die Rechte sicher auch gerne enger gefasst und insbesondere die administrativen Gruppen ausgespart. Aber Microsoft kann kann nicht wissen wissen, wie Sie ihr Active Directory in OUs aufteilen und dann die Rechte nur auf dieses OU vergeben. Ich behaupte aber auch mal, dass in den meisten Firmen auch Administratoren ein Postfach haben bzw. Benutzer mit einem Postfach auch administrieren. Nicht jede Firma trennt "Admin" und "normaler User" strickt.

Das Shared Permission Model ist aus meiner Sicht für kleine und mittlere Firmen immer noch die beste Wahl, auch wenn durch Exchange Fail Jan 2019 - CVE-2018-8581 mal wieder aufgezeigt wurde, dass jede Software Fehler haben kann. Software hat Bugs und Menschen machen Fehler. Wenn Sie aber die Rechte einschränken und daher an anderer Stelle für die gleiche Aufgabe dann mit einem anderen Programm die Berechtigungen benötigen, dann kommt ein Einbrecher durch eine andere Hintertür ins System.

Aus meiner Sicht ist es viel wichtiger, dass Sie ein klares Admin-Konzept haben und die eingesetzten Produkte kennen und zeitnah aktuell halten.

Weitere Links