AGDLP: Microsofts Best Practice für Active Directory und warum wir bewusst darauf verzichten
Was steckt hinter Microsofts Gruppenstruktur-Empfehlung, wo liegt der Haken und wie löst der BAYOOSOFT Access Manager das Problem auf eine smartere Art?
Wenn IT-Administrator:innen über Berechtigungsmanagement in Active Directory sprechen, fällt früher oder später das Kürzel AGDLP. Es ist Microsofts offizielle Empfehlung für die Strukturierung von Gruppen und Zugriffsrechten in Windows-Domänen, gut dokumentiert, weit verbreitet und in der Theorie ein ordentliches Konzept. Der BAYOOSOFT Access Manager folgt dieser Empfehlung jedoch bewusst nicht vollständig. Kein Versehen, kein Kompromiss, sondern eine begründete technische Entscheidung. Dieser Artikel erklärt, was AGDLP ist, warum das Prinzip in der Praxis an seine Grenzen stößt und wie der BAYOOSOFT Access Manager das Problem intelligenter löst.
Was AGDLP bedeutet und warum Microsoft es empfiehlt
Das Akronym steht für Accounts (Benutzer- und Computerkonten), Global Groups (globale Gruppen), Domain Local Groups (domänenlokale Gruppen) und Permissions (Berechtigungen) und beschreibt die Reihenfolge, in der Benutzerkonten und Gruppen in einer Windows-Domäne verschachtelt werden sollen. Das Grundprinzip ist rollenbasiert: Ein Benutzerkonto (A) wird Mitglied einer globalen Gruppe (G), die eine Geschäftsrolle abbildet, also zum Beispiel „Buchhaltung“ oder „Projektleitung“. Diese globale Rollengruppe wird dann in eine domänenlokale Gruppe (DL) eingebettet, die wiederum konkrete Zugriffsrechte auf eine Ressource hält, etwa Lesen oder Schreiben auf einen Netzwerkordner. Die domänenlokale Gruppe ist damit die einzige Stelle in der ACL (Access Control List), an der Berechtigungen tatsächlich vergeben werden (P).
Die Logik dahinter ist nachvollziehbar. Wechselt eine Mitarbeiterin die Abteilung, genügt es, sie aus der alten globalen Gruppe zu entfernen und der neuen hinzuzufügen. Alle Ressourcenzugriffe folgen automatisch. Niemand muss einzelne Ordner-ACLs anfassen. Außerdem verhindert das Modell sogenannte verwaiste SID-Einträge in den ACLs, also Überreste gelöschter Benutzerkonten, die sich sonst über die Jahre aufhäufen. Bei konsequenter Umsetzung wirkt sich AGDLP positiv auf Transparenz und Active Directory-Sicherheit aus.
Klingt gut, und in der Theorie ist es das auch. Für Umgebungen mit mehreren Domänen oder Gesamtstrukturen ist die G-Ebene sogar technisch notwendig, weil globale Gruppen über Domänengrenzen hinweg verwendbar sind und so die domänenlokalen Ressourcengruppen aus beliebigen Domains befüllt werden können. Kurz gesagt: AGDLP löst ein Multi-Domain-Problem.
Die Nachteile von AGDLP: Wo das Prinzip in der Praxis an seine Grenzen stößt
Die Schattenseite von AGDLP ist gut dokumentiert, wird aber in vielen IT-Teams immer noch unterschätzt.
1. Der Initialaufwand ist erheblich:
Für jede Rolle und jede Ressource braucht es mindestens zwei Gruppen statt einer, die globale Rollengruppe und die domänenlokale Berechtigungsgruppe. Das verdoppelt den Gruppenbestand in Active Directory mindestens. Die benötigten Strukturen müssen vollständig manuell in der Active Directory-Konsole aufgebaut werden, Standardwerkzeuge gibt es dafür nicht. Das macht das Modell arbeits- und kostenintensiv und an jeder Stelle, an der ein Mensch eingreifen muss, potenziell fehleranfällig. Wer schon einmal ein AD mit ein paar hundert Ordnern, Druckern und Anwendungen strukturiert hat, weiß, was das in der Praxis bedeutet.
2. Abkürzungen untergraben das gesamte Modell:
Das Modell steht und fällt mit konsequenter Disziplin: Sobald jemand Berechtigungen einmal direkt an eine globale Gruppe vergibt, „nur dieses eine Mal“, beginnt die Struktur zu erodieren. Bevor man es bemerkt, ist die gesamte AGDLP-Logik ausgehebelt. Das Modell steht und fällt mit konsequenter Disziplin bei jeder einzelnen Berechtigungsvergabe, über Jahre hinweg, durch wechselnde Teams.
3. Im Single-Domain-Betrieb ist die G-Ebene technisch überflüssig:
Globale Gruppen entfalten ihren Mehrwert erst dort, wo Benutzer aus verschiedenen Domänen gemeinsam auf Ressourcen berechtigt werden müssen. Wer nur eine Domäne betreibt, löst mit AGDLP ein Problem, das schlicht nicht existiert und zahlt dafür trotzdem den vollen administrativen Preis.
4. Nachträgliche Migrationen sind extrem aufwendig:
Bestehende, historisch gewachsene Berechtigungsstrukturen auf AGDLP umzustellen, bedeutet Gruppen umbenennen, Typen ändern, alte und neue Gruppen parallel pflegen, alles manuell, mit erheblichem Risiko für Zugriffsunterbrechungen.
Das Token-Size-Problem: Wenn User sich nicht mehr anmelden können
Es gibt noch ein technisches Problem, das im Alltag kaum jemand auf dem Schirm hat, bis es zum ernsthaften Vorfall wird: Die Kerberos-Token-Größe.
Jedes Mal, wenn sich ein Benutzer am System authentifiziert, stellt Windows ein Kerberos-Ticket aus. Dieses Ticket enthält nicht nur die Benutzeridentität, sondern auch die SIDs aller Sicherheitsgruppen, in denen der Benutzer Mitglied ist, direkt und indirekt. Die Formel dafür stammt direkt aus der Microsoft-Dokumentation:
TokenSize = 1200 + 40d + 8s
Dabei steht d für Mitgliedschaften in domänenlokalen Gruppen und universellen Gruppen außerhalb der eigenen Domäne (jede: 40 Bytes), und s für Mitgliedschaften in globalen Gruppen sowie sonstigen Gruppen innerhalb der Domäne (jede: 8 Bytes).
Mit dem alten Standard-Grenzwert von 12.000 Bytes (bis Windows Server 2008 R2) konnte bereits die Mitgliedschaft in mehr als etwa 120 universellen Gruppen zu Authentifizierungsfehlern führen. Auf modernen Systemen (ab Server 2012) liegt der Standard bei 48.000 Bytes, aber der Grundsatz bleibt: Je mehr Gruppen durch verschachtelte AGDLP-Strukturen akkumuliert werden, desto näher rückt man dieser Grenze. Werden diese Grenzen überschritten, schlägt die Authentifizierung fehl, der Benutzer kann sich nicht mehr anmelden. Gruppenrichtlinien werden unter Umständen nicht mehr angewendet. In größeren, historisch gewachsenen Umgebungen mit tiefer AGDLP-Verschachtelung ist das kein theoretisches Szenario, sondern ein reales Risiko. Der maximale Wert von 65.535 Bytes ist zwar technisch setzbar, wird von Microsoft aber ausdrücklich nicht empfohlen, unter anderem wegen bekannter Probleme mit IIS.
Bei AGDLP wird dieses Problem strukturell verstärkt: Jede globale Gruppe, die in viele domänenlokale Gruppen eingebettet wird, akkumuliert für jeden darin enthaltenen Benutzer entsprechend viele domänenlokale Gruppen-SIDs im Token. Je tiefer die Verschachtelung, desto schneller wächst der Token.
Wie der BAYOOSOFT Access Manager Gruppenstrukturen intelligent an die Umgebung anpasst
Der BAYOOSOFT Access Manager folgt nicht einem einzigen festen Gruppenmodell, sondern wählt je nach Umgebung die technisch überlegene Struktur. Das Ziel dabei ist immer dasselbe: minimale Kerberos-Token-Belastung bei maximaler Sicherheit und Compliance.
AGP im Single-Domain-Betrieb
In Single-Domain-Umgebungen arbeitet der Access Manager nach dem AGP-Prinzip: Accounts werden direkt globalen Gruppen (G) zugewiesen, die dann die Berechtigungen (P) halten. Domänenlokale Gruppen entfallen vollständig. Da globale Gruppen laut Microsoft-Formel nur 8 Bytes pro Mitgliedschaft zum Kerberos-Token beitragen statt 40 Bytes wie domänenlokale Gruppen, ist das die tokeneffizienteste Variante überhaupt. Hinzu kommt ein kleiner Security-Vorteil: Globale Gruppen können ausschließlich Objekte der eigenen Domäne aufnehmen, was den Scope automatisch auf die eigene Umgebung beschränkt.
Sobald Benutzer oder Gruppen aus mehreren Domänen auf gemeinsame Ressourcen zugreifen müssen, kommen domänenlokale Gruppen ins Spiel, weil nur sie domänenübergreifende Mitgliedschaften erlauben. Der Access Manager arbeitet in diesem Fall nach ADLP: Accounts werden direkt domänenlokalen Gruppen (DL) zugeordnet, die die Berechtigungen (P) halten. Die G-Ebene aus AGDLP entfällt. Jede domänenlokale Mitgliedschaft kostet 40 Bytes im Kerberos-Token, der Aufwand ist also höher als im Single-Domain-Modus. Er ist aber technisch begründet und wird nicht durch eine zusätzliche Verschachtelungsebene weiter erhöht.
Optimierter Multi-Domain-Modus: ADLP und AGP parallel
Für Multi-Domain-Umgebungen mit hohen Anforderungen an die Token-Effizienz bietet der Access Manager einen optimierten Modus, der beide Gruppentypen kombiniert. Pro Ressource existieren dabei sowohl eine globale als auch eine domänenlokale Gruppe in der ACL, nicht verschachtelt wie bei AGDLP, sondern parallel. Benutzer werden dann je nach ihrer Domänenzugehörigkeit automatisch in die jeweils tokenguenstigere Gruppe einsortiert: Benutzer aus der eigenen Domäne landen in der globalen Gruppe (8 Bytes), Benutzer aus Fremddomänen in der domänenlokalen Gruppe (40 Bytes). Die ACL eines Objekts wird dadurch etwas größer, aber jeder einzelne Benutzer zahlt exakt den Token-Preis, den seine Umgebung technisch erfordert. Nicht mehr.
In allen drei Modi gilt: Der Access Manager legt die erforderlichen Gruppen vollautomatisch an, pflegt Mitgliedschaften und korrigiert nicht autorisierte Änderungen proaktiv. Die Abhängigkeit von menschlicher Disziplin bei der Strukturpflege, das Kernproblem von AGDLP, entfällt vollständig.
Welches Gruppenmodell passt zu welcher Umgebung?
Microsofts AGDLP-Empfehlung ist nicht falsch, sie ist für einen bestimmten Kontext optimiert: manuelle Verwaltung in Multi-Domain-Umgebungen. Wer diesen Kontext nicht hat, zahlt für etwas, das ihm keinen Mehrwert bringt, und riskiert dabei die Token-Size-Problematik obendrauf.
Der BAYOOSOFT Access Manager löst dieses Problem nicht durch ein einzelnes alternatives Gruppenmodell, sondern durch intelligente Anpassung an die jeweilige Umgebung. Im Single-Domain-Betrieb sorgt AGP für minimale Token-Belastung und einen natürlichen Security-Scope. Im Multi-Domain-Betrieb ermöglicht ADLP die notwendige domänenübergreifende Flexibilität. Und der optimierte Multi-Domain-Modus kombiniert beide Ansätze so, dass jeder Benutzer immer in der tokenguenstigsten Gruppe landet.
Das BSI schreibt im IT-Grundschutz als Basis-Anforderung (OPS.1.1.1.A2) verpflichtend vor, dass für alle betriebenen IT-Komponenten ein Rollen- und Berechtigungskonzept festgelegt werden muss. Welches technische Gruppenmodell dabei zum Einsatz kommt, lässt der Standard bewusst offen. Mit dem BAYOOSOFT Access Manager lässt sich dieses Konzept sauber und revisionssicher umsetzen, für Fileserver, SharePoint, Active Directory und angebundene Drittsysteme gleichermaßen.
