Gruppen, Domains und LDAP

Wer einen AD-Forest mit mehreren Domains betreibt, wird irgendwann auf Benutzer, die drei unterschiedlichen Bereiche für Gruppen und LDAP-Anfragen stoßen. Diese Seite liefert ein paar Grundlagen, wann sie was sehen.

Umgebung

Für die folgende Beschreibung haben wir zwei Domain Controller in je einer Domain, die einen Forest aufspannen.

In meinem Beispiel ist jeder Domain Controller auch als Global Catalog konfiguriert. Ein DC, der kein Global Catalog-Server ist, bietet keine Verbindung auf Port 3268 an. Ich beschränke mich hier auf LDAP ohne Verschlüsselung. Sobald Sie auf dem Domain Controller eine Zertifikat installiert haben, können Sie natürlich auch die TLS-gesicherten Port 636 und 3269 nutzen.

Partitionen, DC und GC

Ein Domain Controller ist ein LDAP-Server, der eine Datenbank (NTDS.DIT) mit Inhalten bereitstellt. Diese Inhalte sind in Partitionen aufgeteilt, die nach extern aber unter dem gleichen TCP-Port erreichbar sind. Diese sind:

Partition	Replikation	Beschreibung
Schema	Alle DCs des Forest	Enthält die Definition der Datenbankeinträge, d.h. welche Objektklassen es gibt (User, Group, Computer,  OU, Domain, etc.) und welche Eigenschaften pro Objektklasse vorhanden sein müssen oder können
Configuration	Alle DCs des Forest	Eine auf alle Server des Forests synchron gehaltene Datenstruktur für den Eigenbetrieb. Hier liegen z.B. die AD Sites&Services aber auch 3rd-Party-Produkte wie Exchange etc. können hier global relevante Informationen bereitstellen
Domain	Alle DCs der Domain und Teilweise alle GCs des Forest	Diese Partition gibt es pro Domain und enthält die OUs, Computer, Benutzer, Gruppen etc. Sie ist auf alle DCs der gleichen Domain komplett repliziert. Auf anderen GCs wird nur eine Teilmenge der Informationen übertragen,
ForestDNSZones DomainDNSZones	Alle DCs oder nur in der Domain	Wenn ihr DNS-Server seine Informationen im lokalen Active Directory speichert, können Sie pro Zone die Replikation einstellen.

Der Zugriff auf diese Zonen erfolgt über Port 389/LDAP oder 636/LDAPS und über LDP oder andere Programme können Sie die Details sogar anonym ermitteln:

Mein einfacher einzelner DC/GC hat hier fünf Partitionen. Interessant wird es nun, wenn wir die Verteilung bei mehreren Domains anschauen. Jeder Domain Controller hat neben dem Schema und der Konfiguration natürlich auch die komplette Partition seiner eigenen Domain. Das ist auch erforderlich, dass er als autoritative Instanz für die Domain alle Anforderungen und Authentifizierungen (Kennwort-Hash) ausführen kann. Ein "ReadOnly"-DC unterscheidet sich von einen normalen DC z.B. darin, dass er nicht von allen Benutzern der Domain-Partition die Hashwerte der Kennwort vorhält und die Partitionen für Clients nur lesbar sind.

Wenn ein Domain Controller auch "Global Catalog" ist, dann ist er zusätzlich auch über Port 3268/LDAP und 3269/LDAPS erreichbar. Über diesen Zugang erhalten Sie ebenfalls alle Objekte der schon genannten Partitionen. Wenn ihr Forest aber aus mehreren Domänen besteht, dann replizieren die DCs auch Objekte anderer Domänen untereinander und der GC stellt diese als Teilmenge bereit. Der Zugriff auf den GC ist ebenfalls "ReadOnly". Welche Felder auf GCs in anderen Domänen repliziert werden, ist im Schema definiert.

Sie können pro Attribut diese Checkbox sogar setzen und entfernen und damit steuern, welche Attribute auf allen GCs vorgehalten werden. Denken Sie aber an die zusätzliche Replikation weiterer Felder.

Übrigens: Eine Exchange Installation erweitert das Schema nicht nur um neue Klassen und Felder, sondern ändert auch die GC-Einstellungen von bestehenden Feldern.

Das Feld "ProxyAddresses" ist im Active Directory schon immer vorhanden aber nicht für den GC aktiviert. Das ändert erst die Schemaerweiterung von Exchange.

_msdcs-Zone im DNS

Damit die Clients einen schnellen Weg zum GC finden, nutzen sie DNS. Die Domaincontroller tragen dazu nicht nur ihren Rechnernamen in der DNS-Zone ein, sondern auch jede Menge SRV-Records. Hierbei sind zwei Bereiche zu unterscheiden.

• Einträge pro Domain
  In jeder Domäne des AD-Forest gibt es im DNS entsprechende Einträge unter _tcp, _udp, _sites. Hier tragen sich die DCs der Domäne ein.
• Forestweite Einträge
  Die seit Windows 2003 eigenständig delegierte Zone "_msdcs.<forestdomain>" gibt es nur einmal im Forest und enthält weitere Einträge zu Domänen aber vor allem auch den Eintrag zu allen GCs und PDC-Emulator.

Hier ein Auszug einer Windows DNS-Struktur: 

Beachten sie, dass sich die DCs auch als A-Record ohne Hostnamen in ihrer Domain eintragen. Wer per DNS alle DCs einer Domain auflösen will kann dies einfach durch eine Auflösung von A-Records der Domain erreichen:

NSLOOKUP -q=A <domain> 

Allerdings können sich dort auch andere Einträge finden, wenn ein Webserver-Administrator z.B.: die  Adresse "https://<domain>" und nicht nur "http://www.<domain>" veröffentlichen wollen.

Objekteigenschaften zwischen DC und GC

Wenn ich ein Objekt per LDAP anfrage, dann macht es einen Unterschied, ob ich den normalen LDAP-Port 389/636 anspreche oder den GC über Port 3268/3269 abfrage. Ich habe auf meinem DC nach einem Benutzer gesucht und mir alle Eigenschaften angefordert. Die Unterschiede sind erkennbar.

Get-ADObject `
   -LDAPFilter "(samaccountname=fc)" `
   -Server msxfaq.de:389 `
   -Properties *

Get-ADObject `
   -LDAPFilter "(samaccountname=fc)" `
   -Server msxfaq.de:3268 `
   -Properties *

Der Domaincontroller liefert bei der regulären Abfrage auch Felder wie "accountExpires", "codePage", "countryCode" u.a. Das Feld "accountExpires" ist eigentlich auch nur für die DCs der Anmeldedomäne relevant, da deren KDC die Kerberos-Tickets ausstellt oder NTLM-Anmeldungen überprüft. DCs in anderen Domänen müssen dies nicht wissen.

Ein GC der Objekt-Domäne liefert aber ebenfalls nur partielle Felder, selbst wenn er alle Daten in seiner Domain-Partition hätte.

Dies bedeutet aber auch, dass Programme in Umgebungen mit mehreren Domains darauf Rücksicht nehmen müssen. Wenn ich in dem Fall alle Details eines AD-Objekts erhalten will, muss ich erst die Domäne des Objekts finden und dann einen Domaincontroller in der Domain fragen. Diese zusätzlichen Schritte sind auch erforderlich, wenn Sie etwas ändern möchten. Ein GC ist "ReadOnly"

Das ist auch der Grund, warum Exchange zu allen Domänen eine Verbindung benötigt und nicht nur die GCs bei sich befragt. Das ist bei der Planung der Firewall-Regeln zu berücksichtigen.

Objekte im GC

Ein letzter Aspekt ist die Frage nach den Objekten selbst die im GC oder DC vorliegen. Ausgehend von zwei Domains "ROOT" und "SUB" mit je einem DC "DCROOT" und "DCSUB", die beide auch GC sind, habe ich einige LDAP-Anfragen ausgelöst. 

Mein Fokus liegt auf den Objekten in der Root-Domain, die ich dann über die beiden DCs gesucht und angezeigt habe. Ich hätte genauso gut ein Objekt in der SUB-Domain. Wenn Sie eine Gruppe in der SUB-Domain abfragen dann sind die Werte gerade umgekehrt, d.h. die DCs der SUB-Domain liefern immer alle Daten. Dies gilt insbesondere für Gruppen, die außerhalb der Domain verwendet werden.

Es hat schon einen Grund, warum Exchange jede Gruppe zu einer "Universellen Gruppe" konvertiert, wenn Sie diese mit "Enable-Distributiongroup" als Verteiler aktivieren. Nur so kann Exchange sicher sein, dass die Gruppe auf allen GCs vorhanden und mit Daten gefüllt ist.

Memberof/Member und GC

Bei den Gruppen interessierte mich insbesondere nicht nur, welche Gruppen der LDAP Client bei einer Anfrage bekommt sondern auch wie umfangreich die Mitgliedschaften sind. Ich habe dazu wieder drei Gruppen (ROOTLG, ROOTGG und ROOTUG) in ROOT angelegt und den Benutzer ROOTUser addiert. Auch in der Subdomain habe ich und SUB-User addiert und dann wieder abgefragt.

Auch in der Subdomain habe ich drei Gruppen (SUBLG, SUBGG, SUBUG) und einen Benutzer angelegt.

Die Mitgliedschaften des Users "ROOTUSER" waren dann die drei Gruppen in der ROOT-Domain und die UniversalGroup in der Subdomain

Der Versuch den Benutzer auch noch in die Gruppe "SUBGG" aufzunehmen, ist nicht möglich und wurde mit einem Fehler quittiert:

Ich konnte den Benutzer aber in die SUBLG, also eine "Domain lokale Gruppe" der anderen Domain aufnehmen. Das kan ich zwar nicht in den Eigenschaften des Benutzers sehen aber sehr wohl in der Gruppe selbst:

So vorbereitet habe ich nun wieder meine Anfragen nach dem ROOTUSER und dessen "MemberOf"-Attribut gestellt:

(Get-ADObject `
   -LDAPFilter "(samaccountname=ROOTUSER)" `
   -Server <dc>:<port> `
   -Properties memberof `
).memberof

Ich habe die Ergebnisse genau so erwartet aber trifft das auch für Sie als Leser zu?:

CN=ROOTUG,OU=DCGC-Test,DC=carius,DC=de
CN=ROOTGG,OU=DCGC-Test,DC=carius,DC=de
CN=ROOTLG,OU=DCGC-Test,DC=carius,DC=de
CN=SUBUG,OU=DCGC-Test,DC=sub,DC=carius,DC=de

CN=ROOTUG,OU=DCGC-Test,DC=carius,DC=de
CN=ROOTGG,OU=DCGC-Test,DC=carius,DC=de
CN=ROOTLG,OU=DCGC-Test,DC=carius,DC=de
CN=SUBUG,OU=DCGC-Test,DC=sub,DC=carius,DC=de

Objekt nicht gefunden!

CN=ROOTUG,OU=DCGC-Test,DC=carius,DC=de
CN=SUBUG,OU=DCGC-Test,DC=sub,DC=carius,DC=de
CN=SUBLG,OU=DCGC-Test,DC=sub,DC=carius,DC=de

Nun verstehen sie auch, warum alle Gruppen, die in Exchange OnPremises als Verteiler genutzt werden, zwingend "Universelle Gruppen" sein müssen und darum Exchange eine bestehende Gruppe beim "Enable-Distributiongroup" zu einer universellen Gruppe.

Wer Gruppen richtige auflösen will, MUSS das mit universellen Gruppen machen. "DomainLocal"-Groups sind im GC gar nicht zu finden aber auch "DomainLocal"-Gruppen bekommt man nur von den Domains, in denen der GC ist. Das ist dann auch bei der Anwendung von Gruppenrichtlinien ein Thema, die dann ggfls. nicht greifen. Bei Berechtigungen auf Dateiserver ist das Risiko geringer, weil hier selten mit einem DENY gearbeitet wird und es nur auffällt, wenn ein Benutzer keine Berechtigungen hat.

• Verteiler und Gruppen
• Windows Gruppen und Berechtigungen
• Exchange Mixed Group
• Abfragebasierte Verteiler
• DL Management mit EXO
• Gruppenrichtlinien
• Manage distribution groups
  https://learn.microsoft.com/en-us/exchange/recipients/distribution-groups
• Enable-DistributionGroup
  https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/enable-distributiongroup?view=exchange-ps

Was ist mit Forest Trusts

Bislang hat sich meine Analyse immer nur auf Objekte im gleichen Forest bezogen. Sie können natürlich für die Funktion eines "Trust" auch Domains zwischen unterschiedlichen Forests oder komplette Forests "Transitiv" miteinander verbinden. Für die Auswertung von Gruppen über DC/GC-Abfragen hat das aber keine echte Auswirkung. Schauen Sie sich einfach einmal an, in welche der vier Gruppen ein Benutzer einer anderen per externem Trust verbundenen Domain Mitglied sein kann:

Gruppe	Mitgliedschaft	Beschreibung
AD/Universal Group		Ein Benutzer aus einer per External Trust angebundenen Domain kann nicht in eine Universelle Gruppe einer anderen Domain aufgenommen werden. Damit gibt es keine Änderung der Auflösung von Gruppen über "Member" bei so einer Gruppe oder MemberOf beim Benutzer.
AD/Domain Global Group		Ein Benutzer aus einer per External Trust angebundenen Domain kann nicht in eine "Domain Global Group" einer anderen Domain aufgenommen werden. Damit gibt es keine Änderung der Auflösung von Gruppen über "Member" bei so einer Gruppe oder MemberOf beim Benutzer.
AD/Domain Local Group		Ein Benutzer aus einer per External Trust angebundenen Domain kann in eine "Domain Local Group" einer anderen Domain aufgenommen werden. Eine "Domain Local Group" gibt es aber nur auf dem Domain Controller selbst und kann nicht auf einem Member Server referenziert werden. Der Nutzen ist eigentlich nicht vorhanden, auch wenn es theoretisch möglich ist. Ich habe es nicht weiter untersucht.
MEMBER/Lokale Gruppe		Sie können aber einen Benutzer einer per External Trust angebundenen Domain sehr wohl in eine lokale Gruppe eines Memberservers aufnehmen. Das macht Sinn, wenn der Server einen Dienst, z.B. SMB-Share, bereitstellt und sie eine lokale Gruppe für die Vergabe der Berechtigungen anlegen, in die dann Benutzergruppen als Mitglied aufgenommen werden. Diese lokalen Gruppen sind aber, wie der Name schon sagt, lokal und nicht im Active Directory. Sie werden daher auch niciht aufgelöst.

Externe Trusts spielen daher nicht wirklich eine Rolle.

Weitere Links

• AD-Site
• Root.local-Domain
• Domainanmeldung
• Windows Gruppen und Berechtigungen
• Verteiler und Gruppen
• Exchange Mixed Group
• Abfragebasierte Verteiler
• DL Management mit EXO
• Active Directory Domain Services overview
  https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview
• Active Directory Security Groups
  https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups
• Forests - Win32 apps | Microsoft Learn
  https://learn.microsoft.com/en-us/windows/win32/ad/forests
• Naming Contexts and Directory Partitions
  https://learn.microsoft.com/en-us/windows/win32/ad/naming-contexts-and-partitions
• About Application Directory Partitions - Win32 apps
  https://learn.microsoft.com/en-us/windows/win32/ad/about-application-directory-partitions
• Active Directory Replication Concepts
  https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/replication/active-directory-replication-concepts
• Impact on Directory-Enabled Applications - Win32 apps
  https://learn.microsoft.com/en-us/windows/win32/ad/impact-on-directory-enabled-applications
• Planning Global Catalog Server Placement | Microsoft Learn
  https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/planning-global-catalog-server-placement