Was ist der AdminSDHolder im lokalen Active Directory und wie funktioniert er?

Jeder, der bereits im lokalen Active Directory mit Administratoren gearbeitet hat, war indirekt schonmal mit der Funktion des AdminSDHolders zu Gange. In diesem kurzen Artikel versuche ich zu erklären, was genau es damit auf sich hat und zu welchen Problemen er auch führen kann, die eigentlich keine sind.

Was ist der AdminSDHolder?

Jeder, der bereits im lokalen Active Directory mit Administratoren gearbeitet hat, war indirekt schonmal mit der Funktion des AdminSDHolders zu Gange. In diesem kurzen Artikel versuche ich zu erklären, was genau es damit auf sich hat und zu welchen Problemen er auch führen kann, die eigentlich keine sind.

Dieser Prozess soll verhindern, dass die Sicherheitsberechtigung an administrativen Konten geändert wird und somit zu viele Domänenadministratoren oder andere Anwender mit höheren Rechten, administrative Tätigkeiten ausführen können. Der Prozess heißt auch „SD Propagator“.

HINWEIS:

Wenn im folgenden Registry-Pfad der Schlüssel „AdminSDProtectFrequency“ nicht gesetzt ist (der standardmäßig nicht existiert), dann lautet das Überprüfungsintervall durch den prozess „SD Propagator“ des PDC-Emulators 60 Minuten. Der Wert kann zwischen 1 Minute (60 Sekunden) und 2 Stunden (7200 Sekunden) liegen.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Wie funktioniert der Überprüfungsprozess?

  1. Es prüft, welche Benutzerkonten direkt oder verschachtelt in einer der geschützten Gruppen sind und setzt dessen Attribute „adminCount“ auf den Wert von größer 0
  2. Alle Benutzerkonten, die einen Wert des Attributs „adminCount“ größer 0 haben, werden auf den Standardwert (der den Rechten des Objekts AdminSDHolder entspricht) zurückgesetzt. Das bedeutet, dass die Rechte die man auf der Registerkarte „Sicherheit“ des Benutzerkontos sieht, zurückgesetzt werden und auch für alle administrativen Konten gilt.
  3. Der Standardwert basiert auf den Berechtigungen des Objektes CN=AdminSDHolder,CN=System,DC=<Domäne>,DC=<TLD> und dient als Vorlage für alle administrativen Konten.
  4. Damit wird ebenfalls die Vererbung durch darüber liegende OUs deaktiviert

Welche Gruppen sind durch den AdminSDHolder geschützt?

Folgende Gruppen (samt den direkten oder verschachtelten Mitgliedern sowie Gruppen) ab Windows 2000, einschließlich Service Pack 3 werden durch den AdminSDHolder geschützt:

  • Organisations-Administratoren
  • Schema-Administratoren
  • Domänen-Administratoren
  • Administratoren

 

Ab dem Service Pack 4 für Windows 2000 (oder mit installiertem Hotfix 327825 auch mit früherem SP) bzw. Windows Server 2003 werden folgende Gruppen mitgeschützt:

  • Server-Operatoren
  • Sicherungs-Operatoren
  • Konten-Operatoren
  • Druck-Operatoren
  • Zertifikatherausgeber

 

Zusätzlich werden die Benutzerkonten „Administrator“ und „KRBTGT“ ebenfalls vom AdminSDHolder Prozess geschützt sowie Benutzerkonten die in Verteilergruppen (auch verschachtelt) ebenfalls Mitglied einer der geschützten Gruppen sind.

Was ist das AdminCount Attribut?

Jeder Benutzer eines Active Direcotrys hat zudem das „Attribut“ namens „adminCount“. Wenn dieses nicht gesetzt ist oder den Wert „0“ hat ist der Benutzer nicht Mitglied einer geschützten Gruppe und wird daher nicht durch den oben beschriebenen „SD Propagator“-Prozess geprüft. Wenn der Wert „1“ ist dann wird der User durch den Prozess geprüft. Entsprechend ist er auch Mitglied einer geschützten Gruppe.

Bekannter Fehler, hervorgerufen durch den AdminSDHolder

Ein ganz bekannter Fehler, der eigentlich keiner ist, ist ein Synchronisationsproblem bei der Verwendung von Azure-AD-Connect/Entra-ID-Connect. Wenn bei der Installation des AD-Connect ausgewählt wird, dass der Wizzard selbst den benötigten Benutzer im lokalen AD erstellen kann, so erstellt dieser einen Benutzer „MSOL_…“ und fügt diesen am Root-Punkt der AD-Domäne hinzu, sodass dieser auf alle Unterobjekte vererbt wird. Dieser Benutzer sollte somit bei allen Benutzer- und Computerobjekten entsprechende Berechtigungen erhalten, dass die Attribute etc. auch zu Azure-AD/Entra-ID synchronisiert werden können.

Wenn ein Benutzer, der auch zu Azure-AD/Entra-ID synchronisiert werden soll, Mitglied einer AdminSDHolder Gruppe ist, erhällt er die Berechtigungen des MSOL-Benutzers nicht. Dadurch können die Benutzerattribute von diesem nicht gelesen und entsprechend synchronisiert werden.

Ein weiterer Grund dafür, einen „normalen“ Benutzer nicht in Administrative Gruppen hinzuzufügen, sondern für administrative Tätigkeiten einen Admin-User anzulegen, der auch nicht synchronisiert werden muss.

Wie das Problem gelöst werden kann beschreibe ich in folgenden beiden Artikeln:

 

 

0 Kommentare
Inline Feedbacks
View all comments