Printout Header
RSS Feed

AD Berechtigungen : Der AdminSDHolder Mechanismus


AdminSDHolder
Das Attribut adminCount
Protected Objects
Was tun, um auf ein Protected Object zugreifen zu können?
DSPROP - Manuell triggern oder Frequenz ändern
Script: Bei welchen Benutzern und Gruppen ist die Vererbung der Rechte unterbrochen?
Tool: Bei welchen Objekten ist die Vererbung der Rechte unterbrochen?



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:

AD Users and Computers: Benutzer kann Kennwort nicht ändern

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:

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:

  1. 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.

  2. 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:

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:

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...

AD Users and Computers: Benutzer kann Kennwort nicht ändern

... 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):

AD Users and Computers: Benutzer kann Kennwort nicht ändern

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 von dsHeuristics in der Microsoft Open Specification
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:

  1. 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.

  2. 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.

  3. 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).

    AD Users and Computers: Benutzer kann Kennwort nicht ändern

    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.

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...

AD Users and Computers: Benutzer kann Kennwort nicht ändern

...und sich über Connection - Bind mit Username und Passwort angemeldet haben, ...

AD Users and Computers: Benutzer kann Kennwort nicht ändern

...ö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.

AD Users and Computers: Benutzer kann Kennwort nicht ändern

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.

serverName = "dc01.example.com" 'Hier den Namen des eigenen DCs einfügen baseStr = "ou=funktionen,dc=iv,dc=bwl,dc=net" 'Hier den LDAP Pfad der Domäne oder OU einfügen... '...in der gesucht werden soll Const SE_DACL_PROTECTED = &H1000 filterStr = "(|(objectclass=group)(objectclass=user))" Set dso = GetObject("LDAP:") Set ado = CreateObject("ADODB.Connection") 'Neue ADO Connection erzeugen ado.Provider = "ADSDSOObject" 'Die ADSI-Schnittstelle verwenden ado.Properties("User ID") = "administrator" 'Credentials angeben - wenn sie diese zwei Zeilen weglassen, ... ado.Properties("Password") = "secret" '... wird die aktuellen Anmeldedaten verwendet ado.Properties("Encrypt Password") = True 'nur notwendig, wenn Sie "User ID" und "Password" setzen ado.Open "AD-Search" 'Beliebigen Namen für die Connection vergeben Set adoCmd = CreateObject("ADODB.Command") 'Neues ADO-Kommando erzeugen adoCmd.ActiveConnection = ado 'Zuordnung zur bestehenden ADO-Connection adoCmd.Properties("Page Size") = 1000 'Parameter für Paged Result Suche auf 1000 setzen (=AD Standard) adoCmd.Properties("Cache Results") = True adoCmd.CommandText = "<LDAP://" & serverName & "/" & baseStr & ">;" & filterStr & ";ADsPath;subtree" Set objectList = adoCmd.Execute 'Suche durchführen While Not objectList.EOF Set obj = dso.OpenDSObject(objectList.Fields("ADsPath"), userName, userPass, 1) Set objSecDesc = obj.get("nTSecurityDescriptor") If ((objSecDesc.Control And SE_DACL_PROTECTED) <> 0) Then WScript.Echo adminCount & " " & obj.distinguishedname End If objectList.MoveNext 'zum nächsten gefundenen Objekt Wend

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:

AD Users and Computers: Benutzer kann Kennwort nicht ändern

Tweet