Ressourceforest und Gruppenrechte

Diese Seite beschreibt die Berechtigungen von Gruppen und Verteilern bei Exchange OnPremises-Umgebungen in einem Ressource Forest Szenario mit LinkedMailbox.

Beachten Sie dazu auch die Seiten Ressource Forest und Linked Mailbox

Startpunkt

Neben dem Betrieb von Anmeldekonten und Exchange Servern im gleichen Forest gibt es Firmen, die für Exchange einen eigenen Forest betreiben. Sogar Exchange Online ist eine Art "Ressourcen-Frest", wenn wer sich in Microsoft 365 die verschiedenen Werte in "DistinguishedName" in den unterschiedlichen PowerShells anschaut, erkennt auch in der Cloud ein "Multi Forest Szenario", auch wenn Microsoft darüber öffentlich nicht viel schreibt.

Aber OnPremises gibt es die gleiche Betriebsart, die ich auf Ressource Forest beschrieben habe und da gibt es nun mal zwei Forests mit zwei Benutzerkonten für die gleiche Person und zwei Gruppen. Und das kann knifflig sein:

Wir haben hier mehrere Faktoren zu beachten

  • SID beim Anmeldebenutzer
    Der Anmeldebenutzer ist Mitglied in einer Sicherheitsgruppe im Anmeldeforest und bei der Anmeldung an seinem Client bekommt er also ein Kerberosticket bzw. NTLM-Token mit der UserSID und den SIDs der Gruppen, in denen er Mitglied ist. Das Anmeldekonto ist aber in der Regel NICHT Mitglied in einer Gruppe im Exchange Ressource Forest.
  • LinkedMailbox
    Im Exchange Forest gibt es die Linked Mailbox mit dem deaktivierten Benutzerund über das Feld "msexchMasterAccountSID" mit dem Benutzerkonten aus dem vertrauten Anmeldeforest verbunden ist.
  • Verteiler und Rechte
    Damit die Benutzer mit Outlook auch Verteiler nutzen können, gibt es im Exchange Ressource Forest entsprechende Universal Security Groups, die als Verteiler aktiviert sind. Die Mitglieder sind entsprechend die Linked Mailbox und andere Objekte aus dem Exchange Forest. Das Anmeldekonto oder die Gruppe im Anmeldeforest kann dort nicht Mitglied sein, da eine Universal Security Groups dies nicht erlaubt.

Berechtigungen

Nun stellt sich die Frage wie Berechtigungen wirken. Das kann z.B. ein öffentlicher Ordner oder eine SharedMailbox sein, auf die jemand als Benutzer direkt oder über einen Verteiler berechtigt sein kann. Die Frage ist nun, wie Exchange die Berechtigungen auswertet. Der Zugriff erfolgt durch das Anmeldekonto mit Outlook o.ä. über das Netzwerk. Der angemeldete Benutzer hat in seinem Kerberosticket oder NTLM-Ticket daher seine UserSID und die SIDs aller Gruppen, in denen er Mitglied ist.

Zuerst versucht Exchange anhand der UserSID die Rechte auszuwerten. Es gibt aber im gesamten Exchange Forest keinen aktiven Benutzer mit der UserSID. Hier kommt dann das Feld "msexchMasteraccountSID" zum Einsatz, denn Exchange prüft beides ab

ACLSid =      (ADUser mit Account = Aktiv    und ObjectSID = UserSID") 
         oder (ADUser mit Account = disabled und msexchMasterAccountSid = UserSID)

Von dem so gefundenen Objekt nutzt Exchange dann die ACL und prüft die Zugriffsrechte. Was für Benutzerkonten noch einfach ist, ist für Gruppen deutlich kniffliger. Der angemeldete Benutzer weiß ja nicht, dass er auch Mitglied des Verteilers ist und liefert daher auch nicht die SID des Verteilers in seinem Zugriffstoken mit. Der Exchange Server hingegen kennt zwar die LinkedMailbox aber macht sich wohl nicht die Mühe, die Gruppenmitgliedschaften dieser Mailbox zu ermitteln und die ACL darauf auszuwerten.

Ergebnis: Der Benutzer kann keine öffentlichen Ordner oder Postfächer anderer Benutzer öffnen, wenn die Berechtigungen über Gruppen im Exchange Ressource Forest gegeben wurden.

Lösungswege

Mit dem Wissen, wie Exchange tickt, können Sie sich nun verschiedene Lösungen herleiten, z.B.

  • Rechte über LinkedMailbox und nicht Verteiler
    Die Zugriffsrechte über die LinkedMailbox funktioniert. Sie könnten daher auf die Vergabe von Berechtigungen über Verteiler verzichten und direkt die Benutzer individuell berechtigen. Elegant ist das aber nicht, wenn neue Anwender dazu kommen und nicht allein über eine Gruppenmitgliedschaft berechtigt werden können.
    Sie könnte aber ein Skript bauen, welches zyklisch die Mitglieder einer Gruppe auf das Postfach oder den öffentlichen Ordner zusätzlich berechtigt.
  • Anmeldekonto ist Mitglied im Verteiler
    Das ist möglich, wenn Sie den Verteiler von "Universal Security Group" auf "Domain Local Security Group" umstellen. Nur dann können Sie das Anmeldekonten des vertrauten Anmeldeforest in die Gruppe aufnehmen. Allerdings nicht mit Outlook, sondern per Windows Bordmittel. Zudem erscheint der Benutzer dann in Active Directory Benutzer&Computer einmal mit dem deaktivieren Konto und mit dem Anmeldekonto. Inkonsistenzen sollten Sie möglichst automatisch auflösen, z.B. indem ein Skript die Mitgliedschaften angleicht.
    Denken Sie auch daran, dass der Exchange Ressource Forest dann nur aus einer Domain bestehen darf, denn eine "Domain local"-Gruppe ist nicht im globalen Katalog und je nach befragtem DC funktioniert dann die Mailverteiler-Funktion oder Zugriff über Berechtigungen gut oder nicht.
  • SIDHistory
    Wer sich mit ADMT -Active Directory Migration Toolkit auskennt, weiß um die Möglichkeit die SID von Konten in andere Forests zu clonen. Der Prozess wird bei Migrationen genutzt, um Berechtigungen beizubehalten. Sie könnten als auch die SID des Verteilers zusätzlich als SIDHistory an die Gruppe im Anmeldeforest kleben. Dann bekommt der Anmelder bei der nächsten Anmeldung neben der UserSID und der GroupSID auch die GroupHistorySID und Exchange kann beim Zugriff des Benutzers keinen Unterschied erkennen. Voraussetzung ist natürlich, dass die SIDHistory-Filterung auf dem Trust entsprechend konfiguriert ist.

Alle Varianten haben ihre individuellen Vor- und Nachteile. einen goldenen Weg gibt es nicht, solange Microsoft nicht in Exchange die Logik erweitert.

Mein Favorit

Aktuell favorisiere ich den Einsatz von "Domain Local Security Groups" in einem Exchange Ressource Forest, der nur eine Domain hat.

Das mag zwar Exchange nicht so gerne, da Exchange jede Gruppe zu einer Universal Security Group konvertieren möchte. Das ist natürlich nicht möglich, solange nur ein Objekt aus einem anderen Forest als Mitglied in der Gruppe ist. Sie können also den Gruppentyp umstellen und einen User addieren.

Sie könnten als Exchange Administrator ein Skript entwickeln, welches alle Verteiler in ihrem Ressource Forest zyklisch verarbeitet, den Typ auf "DomainLocal" gestellt und für jedes Mailbox-Mitglied das dazu passende Account-Konto addiert.

Auch das ist eine Aufgabe für ein Provisioning und Automatisierung. Nur gut, dass wir hierzu recht einfach Änderungen an Gruppen und AD-Objekten automatisch erkennen und darauf reagieren können. Siehe dazu Get-USNChanges und GET-ADChanges.

add key=”UseDisabledAccount” value=”1″

Bei der Recherche zu dieser Seite bin ich auf einen Schlüssel gestoßen, den ich als Administrator in der web.config hinterlegen kann, z.B.

CU12 Exchange 2016 can break additional configurations you have defined in the EWS web.config file. For example we have added the key add key=”UseDisabledAccount” value=”1″ to the OWA and to the EWS web.config. This key helps with the correct handling of low-level calendar permissions as AvailabilityOnly and LimitedDetails on security groups when working with resource forests ( linked mailboxes ). After CU12 has been installed this key was not present in the EWS web.config anymore. It turned out when a customer reported that users who want to access a resource calendar are not able to open it in Outlook and OWA.
Quelle: CU12 Exchange 2016 and .NET 4.7.2 https://webbanshee.net/cu12-exchange-2016-net-4-7-2/

Die Eintragungen sind in den beiden folgenden Dateien vorzunehmen:

%ExchangeInstallPath%\ClientAccess\Owa\web.config
%ExchangeInstallPath%\ClientAccess\exchweb\Ews\web.config

Der Eintrag lautet:

<appSettings>
// Add the following line.
       <add key="UseDisabledAccount" value="1" />
</appSettings>

Angeblich soll dies Probleme beseitigen. Vielleicht gilt dies für OWA aber eine Auswirkung auf Outlook konnte ich nicht feststellen.

Zwischenstand

Vermutlich ist das Thema dieser Seite für viele Firmen kein Problem, da sie Exchange und Anmeldekonten im gleichen Forest betreiben oder mittlerweile in Exchange Online sind. So haben das Problem nur noch die Firmen, die lokal einen Exchange Ressource Forest betreiben. Davon gibt es wohl nicht sehr so viele und Sie haben sich wohl damit arrangiert, dass die Vergabe von Zugriffsrechten über Verteiler nicht funktioniert.

Ich habe ihnen auf dieser Seite drei Möglichkeiten aufgezeigt, das Problem zu reduzieren. Schön finde ich alle drei nicht.

Weitere Links