Inkonsistente Berechtigungen im Global Catalog
Wer mit Hilfe von Active Directory Gruppen Berechtigungen auf Ressourcen vergibt, macht dies häufig nach dem empfohlenen Prinzip:
- Berechtigungen an lokale Gruppen binden.
- Globale oder universelle Gruppen in die lokalen verschachteln.
- Benutzer den globalen Gruppen hinzufügen
Vergibt man auf diese Weise Berechtigungen im Active Directory auf AD-Objekte, kann es unerwartete Resultate zur Folge haben…
Index
Global Catalog Problem:
Benutzer in gleicher lokalen Gruppe – Attribut aber nicht sichtbar
Das folgende Beispiel soll inkosistente Berechtigungen im Global Catalog und seine Folgen besser verdeutlichen:
Ein Forest besteht aus zwei Domänen:
- Domäne1 und
- Domäne2
In jeder Domäne ist mindestens ein Domain-Controller Global Catalog (GC) Server.
In der Domäne 1 wurde eine lokale Gruppe erstellt. Diese lokale Gruppe wurde berechtigt, ein bestimmtes Attribut eines Benutzers im AD lesen zu können, was z.B. für alle anderen Benutzer nicht sichtbar ist. Dieses Attribut wird auch in den GC repliziert.
Mitglied dieser Gruppe ist eine universelle Gruppe mit je einem Benutzer aus jeder Domäne.
Der Unterschied ist, wenn…
- …Benutzer1 aus Domäne1 auf den Global Catalog zugreift, kann er das Attribut problemlos lesen.
- …Benutzer2 aus Domäne2 dies nun auf seinem GC versucht, sieht er das Attribut nicht.
Wie kommt das? Benutzer2 ist doch genau wie Benutzer1 Mitglied der universellen Gruppe und die GCs in beiden Domänen halten auch dieselben Informationen.
Ursache: Ressource nicht in der gleichen Domäne
Die Ursache hierfür ist, dass wir eine grundsätzliche Regel für die oben genannte Berechtigungsvergabe missachtet haben:
Die Ressource muss sich in derselben Domäne befinden, wie die lokale Berechtigungsgruppe.
In diesem Fall ist jedoch der GC in Domäne 2 in einer anderen Domäne als die lokale Gruppe.
Die SIDs von lokalen Gruppen werden aber nur in derselben Domäne in das Benutzertoken aufgenommen. Aus diesem Grund hat der Benutzer aus Domäne 2 beim Zugriff auf einen GC aus Domäne 2 keine SID für die lokale Gruppe in seinem Token. Daher erhält er auch keine Berechtigung auf das Attribut.
Lösungsvorschlag
Zur Vermeidung des Problems, sollte man in diesem speziellen Fall man die Berechtigungen direkt an universelle Sicherheitsgruppen vergeben.
Die FirstAttribute AG ist spezialisiert auf Active Directory Projekte und Migrationen.
Stellen Sie uns gern Ihre Frage zu AD Konsolidierung, Konzeptionierung oder zur Anbindung an andere Systeme.
Leave a Reply
Danke für Ihre Anregungen, Fragen und Hinweise. Unsere Datenschutzerklärung finden Sie hier: https://www.active-directory-faq.de/datenschutzerklaerung/