AD Berechtigungen : Der AdminSDHolder Mechanismus
AdminSDHolder
Beim Umgang mit Active Directory Objektberechtigungen bemerken AD Administratoren des Öfteren einen seltsamen Effekt: Berechtigungen, die man auf Ebene einer bestimmten OU gesetzt hat, gelten auf einmal nicht mehr auf bestimmte Benutzer oder Gruppen, dies sich in der betreffenden OU befinden. Ein Helpdesk-Mitarbeiter oder User-Admin kann hier auf einmal nicht mehr das Passwort eines bestimmten Benutzers zurücksetzen, er kann keine Telefonnummer oder Mail-Adresse im Benutzerkonto ändern, oder er kann einer Gruppe keine neuen Mitglieder hinzufügen. Stets lautet die Fehlermeldung: Zugriff verweigert / Keine ausreichenden Berechtigungen.
Wenn man das Phänomen näher untersucht, stellt man fest, dass hier die Vererbung der Berechtigungen am Objekt selbst deaktiviert ist: Die auf der OU darüber gesetzten Berechtigungen gelten nicht für das Objekt:
Noch seltsamer: Will man dies korrigieren und aktiviert die Rechte-Vererbung wieder (Häkchen setzen bei "Include inheritable permissions from the object's parent"), dann sind die Berechtigungen eine Weile normal, nach ca. einer Stunde ist die Vererbung wieder aufgehoben!
Was geht hier vor? Ganz einfach, der AdminSDHolder-Mechanismus ist der Grund:
- Ein Prozess namens SDPROP (Security Descriptor Propagation) ist auf dem PDC Emulator der jeweiligen Active Directory Domäne automatisch alle 60 Minuten aktiv. Wie man die Frequenz beeinflussen kann, wird weiter unten beschrieben.
- Der Prozess sucht nach sogenannten Protected Objects. Dies sind hoch privilegierte, fürs AD lebenswichtige Objekte, z.B. Mitglieder der Gruppen "Domänen-Admins" oder "Schema Admins". Eine genaue Auflistung der Protected Objects folgt weiter unten.
- Für jedes Protected Object wird die Rechte-Vererbung deaktiviert und als Berechtigung wird eine Kopie der ACL des AdminSDHolder Containers ans Objekt gehängt. Der AdminSDHolder Container befindet sich in jeder Domäne im "System" Container und enthält sozusagen die Blaupause der Berechtigung die für die Protected Objekts gelten soll.
- Wenn Berechtigungen eines Protected Objects manipuliert wird, dann wird gleichzeitig auch das Attribut "adminCount" erzeugt und auf 1 gesetzt.
- Stellt SDPROP fest, dass ein Protected Object bereits eine deaktivierte Rechtevererbung und eine Kopie der AdminSDHolder-Rechte hat, dann wird für das Objekt nicht verändert. Es wird also auch das adminCount-Attribut nicht auf 1 gesetzt!
Dies ist der Grund für die mysteriöse Manipulation an den Berechtigungen der betroffenen Accounts. Active Directory schützt hier Benutzer, die als wichtig angesehen werden, weil Sie in wichtigen System-Gruppen Mitglied sind. Es wird sozusagen dafür gesorgt, dass ein Domänen-Admin nur von einem anderen Domänen-Admin verändert oder gelöscht werden darf, und nicht durch einen Mitarbeiter des normalen Helpdesks.
Beschreibung des AdminSDHolder Mechanismus in der Microsoft Open Specification
Beschreibung des AdminSDHolder Mechanismus in der Microsoft Knowledge Base
Das Ärgerliche am AdminSDHolder Mechanismus: Er ist schlecht beim "Aufräumen". Denn wenn ein User wieder aus einer der hoch privilegierten Systemgruppen entfernt wird und kein Protected Object mehr ist, bleibt die Deaktivierung der Vererbung trotzdem bestehen! Auch der das Attribut adminCount bleibt einfach unverändert auf 1.
Das Attribut adminCount
Verändert der AdminSDHolder Mechanismus die Access Control List eines Objektes, dann wird auch das Attribut adminCount auf 1 gesetzt.
Es existiert hier häufig der Irrtum, dass dies ein zuverlässiger Indikator oder sogar ein Kriterium für die Auswahl als Protected Object sei. Das ist nicht der Fall. Merken Sie sich folgende Fakten:
- Nicht alle Objekte, die den Wert adminCount = 1 gesetzt haben, unterliegen dem AdminSDHolder Mechanismus. Wenn ein Benutzerkonto z.B. wieder aus den Enterprise-Admins entfernt wird und dadurch nicht mehr Protected Object ist, so bleibt der Wert 1 trotzdem im adminCount.
- Nicht alle Protected Objects mit deaktivierter Vererbung haben einen adminCount Wert von 1. Wenn man dieses Attribut nämlich von Hand löscht oder auf 0 setzt, dann wird das System deswegen nicht die Vererbung wieder aktivieren und die ACL des Objektes auf Normalzustand zurückversetzen! Vielmehr erkennt der SDPROP Prozess, dass diese Protected Object die Berechtigungen so gesetzt hat wie das AdminSDHolder-Objekt, und dass die Vererbung blockiert ist: Das Objekt wird nicht mehr angefasst, und der Wert adminCount bleibt so wie er ist.
Warum existiert adminCount dann überhaupt? Gute Frage. Es handelt sich dabei wohl um ein Überbleibsel aus Windows 2000 Zeiten, wo es den SDPROP-Prozess beschleunigen sollte. Mittlerweile ist es zu Nichts anderem gut als dem kurzen Check:
- Wer war in der Vergangenheit einmal in einer hoch privilegierten Gruppe? - Allerdings ohne Garantie auf Vollständigkeit des Ergebnisses.
Die Suche nach Objekten mit einem entsprechenden adminCount Wert wäre mit dem einfachen LDAP-Filter (adminCount=1) möglich. Wie gesagt: Es wäre ein trügerische Ergebnis. Lieber sucht man direkt nach Protected Objects über die Gruppenmitgliedschaften oder noch besser über deren ACLs.
Protected Objects
Folgende Objekte sind Protected Objects im Sinne des AdminSDHolder Mechanismus:
| User | Administrator Krbtgt |
| Gruppen | Account Operators Administrators Backup Operators Cert Publishers (nur bis Windows 2000) Domain Admins Domain Controllers Enterprise Admins Read-only Domain Controllers (erst ab Windows Server 2008) Replicator Schema Admins Server Operators |
Bei den Gruppen verhält es sich so, dass jedes direkte und indirekt Mitglied dieser Gruppen zum Protected Object wird! Ist also z.B. in den Kontenoperatoren (Account Operators) eine Gruppe "G_HelpDesk" enthalten, so wird diese Gruppe zusammen mit allen darin enthaltenen Benutzern zu Protected Objects und vom AdminSDHolder Mechanismus entsprechend verändert.
Man kann Active Directory so konfigurieren, dass einige dieser Gruppen nicht mehr zu den Protected Objects gehören. Dazu muss jedoch das globale Bitfeld dsHeuristics verändert werden. Es handelt sich hier um einen AD Konfigurationswert, der global als Attribut in der Config-Partition des Active Directory gespeichert wird. Seien Sie bitte stets vorsichtig, wenn Sie den dsHeuristics Wert ändern wollen - er hat stets weit reichende Auswirkungen! am besten Sie speichern sich VOR der Änderung den alten Wert dieses Attributes.
Um dsHeuristics zu ändern, öffnet man das Objekt CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=example,DC=com, wobei Sie für example.com natürlich Ihre eigene Root-Domäne des Active Directory Forests einsetzen müssen. In diesem Objekt gibt es entweder bereits ein Attribut namens dsHeuristics, oder man erzeugt es. Das Attribut ist ein normaler String, der jedoch ein Bitfeld kodiert, d.h. jeder Buchstabe steht für ein Bit, dass die Werte 0-1 oder a-f annehmen kann.
Die Bits werden dann einfach von links nach rechts abgezählt (mit 1 beginnend), wobei die Länge von dsHeuristics unterschiedlich sein kann, falls man Bits an höheren Stellen nicht benötigt wird der String einfach abgeschnitten.
Sie können nun innerhalb des dsHeuristics Feldes bestimmen, dass eine oder mehrere der folgenden Gruppen NICHT mehr Protected Objects sind und auch nicht mehr im AdminSDHolder-Mechanismus berücksichtigt werden:
- Account Operators (Konten-Operatoren)
- Server Operators
- Print Operators
- Backup Operators
Dazu müssen wir das 16. Bit (wie schon erwähnt, die Bits werden von links nach rechts bei 1 beginnend durchgezählt) in dsHeuristics verändern. Das Bit trägt die Bezeicnhung dwAdminSDExMask. Folgende Werte für diese Bit sind möglich:
| Wert | Gruppen, die nicht mehr Protected Objects sind: |
| 0 | Keine - dies ist der Standard |
| 1 | Account Operators |
| 2 | Server Operators |
| 3 | Server Operators + Account Operators |
| 4 | Print Operators |
| 5 | Print Operators + Account Operators |
| 6 | Print Operators + Server Operators |
| 7 | Print Operators + Server Operators + Account Operators |
| 8 | Backup Operatos |
| 9 | Backup Operators + Account Operators |
| a | Backup Operators + Server Operators |
| b | Backup Operators + Server Operators + Account Operators |
| c | Backup Operatos + Print Operators |
| d | Backup Operatos + Print Operators + Account Operators |
| e | Backup Operatos + Print Operators + Server Operators |
| f | Backup Operatos + Print Operators + Server Operators + Account Operators |
Sollte das dsHeuristics-Attribut nicht vorhanden sein, dann setzen Sie es auf den Wert 000000000100000x - wobei x dann der gewünschte Wert von dwAdminSDExMask aus der Tabelle ist. also z.B. 000000000100000a, falls Sie Backup-Operatoren und Server-Operatoren aus den Protected Objects ausschließen sollen. Das 10. Bit muss übrigens stets auf 1 gesetzt werden, falls dsHeuristics länger als 10 Bits lang ist.
Falls das Attribut bereits vorhanden ist, sollte man die anderen Bits in Ruhe lassen und nur die 16. Stelle ändern - falls der bisherige Wert weniger als 10 Stellen hatte, muss man die Stellen bis 16 mit 0 auffüllen, wobei das 10. Bit auf 1 gesetzt wird - es signalisiert, dass sdHeuristics mehr als 10 Stellen lang ist.
Man kann das dsHeuristics Wert z.B. mit ADSI-Edit setzen...
... oder auch mit jedem normalen LDAP-Editor (mein eigener kommerzielles LDAP Browser "LEX - The LDAP Explorer" hat sogar einen eigenen bequemen Attribut-Editor für das dsHeuristics-Attribut):
Das Editieren des dsHeuristics Attributs sollte jedoch stets sehr sorgfältig und auf keinen Fall ohne gründliche Überlegung geschehen, denn mit dsHeuristics beeinflusst man die Konfiguration des gesamten Forests! Falls man aus Versehen ein anderes Bit in diesem Attribut setzt, weil man sich bei der Stelle verzählt, dann verändert man womöglich das Verhalten der Domänencontroller in wichtigen, Sicherheits-relevanten Bereichen! Zusätzliche Informationen:
Beschreibung der dwAdminSDExMask-Bits in der Microsoft Open Specification
Was tun, um auf ein Protected Object zugreifen zu können?
In unserem Szenario war der AdminSDHolder Mechanismus der Grund dafür, dass z.B. ein nieder-privilegierter User-Admin ein Protected Object nicht verändern konnte (z.B. um das Passwort zurückzusetzen). Vielleicht möchten Sie dieses Systemverhalten ändern. Es gibt jetzt drei Varianten, dieses zu erreichen:
- Sorgen Sie dafür, dass das Objekt nicht mehr zu den Protected Objects gehört, indem Sie es aus den jeweiligen hoch privilegierten Gruppen (Liste der Protected Objects) entfernen. Nachdem die Mitgliedschaft aufgehoben ist, darf man jedoch nicht vergessen, auch die Rechte-Vererbung am Objekt selbst wieder zu aktivieren. Wenn man ganz sorgfältig ist, könnte man auch das Attribut adminCount bei dem betreffenden Objekt auf 0 setzen oder löschen. Damit ist der Urzustand wiederhergestellt.
- Konfigurieren Sie Ihr Active Directory so, dass die betreffende hoch privilegierte Gruppe vom System nicht mehr als Protected Object angesehen wird. Dies wirkt sich jedoch global auf alle Domänen Ihres AD Forests aus, es handelt sich also um eine weit reichende Änderung, die gut überlegt sein will!
Um zu bestimmen, welche der vordefinierten Gruppen zu den Protected Objects gehören und welche nicht, dient das Attribut dsHeuristics. Dieser Vorgang ist im vorangegagnenen Abschnitt detailliert beschrieben. Nachdem diese Konfiguration vorgenommmen wurde, darf man jedoch nicht vergessen, auch die Rechte-Vererbung am Objekt selbst wieder zu aktivieren. Wenn man ganz sorgfältig ist, könnte man auch das Attribut adminCount bei dem betreffenden Objekt auf 0 setzen oder löschen. Damit ist der Urzustand wiederhergestellt.
- Wenn das betreffende Objekt ein Protected Object bleiben soll und der besagte User-Admin trotzdem z.B. das Kennwort ändern können soll, dann fügen Sie den User-Admin (oder die Gruppe der User-Admins) direkt in die Rechte-Vorlage am AdminSDHolder-Objekt ein. AdminSDHolder befindet sich im System-Container der Domäne (dieser wird erst sichtbar, wenn sie die Erweiterte Ansicht innerhalb von AD Users and Computers aktivieren).
Nachdem diese Rechte-Vorlage geändert wurde, sorgt der SDPROP-Prozess innerhalb der nächsten 60 Minuten dafür, dass die neue Berechtigung auf allen Protected Objects aktiv wird. Beachten Sie hierbei jedoch: Diese Berechtigung gilt dann tatsächlich für ALLE Protected Objects - also z.B. dann auch für die vordefinierten administrativen Systemgruppen - und zwar in der gesamten Domäne. Seien Sie also vorsichtig mit der Rechtevergabe. In unserem Fall sollte man z.B. auf keinen Fall die User-Admins mit Vollrechten zu den AdminSDHolder-Berechtigungen hinzufügen, denn damit hätten sie auch volle Kontrolle über die Domain-Admin Gruppen. Statt dessen würde man das Recht hinzufügen, Passwort-Rücksetzungen für User-Objekte vorzunehmen.
SDPROP - Frequenz ändern oder Manuell triggern
Der DSPROP-Prozess, der nach Protected Objects sucht und deren Berechtigungs-ACL ändert, läuft normalerweise alle 60 Minuten. Sie können diese Frequenz ändern, indem Sie in der Registry des Domänen Controllers mit der PDC Emulator Rolle folgenden Wert setzen bzw. erzeugen:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\AdminSDProtectFrequency (REG_DWORD)
Sie können hier Werte zwischen 60 (=1 Minute) und 7200 (= 2 Stunden) eingeben. Allerdings empfiehlt Microsoft, die SDPROP-Frequenz nur für Testzwecke über einen kurzen Zeitraum hinweg zu ändern, da hier die CPU-Last durch das beteiligte LSASS (Local Security Authority SubSystem) den Domänencontroller u.U. schwer belastet.
Sie können den DSPROP-Prozess und damit den AdminSDHolder-Mechanismus auch manuell auslösen, indem Sie über das LDAP-Protokoll ein spezielles Signal an den PDC-Emulator der Domäne senden. Es handelt sich hierbei um eine so genannt RootDSE Modify Operation: Man schreibt einen Wert in ein spezielles Attribut des obersten Wurzel-Objektes des Verzeichnisdienstes, dem RootDSE (Directory Service Entry). In Wirklichkeit existiert dieses Attribut gar nicht, sondern die Schreiboperation gibt dem betreffenden Domänencontroller dann das Signal zum Ausführen einer bestimmten Aktion, in unserem Falle eben dem Triggern des AdminSDHolder-Mechanismus.
- Alle Windows Server-Versionen : RootDSE-Attribut fixupInheritance auf 1 setzen. Für diese Aktion benötigt man das Extended Right "Recalculate-Security-Inheritance" (Extended Rights GUID 62dd28a8-7f46-11d2-b9ad-00c04f79f805).
- Ab Windows 2008 R2 : RootDSE-Attribut runProtectAdminGroupsTask auf 1 setzen. Für diese Aktion benötigt man das Extended Right "Run-Protect-Admin-Groups-Task" (Extended Rights GUID 7726b9d5-a4b4-4288-a6b2-dce952e80a7f). Bei modernen Windows-Versionen wird hier der AdminSDHolder-Mechanismus schneller ausgeführt (denn fixupInheritance löst noch andere Checks für AD-Berechtigungen aus, die länger dauern können).
Der Schreibvorgang mit dem in Windows Servern mit gelieferten Tool LDP.EXE: Nach dem Sie hier im Menü Connection - Connect eine Verbindung zum Domänencontroller mit der PDC-Emulator-Funktion hergestellt haben...
...und sich über Connection - Bind mit Username und Passwort angemeldet haben, ...
...öffnen Sie mit Browse - Modify den Dialog zum Übermittlen einer Schreiboperation. Das DN-Feld lassen sie leer, das bedeutet, dass Sie den rootDSE-Eintrag ansteuern. Dort schreiben Sie den Wert 1 in das theoretische "Attibut" fixupInheritance. Der AdminSdHolder Mechanismus wird dann intern getriggert - etwas Gedult brauchen Sie jedoch trotzdem, da es eine Weile dauert, bis die Eigenschaften aller Objekte im Verzeichnis entsprechend untersucht wurden.
Analog zu diesem Vorgang könnten Sie dann auf einem Domänencontroller ab der Version Windows Server 2008 R2 dann anstatt fixupInheritance die Kennung runProtectAdminGroupsTask verwenden und ebenfalls auf den Wert 1 setzen.
Script: Bei welchen Benutzern und Gruppen ist die Vererbung der Rechte unterbrochen?
Hier ist ein Script, mit dem geprüft werden kann, für welche Benutzer und Gruppen innerhalb einer Domäne oder einer OU die Rechte-Vererbung unterbrochen ist. Diese Unterbrechung kann absichtlich konfiguriert und damit gewollt sein, sie könnte jedoch auch ein Nebeneffekt des AdminSDHolder Mechanismus sein.
Tool: Bei welchen Objekten ist die Vererbung der Rechte unterbrochen?
Es gibt ein kostenloses Admin-Utility, mit dem man ganz einfach nachprüfen kann, bei welchen Objekten der Domäne die Rechtevererbung unterbrochen ist: LIZA - Active Directory Analyse für Security, Berechtigungen und ACLs. Hier hilft die Option Search blocked Inheritance. Das Ergebnis wird für die gesamte Domäne angezeigt:
