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.

Wie sicher ist sicher?

Exchange ist sehr eng mit dem Active Directory integriert und damit sind auch entsprechende Rechte verbunden. Es gibt aus meiner Sicht mehrere Optionen, wie eine Software und Administration erfolgen kann. Interessant ist, dass je nach Exchange Version die verschiedenen Optionen eingesetzt wurden.

Administration Service Bewertung genutzt von

Durch Exchange Administrator

Liest/Schreibt die Daten

Produktspezifische Datenbank

Die Zeit von Exchange 4.0 bis 5.5 war lange vor dem ersten Active Directory. Diese Produkte hatten daher ihren eigenen Verzeichnisdienst" zur Verwaltung der Exchange Empfänger. Die Server selbst waren zwar Mitglied im Active Directory aber eben nur Mitgliedsserver ohne weitere Berechtigungen. Der Windows Administrator musste die Domain-Benutzer anlegen und Exchange hat dann einfach die Authentifizierung durch die Domäne genutzt. Die Informationen über Postfächer, Verteiler und öffentlichen Ordner wurden in einer eigenen Verzeichnisdatenbank "DIR.EDB" gespeichert und unterlagen damit einer getrennten Verwaltung. Interessanterweise sind viele Fehlermeldungen und Eventlog-Nummern der Exchange 5.x Verzeichnisdatenbank mit den Fehlern im Active Directory Eventlog (NTTDT.DIT) identisch. Da könnte es also eine Zusammenarbeit gegeben haben.

Der Nachteil dieser Lösung war natürlich die doppelte Verwaltung von Identitäten. Inkonsistenzen sind möglich, z.B. Postfächer ohne zugeordneten Benutzer und gleichnamige Gruppen mit unterschiedlichen Mitgliedern.
  • Exchange 4.0-55

Durch Administrator direkt an den AD-Objekten

Liest die Daten nur aus

Klassisches AD Modell

Seit Exchange 2000 gibt es keinen eigenen Exchange Verzeichnis Service mehr und Exchange baut auf das Active Directory. Bis Exchange 2003 hat Microsoft die MMC für Benutzer und Computer um "Exchange Karteikarten und Aktionen" erweitert. Technisch hat aber der Administrator mit seinen Berechtigungen direkt per LDAP an den AD-Objekten gearbeitet. Das geht auch an der Exchange Business Logik vorbei per LDAP, VBScript und wurde damals auch intensiv genutzt.

Das kann auch eine Malware machen und es gab keine unabhängige Validierung der Werte auf Gültigkeit. Der Schutz dieser Admin-Konten ist bei dem Modell wichtig.

Mit Blick auf den Server ist diese Konfiguration natürlich sicher, da der Server hier nur "Lesen" muss. Der Server muss nichts schreiben.
  • Exchange 2000
  • Exchange 2003

Indirekt über den Server

Liest und schreibt Daten. Erzeugt und löscht Objekte

Shared Permission Model

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

Der normale Administrator selbst muss damit nicht mehr das Recht haben, bestimmte Properties an den Exchange Konfigurationsobjekten oder Empfängern zu schreiben. Der Exchange Code kann zudem die Plausibilität der Daten prüfen und damit Falscheinstellungen von vorneherein unterbinden, z.B. Mailadressen anhand der Vorgaben direkt umsetzen oder ungültige Adresse abweisen.

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 + Server

Liest und schreibt Daten. Legt aber keine Objekte an

Split Permission Model

Bei diesem Modell hat der Exchange Server weniger Berechtigungen und kann keine Objekte mehr anlegen oder löschen. Insbesondere administrative Objekte sind besser geschützt.

Allerdings müssen neue Anwender dann durch einen "UserAdmin" angelegt und durch Exchange Admins dann mit einem Postfach versehen werden. Daher leitet sich auch der Name "shared" ab. Das sichert ihre Umgebung besser gegen Fehler in Exchange ab aber öffnet natürlich wieder eine Tür beim Administrator, der die Anlage und Löschung selbst organisieren muss.

Optional aktivierbar

Indirekt über den Server

Liest und schreibt Daten. Erzeugt und löscht Objekte

Ressource Forests

Dies ist ein besonderer Fall, bei dem Exchange in einem ganz eigenen Forest installiert wird. Exchange kann dann keine Objekte im Anmeldeforest verändern.

Ab Ex2000

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 Sinn, diese Berechtigungen 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 On-Prem 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.

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.

SSie 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