Exchange Split Permission

Der Standard und das Problem

Exchange Server sind in vielen Active Directory Umgebungen ein bekannter Begleiter. Aus der Perspektive der IT-Sicherheit stellen sie aber ein gewisses Risiko dar. Mit einem Exchange Split Permission Modell kann man das Risiko deutlich reduzieren.

Doch wo kommt dieses Risiko her? Es beginnt bei der Installation des ersten Exchange Servers in einem Active Directory. Da wird die dafür erforderliche Option “Apply Active Directory split permission…” nicht standardmäßig aktiviert:

Exchange Split Permission

Wurde der erste Exchange Server auf diese Weise installiert, dann wird im Active Directory die Sicherheitsbeschreibung erweitert. So kann ein Exchange seine Arbeit aufnehmen. Doch diese Rechteerweiterung hat es in sich. Hier seht ihr ein schönes Beispiel:

Exchange Split Permission

Die Gruppe “Exchange Windows Permissions” hat auf der Domain die Berechtigung zum Ändern und Zurücksetzen von Kennworten erhalten. Diese wird auf “speziell” angewendet. Das hat die GUI etwas unglücklich gelöst. Schaut man sich aber eine beliebige OU oder einen Container unter der Domain an, dann wird die Berechtigung korrekt dargestellt. Hier mal das Beispiel des Containers “Users”:

Exchange Split Permission

Mit meiner PowerShell-Funktion kann ich diese Berechtigung für alle OUs im AD erkennen:

Exchange Split Permission

Die Gruppenmitglieder können also Benutzerpassworte in der Domain zurücksetzen. Und wer sind die Mitglieder? Richtig: Die Computerkonten der Exchange Server:

Exchange Split Permission

OK, das alleine ist noch nicht problematisch. Gravierend wird es erst, wenn man folgende Fakten dazu zählt:

  • Zu den Usern zählen auch alle Adminkonten. Wer den Exchange Server kontrolliert, kann die Passworte von Admins ändern und deren Identität annehmen.
  • Zu den Usern gehört auch das Konto KRBTGT. Wer dessen Passwort kennt, kann sich Golden Tickets ausstellen! In einem solchen Fall wird ein Active Directory sehr oft als verloren angesehen. Wie ein Golden Ticket funktioniert, zeige ich hier: https://www.ws-its.de/hacking-kerberos-goldenticket/ die Grundlagen findet ihr hier: https://www.ws-its.de/kerberos-ein-ueberblick/
  • Exchange Server sind für meist alle Benutzer intern erreichbar. Zudem sind auch oft aus dem Internet erreichbar (HTTPS für Outlook, OWA und Active Sync, SMTP für Mails).

Ein Angreifer braucht also nur einen Zugriff auf einen Exchange (aus dem Internet oder durch einen internen, kompromittierten Benutzer) und einen Exploit für eine ausnutzbare Schwachstelle. Dann kann er den Exchange Server kontrollieren und damit auch direkt das Active Directory übernehmen

Na zum Glück gibt es kaum Schwachstellen für Exchange Server…

Exchange Split Permission

Quelle: CVE – Search Results (mitre.org)

Das sollte als Grund für eine Veränderung eigentlich genügen! Wer es immer noch nicht glauben kann, in diesem Beitrag zeige ich einen einfachen Hack: https://www.ws-its.de/ad-hacking-ueber-exchange-server/

Exchange Rechtemodelle im Überblick

Microsoft bietet uns insgesamt 3 Rechtemodelle an.

Shared Permission

Das ist der Standard, den ich in der Einleitung eben beschrieben habe. Dieses Modell bietet sich nach Microsoft an, wenn die gleichen Admins für Exchange und Active Directory zuständig sind. Ich würde da gerne widersprechen. Diese Empfehlung kommt aus einer Zeit, in der kein Tier-Berechtigungsmodell genutzt wurde. In dieser Zeit meldete man sich auch auf Clients als Domain Admin an, um eine Software zu installieren. Das ist nicht mehr zeitgemäß!

Link zu Microsoft: Split permissions in Exchange Server | Microsoft Learn

RBAC split permissions

Mit diesem Modell werden die Rechte an den Exchange Objekten durch eine Role Based Access Control (RBAC) Delegation aufgeteilt. Man erstellt neue Gruppen im AD und weist diesen im Exchange die Rechte an den AD-Objekten zu. Microsoft empfiehlt dieses Modell, da es mit nur wenigen Einschränkungen daher kommt.

Link zu Microsoft: Split permissions in Exchange Server | Microsoft Learn

Active Directory split permissions

Dieses Modell schneidet tief in die Berechtigung ein. Ein Exchange Admin kann nun keine AD-Objekte, wie z.B. Benutzer oder Verteilergruppen mehr anlegen. Das muss ein Active Directory Admin für ihn erledigen.

Link zu Microsoft: Split permissions in Exchange Server | Microsoft Learn

Einschränkungen im Vergleich

Die Rechtetrennung betrifft einzelne Befehle in der PowerShell und natürlich auch deren Pendant in der EAC-Seite:

cmdletshared permissionsRBAC split permissionsAD split permissions
New-MailboxExchange Adminsnur RoleMemberskeine Berechtigung
New-MailContactExchange Adminsnur RoleMemberskeine Berechtigung
New-MailUserExchange Adminsnur RoleMemberskeine Berechtigung
New-RemoteMailboxExchange Adminsnur RoleMemberskeine Berechtigung
Remove-MailboxExchange Adminsnur RoleMemberskeine Berechtigung
Remove-MailContactExchange Adminsnur RoleMemberskeine Berechtigung
Remove-MailUserExchange Adminsnur RoleMemberskeine Berechtigung
Remove-RemoteMailboxExchange Adminsnur RoleMemberskeine Berechtigung
Add-DistributionGroupMemberExchange AdminsExchange Adminskeine Berechtigung
New-DistributionGroupExchange AdminsExchange Adminskeine Berechtigung
Remove-DistributionGroupExchange AdminsExchange Adminskeine Berechtigung
Remove-DistributionGroupMemberExchange AdminsExchange Adminskeine Berechtigung
Update-DistributionGroupMemberExchange AdminsExchange Adminskeine Berechtigung

Umstellung des Rechtemodells

Vorbereitung

Ich benötige ein aktuelles Exchange Server ISO, da die Umstellung des Rechtemodells mit der setup.exe vorgenommen wird. Weiter benötige ich eine Kennung mit den Rechten im Exchange Server und im Active Directory. Dafür privilegiere ich meine T3-Kennung temporär zum Superadmin:

Exchange Split Permission

Aktivierung von RBAC split permissions

Microsoft hat die Arbeitsschritte hier beschrieben: Configure Exchange Server for split permissions | Microsoft Learn.

Als T3-Admin starte ich den setup.exe-Befehl auf einem Domain Controller, nachdem ich dort das Exchange Server ISO eingebunden habe:

Exchange Split Permission

Die Aktion dauert wenige Minuten. Was hat sich im Active Directory verändert? Ich prüfe die ACL auf der Domain Partition. Doch hier hat sich im Vergleich zum Modell “shared permissions” nichts verändert!

Exchange Split Permission

Und was hat sich im Exchange verändert? In der EAC-Seite gibt es die Option zur Anlage eines neuen Benutzers mit Mailbox noch:

Exchange Split Permission

Und ebenso funktioniert die Anlage über die PowerShell weiterhin:

Exchange Split Permission

Das bedeutet, es gibt wirklich nur eine Trennung mit den Berechtigungsgruppen und ein Exchange Organisationsadmin hat immer noch die vollen Rechte im Active Directory. Von den Exchange Computerkonten mal ganz abgesehen. Das ist nicht das, was ich mir hier vorstelle. Daher überspringe ich die weiteren Schritte in der Microsoft-Anleitung!

Aktivierung von Active Directory split permissions

Auch für diese Umstellung ist ein Aufruf der setup.exe erforderlich. Diese starte ich als T3-Admin (mit SuperAdmin-Rechten) auf meinem Domain Controller. Auch hier dauert der gesamte Vorgang nur wenige Minuten:

Exchange Split Permission

Ich prüfe wieder, welche Berechtigungen im AD greifen. Es sind einige Einträge in der ACL verschwunden. Vor allem fehlt nun der Passwort-Reset-Eintrag 🙂

Exchange Split Permission

Doch das möchte ich nun genau wissen. Ich versuche wieder, einen User mit Mailbox anzulegen. Die EAC scheitert:

Exchange Split Permission

Und ebenso geht es in der PowerShell nicht weiter, da die erforderlichen Parameter fehlen:

Exchange Split Permission
Exchange Split Permission

So habe ich mir das vorgestellt! 🙂 Zusätzlich scanne ich noch alle ACL meiner Domain Partition auf Berechtigungen vom Exchange. Das Ergebnis ist optimal:

Exchange Split Permission

Zurück zu shared permission (default), wenn man das braucht

Der Weg zurück zum Modell “shared permissions” wird wieder über die setup.exe durchgeführt. Dem geübten Auge wird auffallen, dass der Befehl der gleiche ist, mit dem man zum Modell “RBAC split permissions” wechselt:

Exchange Split Permission

Das ist auch nicht weiter verwunderlich, da der Unterschied zwischen diesen beiden Modellen alleine in den Rollen im Exchange liegt.

Mitgliedschaft in der Gruppe Administratoren

Ich präferiere das Modell “Active Directory Split Permissions”, da hier das Risiko eines Übergriffs zum AD nicht mehr möglich ist. Aber: Es gibt bei mir im AD noch einen Rest, der weiter die hohen Rechte an die Exchange Server delegiert:

Exchange Split Permission

Ich weiß noch, dass diese Gruppenmitgliedschaft bei einem CU-Setup oder dem Aufbau eines neuen Exchange Servers benötigt wird. Da das aber recht seltene Ereignisse sind, habe ich die Gruppenmitgliedschaft entfernt. Das Ergebnis aus der Perspektive des Hackers könnt ihr euch in meinem Artikel https://www.ws-its.de/ad-hacking-ueber-exchange-server/ ansehen.

Fazit

Der Eingriff zum richtigen Aufsplitten ist recht schnell erledigt und die Verbesserung der IT-Sicherheit ist enorm. Aber natürlich müssen vorher einige Prozesse angepasst werden: Bisher konnte der Exchange Admin neue Verteilergruppen oder Mailboxen mit den AD-Objekten direkt selber anlegen. Jetzt muss ein AD-Admin diese Objekte im AD anlegen und dann muss der Exchange Admin diese im Exchange enablen. Und bei der Entfernung gilt natürlich das Gleiche. Aber das sollte sich doch lösen lassen, oder?

Stay tuned!

Kommentar hinterlassen