Der RID-Master ist neben der Rolle des PDC-Emulators und Infrastrukturmasters die Rolle, die in jeder Domäne einer Gesamtstruktur existiert. Diese Betriebsmasterrolle weist einen eindeutigen Pool von 500 „relative identifier“ (RIDs) an jeden Domänencontroller innerhalb einer Domäne, für das Erstellen von Objekten zu. Der RID-Master kann keine RIDs domänenübergreifend verteilen. Wozu auch? Denn jede Domäne hat schließlich seinen eigenen RID-Master.


Jeder Domänencontroller (DC) verwendet RIDs um Sicherheitsprinzipale wie z.B. Benutzer-, Gruppen- oder Computerkonten (also SIDs) etc. zu erstellen. Ein „security identifier“ (kurz SID) setzt sich aus der Domänen-SID, diese SID ist für alle Objekte innerhalb einer Domäne identisch und einer eindeutigen „relativen ID“ (kurz RID) zusammen.




 


SIDs müssen in der Domäne (und in der Gesamtstruktur) eindeutig sein, um die Zugriffe auf die Netzwerkressourcen (Dateien, Drucker etc.) klar zu definieren. Da Sicherheitsprinzipale von jedem DC erstellt werden können, stellt der RID-Master sicher, dass ein RID nicht von zwei DCs gleichzeitig ausgestellt werden kann, in dem jeder DC einen eindeutigen RID-Pool erhält.



 


Wann fordert ein DC einen neuen RID-Pool an?


Hat ein DC bis einschließlich „Windows 2000 SP3“ 80% (also 400 RIDs) seines RID-Pools aufgebraucht, fordert der DC vom RID-Master aus seiner Domäne einen neuen Block von 500 RIDs an. Das bedeutet, dass jeder DC stets einen RID-Pool zwischen 100 und 600 RIDs zur Verfügung hat.


Ab „Windows 2000 SP4“ fordern die DCs bereits bei 50% (250 RIDs) verbrauchten RIDs einen neuen RID-Pool an. Das bietet eine bessere Flexibilität, wenn der RID-Master für eine gewisse Zeit offline sein sollte. Daher stehen einem DC ab „Windows 2000 SP4“ stets zwischen 250 und 750 RIDs zur Verfügung.


Ein DC fordert einen neuen RID-Pool an wenn:




  • der Schwellenwert von 80% bzw. 50% erreicht wurde.


  • der Vorgang des Zuweisen eines neuen RID-Pools manuell durchgeführt wird.

    Allocate-Rids Extended Right (Windows)


  • der DC von einer Sicherung wiederhergestellt wurde.

 


Wenn ein DC seinen RID-Pool aufgebraucht hat und bzgl. eines etwaigen Problems vom RID-Master keinen neuen RID-Pool erhalten konnte, kann der DC keine Objekte im AD mehr erstellen. Im Verzeichnisdienstprotokoll des DCs werden die EventIDs 16645 sowie 16651 protokolliert die darauf hinweisen, dass der RID-Pool des DCs aufgebraucht ist und kein neuer RID-Pool angefordert werden konnte (z.B. weil der RID-Master offline ist oder Netzwerkprobleme bestehen).


RID Pool Request



 


Wo wird der RID-Master definiert?


Der RID-Master wird im Attribut fSMORoleOwner festgelegt, dass sich in den Eigenschaften des folgenden Objekts befindet:
CN=RID Manager$,CN=System,DC=Domäne,DC=de


Im Attribut fSMORoleOwner wird als Wert der LDAP-Pfad zum „NTDS Settings“ Objekt des RID-Masters gespeichert:
CN=NTDS Settings,CN=MZDCON01,CN=Servers,CN=Mainz,CN=Sites,CN=Configuration,DC=ad2008R2,DC=Dikmenoglu,DC=de



Verbindet man sich nun in LDP, das sich bis einschließlich „Windows Server 2003“ in den Windows Support Tools befindet und ab „Windows Server 2008“ bereits „on Bord“ ist, mit dem Objekt „
CN=RID Manager$,CN=System,DC=Domäne,DC=de“ werden einem diese Informationen angezeigt:




 


Das Interessante an diesem Screenshot ist das Attribut rIDAvailablePool. In diesem Attribut ist ein Large Integer Wert mit einem „hohen“ und „niedrigen“ Wert gespeichert. Nur wie lässt sich der Wert 4611686014132422208 umrechnen und somit die beiden Bereiche zum Vorschein bringen? LDP schafft Abhilfe. In LDP hat Redmond ein Tool eingebaut, das einem das Umrechnen abnimmt. Unter Windows 2000 und Windows Server 2003 findet man das Umrechnungstool in LDP unter Utilities – Large Integer Converter. Ab Windows Server 2008 heißt es in LDP Dienstprogramme – Konvertierung großer Ganzzahlen. Wenn man dort den Wert aus dem Attribut rIDAvailablePool eingibt und umrechnen lässt, erhält man solch eine ähnliche Ausgabe:




 


Der „hohe Bereich“ gibt die maximale Anzahl der RIDs und somit der Sicherheitsprinzipale innerhalb einer Domäne an, die erstellt werden können. Es können in einer Domäne also 1 Milliarde Sicherheitsprinzipale erstellt werden. Dieser Wert lässt sich nicht ändern und ist auch einer der maximalen Limits des Active Directory!


Siehe auch:
Die Grenzen des Active Directory



Der niedrige Bereich gibt den Anfang des nächsten RID-Pools an. Der nächste DC der vom RID-Master einen neuen RID-Pool anfordert, erhält einen RID-Pool von 1600 bis 2099. Der erste RID-Pool einer Domäne ist von 1100 bis 1599 (+/- zwei-drei RIDs, abhängig von der Serverversion).


Die noch zur Verfügung stehenden RIDs innerhalb einer Domäne, lassen sich auch in der Kommandozeile mit DCDIAG anzeigen. Der Befehl mit dem man den hohen und niedrigen Bereich anzeigen kann, lautet: DCDIAG /Test:RIDManager /v | Find /i „Available RID“




 


Ein weiterer Befehl mit dem man den bereits umgerechneten Wert aus dem Attribut rIDAvailablePool in der Kommandozeile sich anzeigen lassen kann, ist: DCDIAG /Test:RIDManager /v



 


 


 


Was passiert mit den ungenutzten RIDs?


Das Limit von einer Milliarde Sicherheitsprinzipalen werden die meisten Unternehmen nicht erreichen. Doch man sollte sich folgendem bewusst sein:




  • RIDs werden niemals an den RID-Master zurückgegeben. Wird ein Benutzer gelöscht, wird somit auch der SID gelöscht. Wenn z.B. der Benutzer „Yusuf“ gelöscht und ein neuer Benutzer mit dem gleichen Namen erstellt wird, so ist es nicht der identische Benutzer denn das neue Benutzerkonto erhält eine neue SID (und somit auch eine neue RID). Der gelöschte RID wandert nicht in den RID-Pool zurück.


  • Wenn ein DC heruntergestuft wird, ist sein RID-Pool egal wie viele RIDs verbraucht wurden, ebenfalls verloren.


  • Crasht ein DC, ist der RID-Pool auf dem DC auch dahin.


Neigt sich innerhalb einer Domäne die maximale Anzahl an RIDs dem Ende zu, muss entweder eine zusätzliche Domäne erstellt oder migriert werden!


 



Die RID-Attribute


In den Eigenschaften aller DC-Objekte befindet sich das Attribut rIDSetReferences. Darin ist als Wert der Distinguished Name des Objekts RID Set gespeichert. Jeder DC speichert seine RID-Pool Informationen in diesem Objekt:
CN=RID Set,CN=<DC>,OU=Domain Controllers,DC=Domäne,DC=de



Diese kann man sich mit Bordmitteln in LDP oder ADSIEdit ansehen. Ab Windows Server 2008 kann man auch zuerst in der MMC Active Directory-Benutzer und Computer unter Ansicht die Optionen „Benutzer, Kontakte, Gruppen und Computer als Container“ und die „erweiterten Features“ aktivieren. Anschließend erscheint nach Auswahl des DC-Objekts das Objekt
RID Set. Mit einem Doppelklick auf das Objekt kann man sich die RID-Pool Informationen im Reiter Attribut-Editor anzeigen lassen.


In den Eigenschaften des Objekts RID Set findet man die Attribute rIDAllocationPool, rIDNextRID, rIDPreviousAllocationPool und rIDUsedPool.




 



Jeder DC verfügt über zwei RID-Pools. Der RID-Pool den die DCs aktuell zum erstellen von Sicherheitsprinzipalen nutzen ist im Attribut
rIDPreviousAllocationPool gespeichert. Im Attribut rIDAllocationPool wird ein neuer RID-Pool gespeichert den ein DC anfordert, wenn der aktuelle Pool den o.g. Schwellenwert erreicht hat. Ist in beiden Attributen der gleiche Wert gespeichert, hat der DC im Attribut rIDPreviousAllocationPool noch nicht den Schwellenwert erreicht. Rechnet man den Integer Wert im Attribut rIDPreviousAllocationPool mit dem Umrechnungstool in LDP um, erhält man den aktuellen RID-Pool der zurzeit genutzt wird:






Im Attribut
rIDNextRID wird nicht wie es der Name erwarten lässt, der „nächste“ RID der beim erstellen des nächsten Sicherheitsprinzipals dem neuen Objekt zugewiesen wird gespeichert. Stattdessen ist im Attribut der letzte RID der dem „zuletzt“ erstellten Objekt vergeben wurde gespeichert.




 


Da die RID-Pool Informationen DC-spezifisch sind, werden die Attribute rIDAllocationPool, rIDNextRID und rIDPreviousAllocationPool logischerweise nicht repliziert. Jeder DC hat seine eigenen Werte in den Attributen gespeichert.


Das Attribut rIDUsedPool hingegen wird nicht verwendet.


 


 


Den RID-Pool erhöhen


Der RID-Pool von 500 RIDs, der vom RID-Master an die DCs und an sich selbst verteilt wird kann erhöht werden. Dazu gilt es auf dem RID-Master im folgenden Registry-Schlüssel, der seit Windows 2000 existiert, den entsprechenden Wert einzutragen:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\RID Values\RID Block Size


Wurde ein gewünschter Wert (in Dezimal, z.B. 10000) konfiguriert, muss zwingend der RID-Master neu gestartet werden ehe der neue Wert aktiv wird. Das verteilen eines größeren RID-Pools durch den RID-Master ist nur durch diese Registry-Änderung möglich. Trägt man dort einen kleineren Wert als 500 ein, wird der Wert ignoriert und stattdessen der Standardwert von 500 weiter verwendet.


Doch das vergrößern des RID-Pools ist in der Praxis in den allermeisten Fällen nicht notwendig! Wenn der RID-Pool auf einem DC den o.g. Schwellenwert erreicht, wird automatisch vom RID-Master ein neuer Pool angefordert. Ist dies nicht möglich, besteht ein Problem mit dem RID-Master oder es besteht ein Netzwerk bzw. Konnektivitätsproblem. Dies können DNS-, AD-Replikations- oder Netzwerkprobleme sein.



 


Die doppelte Vergabe einer SID


Es gibt Situationen in denen es zur doppelten Vergabe einer SID kommen kann. In Situationen wo der RID-Master „mit Gewalt“ von einem anderen DC übernommen wurde, ein DC von einem Image rückgesichert wurde oder zwei RID-Master in der Domäne existieren, kann es beim erstellen eines Sicherheitsprinzipals zur erneuten Vergabe einer bereits vergebenen RID kommen.


Um die Möglichkeit das zwei RID-Master in der Domäne existieren können zu minimieren, werden folgende Überprüfungen durchgeführt:




  • Es findet eine Replikation statt bevor der RID-Master „mit Gewalt“ von einem anderen DC übernommen wird.


  • Das Attribut rIDAvailablePool wird über die „dringende Replikation“ (urgent replication) repliziert, um den zukünftigen RID-Master möglichst auf dem aktuellsten Stand zu bringen.


  • Wenn der RID-Master einen RID-Pool einem DC zuweist und dieser sich mit einem anderen Pool auf einem anderen DC überschneidet, verwirft der DC den neuen RID-Pool den er erhalten hat und fordert einen neuen Pool an. Das macht der DC erst dann, wenn er die Information der Überschneidung über die AD-Replikation erfahren hat. Diese Vorgehensweise hindert die DCs eine bereits vergebene SID erneut zu vergeben und sorgt dafür, dass die DCs die einen RID-Pool haben der sich mit einem anderen Pool überschneidet, vom RID-Master einen neuen RID-Pool anfordern.



Wenn der Fall doch einmal eintreffen sollte und doppelte SIDs (aus welchen Gründen auch immer) vergeben wurden, kann man diese mit NTDSUTIL aufspüren und entfernen. Die Vorgehensweise ist wie folgt:




  • Zuerst gilt es unter Start – Ausführen das NTDSUTIL zu starten.


  • Danach muss man sich mit einem DC verbinden. Dazu gibt man den folgenden Befehl ein: connect to server <Computername>


  • Mit dem Befehl check duplicate sid wird nach doppelten SIDs in der Domäne gesucht. Ist die Suche beendet, wird die Log-Datei dupsid.log auf der Ebene erstellt, in der auch das NTDSUTIL aufgerufen wurde. In der Log-Datei sind die doppelten SIDs (falls vorhanden) protokolliert.


  • Wurden doppelte SIDs gefunden, kann man auf der gleichen NTDSUTIL-Ebene mit dem Befehl cleanup duplicate sid die duplizierten SIDs entfernen.


  • Anschließend kann man mit „q“ oder „quit“ (zwei mal) das NTDSUTIL verlassen.


Das erstellen der Log-Datei kann auch mit einem Einzeiler in der CMD erstellt werden.
Der Befehl dazu lautet:
C:\Users\Administrator> NTDSUTIL “sec acc man” “co to se DCNAME” “check dup sid” q q



Doppelte SIDs können mit diesem Einzeiler entfernt werden:
C:\Users\Administrator> NTDSUTIL “sec acc man” “co to se DCNAME” “clean dup sid” q q




 


Weitere Informationen:
Die FSMO-Rollen verschieben
Event ID 16650: The account-identifier allocator failed to initialize in Windows 2000 and in Windows Server 2003
Description of RID Attributes in Active Directory
“Domain controller has failed to obtain a new identifier pool” error event in Windows 2000 Server SP3 and earlier
Active Directory attributes that refer to a prefix may not be stored in the local copy of Active Directory on a computer that is running Microsoft Windows Server 2003
FSMOs
HOW TO: Find and Clean Up Duplicate Security Identifiers with Ntdsutil in Windows Server 2003
How To Find and Clean Up Duplicate Security Identifiers with Ntdsutil in Windows 2000

Comments are closed, but trackbacks and pingbacks are open.