Von RIDs, SIDs und deren Master…

Auch wenn diese Begriffe schon seit langem in der Microsoft Welt existieren, sollten es diese dennoch wert sein, diese mal wieder genauer zu erklären: Eine SID (Security Identifier) besteht grundsätzlich aus zwei Teilen – einer Domänen-SID und einem RID (Relative Identifier). Dabei verhält sich das ähnlich, wie bei einer IP-Adresse, welche aus einer NetID und einer HostID besteht. Der erste Teil einer SID ist innerhalb der Domäne immer derselbe – und dieser Teil ist der längere Teil. Nach dem letzten Bindestrich, folgt dann zuguterletzt der RID. Es gibt dabei vordefinierte Objekte in Windows, welche immer über dieselbe RID verfügen (so z.B. der vordefinierte Administrator, der immer über die RID 500 verfügt, weshalb dieser seit Windows Vista auch standardmässig deaktiviert wurde).

D.h. das einzige eindeutige an einer SID innerhalb einer Domäne, ist eigentlich der RID. Da jedoch in den meisten Domänen mehr als ein Domänencontroller existiert und auf jedem Domänencontroller ein neues Objekt erstellt werden kann (ausser natürlich auf einem RODC ;-D), müssen sich diese Domänencontroller irgendwie untereinander absprechen, damit keine doppelten RIDs vergeben werden. Da dies ein heilloses Durcheinander darstellen würde, wenn wir von einer Umgebung mit zahlreichen DCs ausgehen, muss hier jemand für Kontrolle sorgen. Somit ist der Betriebsmaster (die FSMO-Rolle) der RID-Masters geboren, welchen es einmal pro Domäne gibt. Dieser wäre in der Theorie in der Lage über 1 Milliarde RIDs in einer Domäne zu vergeben – resp. über eine Milliarde Objekte mit RIDs auszurüsten…

Nun wäre es jedoch sehr kontraproduktiv, wenn alle Domänencontroller bei jeder Objekterstellung auf diesen DC mit der RID-Master-Rolle angewiesen wären. Deshalb holt sich jeder Domänencontroller einfach schon einmal präventiv einen Pool von 500 RIDs beim RID-Master ab (dieser Wert könnte auch angepasst werden – aber wer möchte das schon ;-D). Somit könnten theoretisch 500 Objekte auf diesem DC erstellt werden, ohne jedesmal beim RID-Master nachzufragen, welche RID verwendet werden kann. Damit der DC nicht erst nach 500 vergebenen RIDs plötzlich auf die Idee kommt, dass er einen neuen Pool organisieren muss, fragt dieser schon nach 50% vergebener RIDs beim Master nach weiteren RIDs nach. Dieses Verhalten gilt seit Windows Server 2000 inkl. Sp4 – vorher hat er es bis 80% ausgehalten…

Das ist also mal der Fakt, wenn alles funktioniert – was kann nun jedoch alles schief gehen? Naja: Es könnte sein, dass der RID-Master ausfällt. In diesem Falle muss die FSMO-Rolle auf einen anderen Domänencontroller übernommen werden (seize). Wenn der RID-Master ganz ausfallen sollte und man diesen Umstand weshalb auch immer vergessen hat, dann wird man weiterhin Objekte erstellen können – halt solange, wie die RID-Pools eines Domänencontrollers noch freie RIDs ausspucken…

Was jedoch, wenn ein Domänencontroller plötzlich nicht mehr weiss, welche RID er als letztes verwendet hat? Wann kann ein solcher Fall überhaupt auftreten? Falls ein IT-Administrator ein reguläres System-Backup wiederherstellt, wird der Domänencontroller automatisch angewiesen, den RID-Pool erneut mit dem RID-Master abzugleichen und einen neuen Pool zu beziehen. Dies kann jedoch z.B. dann passieren, wenn ein IT-Administrator eine Image-Sicherung eines Domänencontroller wiederherstellt oder bei einem virtuellen Domänencontroller einen Snapshot wiederherstellt.

Was soll man da denn machen? Im ersten Schritt sollte man in diesem Falle erst einmal auf allen Domänencontrollern prüfen, welche RID-Pools gerade in Verwendung sind. Dies kann man durch die Eingabe des folgenden Befehls tun:

dcdiag /v /test:RIDManager

Der Output dieses Befehls sieht ungefähr so aus:

Starting test: RidManager
   * Available RID Pool for the Domain is 12600 to 1073741823
   * ITRSRV00.epads.itrainlab.com is the RID Master
   * DsBind with RID Master was successful
   * rIDAllocationPool is 12100 to 12599
   * rIDPreviousAllocationPool is 11600 to 12099
   * rIDNextRID: 11918
   ……………………. ITRSRV00 hat den Test RidManager bestanden.

Man kann dieser Ausgabe entnehmen, dass die nächste RID, welche vergeben wird, die RID 11918 sein wird. Der erhaltene RID-Pool definiert sich von 12100 bis 12599 – also genau 500 RIDs.

Wenn nun zwei RID-Pools (von zwei DCs) identisch sein sollten, so muss dieser RID-Pool als ungültig erklärt und ein neuer Pool vom RID-Master angefordert werden. Das nachfolgende kleine Script von Microsoft kann dabei helfen, den RID-Pool als ungültig zu erklären – keine Angst: Der DCDiag gibt im Anschluss einen RID-Pool von „0“ aus – sobald jedoch ein neues Objekt erstellt wird, holt sich der DC automatisch einen neuen RID-Pool beim RID-Master (obwohl teilweise auch am Ende der Objekterstellung noch eine Fehlermeldung angezeigt wird).

Das nachfolgende Script muss als „.vbs“-Datei gespeichert und einfach ausgeführt werden:

Option Explicit

Const HKLM = &H80000002

Dim WshShell
Dim strDC
Dim objWbemLocator, objWMISvc, objWMIReg
Dim strKeyPath, strValueName, strServerRole
Dim objROOT
Dim strDefaultNC
Dim objDomain
Dim strDomainSID

Set WshShell = Wscript.CreateObject(„Wscript.Shell“)

strDC = UCase(WshShell.ExpandEnvironmentStrings(„%COMPUTERNAME%“) & „.“ & WSHShell.RegRead („HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Domain“))

Set objWbemLocator = CreateObject(„WbemScripting.SWbemLocator“)
Set objWMISvc = objWbemLocator.ConnectServer(strDC, „root\default“, „“, „“)
Set objWMIReg = objWMISvc.Get(„StdRegProv“)
strKeyPath = „SYSTEM\CurrentControlSet\Services\NTDS\Parameters“
strValueName = „Machine DN Name“
objWMIReg.GetStringValue HKLM,strKeyPath,strValueName,strServerRole
 
If strServerRole <> „“ Then
 Set objROOT = GetObject(„LDAP://“ & strDC & „/RootDSE“)
 strDefaultNC = objROOT.Get(„defaultNamingContext“)
 Set objDomain = GetObject(„LDAP://“ & strDC & „/“ & strDefaultNC)
 strDomainSID = objDomain.objectSID
 objROOT.Put „invalidateRidPool“, strDomainSID
 objROOT.SetInfo
 Wscript.Echo(„The current RID pool has been invalidated!“)
 Wscript.Echo(„A new RID pool will be requested from the RID Master FSMO!“)
Else
 Wscript.Echo(strDC & “ is not a DC!“)
End If

Set WshShell = Nothing
Set strDC = Nothing
Set objWbemLocator = Nothing
Set objWMISvc = Nothing
Set objWMIReg = Nothing
Set strKeyPath = Nothing
Set strValueName = Nothing
Set strServerRole = Nothing
Set objROOT = Nothing
Set strDefaultNC = Nothing
Set objDomain = Nothing
Set strDomainSID = Nothing

 

Dieses Script kann also helfen, wenn doppelte RIDs zwischen Domänencontrollern vergeben werden – was ist jedoch, wenn die RIDs die vergeben werden mit den RIDs von alteingesessenen Objekten in Konflikt stehen? Welche RIDs und SIDs haben die bestehenden Objekte in der Domäne überhaupt? Welches ist die höchste SID/RID?

Genau an diesem Punkt kommt mein neues Tool zum Einsatz: GetSID (einfach in meiner Version, da es diesen Befehl als Download schon gibt ;-D). GetSID.exe exportiert alle SIDs, RIDs und Objekt DNs aus einer ganzen Domäne oder einem bestimmten OU-Pfad in ein CSV-Datei. Zudem gibt das Tool nach erfolgreicher Verarbeitung die höchste gefundene RID der Domäne oder des Suchpfades auf dem Bildschirm aus. Also alles in allem sehr handy, wenn man die bestehende Umgebung mit den RID-Pools abgleichen möchte.

Apropos: Dieses Tool gibt es unter diesem Link! ;-D

In diesem Sinne: Nicht allzuviel Ärger mit SIDs und RIDs und wenn doch, dann hoffe ich etwas Licht ins Dunkel gebracht zu haben…

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Schreib einen Kommentar