Mit dem Kommandozeilentool Whoami das sich unter Windows 2000 im Ressource Kit befindet und ab Windows Server 2003 on Bord ist, lässt sich der komplette Inhalt des Access-Tokens des aktuell angemeldeten Benutzers anzeigen und exportieren. Im Accesss-Token ist die SID des Benutzers, die SIDs der SID-History (ab Windows Server 2003) und die SID's aller Gruppen in denen der angemeldete Benutzer innerhalb der Domäne direkt oder verschachtelt Mitglied ist enthalten. Whoami zeigt auch direkte oder verschachtelte domänenübergreifende universelle Gruppenmitgliedschaften an.
Führt man in einer CMD den Befehl Whoami /all > C:\Temp\Whoami.txt aus, wird solch eine Datei im angegebenen Pfad erstellt:
Die Hilfe zu Whoami lässt sich in gewohnter Windows-Manier mit Whoami /? anzeigen.
In welcher Situation ist es sinnvoll Whoami auszuführen?
Wenn ein Benutzer zu einer Gruppe hinzugefügt und dieser Gruppe die entsprechenden Rechte auf eine Ressource (Dateien, Drucker etc.) erteilt wurde, der Benutzer aber immer noch keinen Zugriff auf die Ressource hat, sollten zwei Punkte sichergestellt werden:
-
Hat sich der Benutzer nach dem hinzufügen zur Gruppen erneut an seinem Client angemeldet? Denn Gruppenmitgliedschaften werden nicht während einer Benutzersitzung ausgewertet, sondern nur bei der Anmeldung.
-
Hat sich der Benutzer bereits neu angemeldet, kann mit Whoami /all das Access-Token ausgewertet werden. Damit kann man überprüfen, ob sich der Benutzer auch tatsächlich in der entsprechenden Gruppe befindet.
Die Gruppenmitgliedschaften eines Benutzers mit der AD-PowerShell exportieren
Das Pendant zu Whoami stellt mit „Windows Server 2008 R2“ und Windows 7 die „Active Directory-PowerShell“ dar. Wird auf einem „Windows Server 2008 R2“ DC oder auf einem Windows 7 Client mit installiertem RSAT (Remote Server Administration Tools) das Cmdlet Get-ADAccountAuthorizationGroup ausgeführt, werden ebenfalls die direkten und verschachtelten Gruppenmitgliedschaften des angegebenen Benutzerkontos angezeigt. Domänenübergreifende „domänenlokale“ Gruppenmitgliedschaften werden nicht angezeigt, aber domänenübergreifende „universelle“ Gruppenmitgliedschaften schon. Domänenübergreifende globale Gruppen sind aus technischen Gründen ohnehin nicht möglich, da eine globale Gruppe nur Mitglieder aus der eigenen Domäne enthalten kann.
Ein DC kann „domänenlokale“, „globale“ und „universelle“ Gruppenmitgliedschaften eines Benutzers, nur innerhalb seiner Domäne ermitteln. Domänenlokale- und globale Gruppen werden zwar (neben den universellen Gruppen) auch in den globalen Katalog (GC) repliziert, allerdings nicht die Mitglieder dieser Gruppen! Deshalb findet auch bei Gruppenveränderungen in domänenlokalen und globalen Gruppen keine GC-Replikation statt. Da aber ein Benutzer Mitglied einer universellen Gruppe in unterschiedlichen Domänen sein kann, ist für die Abfrage von domänenübergreifenden universellen Gruppenmitgliedschaften ein GC notwendig. Denn nur der GC kennt die domänenübergreifenden universellen Gruppenmitgliedschaften eines Benutzers, da das member Attribut von universellen Gruppen auf den GC repliziert wird. Wenn sich ein Benutzer in einer Gesamtstruktur mit mehreren Domänen an einer Domäne anmeldet, muss der DC einen GC kontaktieren um die universellen Gruppenmitgliedschaften abzurufen, in denen der Benutzer evtl. in anderen Domänen Mitglied ist. Oder es ist ab Windows Server 2003 das „zwischenspeichern der universellen Gruppenmitgliedschaften“ auf einem AD-Standort aktiviert.
In einer Multidomänen-Gesamtstruktur ist es zwingend erforderlich, dass zum Zeitpunkt der Abfrage mit dem Cmdlet Get-ADAccountAuthorizationGroup ein GC erreichbar ist. Denn schließlich wird für die Auswertung der domänenübergreifenden universellen Gruppenmitgliedschaften ein GC benötigt. Wenn zum Zeitpunkt der Abfrage kein GC erreicht werden kann schlägt die Abfrage fehl. Allerdings schlägt die Abfrage nur dann fehl, wenn es sich um eine Multidomänen-Gesamtstruktur handelt!
Die Option „Das zwischenspeichern von universellen Gruppenmitgliedschaften“ bringt nicht den gewünschten Erfolg. Die Abfrage mit dem Cmdlet in einer Gesamtstruktur mit mehreren Domänen schlägt auch in diesem Fall fehl.
Ein GC oder das zwischenspeichern von universellen Gruppenmitgliedschaften ist für die Benutzeranmeldung nur in einer Gesamtstruktur mit mehreren Domänen notwendig. Handelt es sich um eine Einzeldomänen-Gesamtstruktur (Single-Domänen Forest), wird weder ein GC, noch das zwischenspeichern von universellen Gruppenmitgliedschaften benötigt. Es existieren ohnehin keine domänenübergreifenden Gruppenmitgliedschaften, wozu ein GC oder das zwischenspeichern von universellen Gruppenmitgliedschaften notwendig wäre.
In einer Einzeldomänen-Gesamtstruktur benötigt das Cmdlet deshalb auch keinen GC. Schließlich kennt in einer Einzeldomänen-Gesamtstruktur der DC alle Gruppenmitgliedschaften eines Benutzers. Auch der Benutzer kann sich in einer Einzeldomänen-Gesamtstruktur ohne einen GC erfolgreich an der Domäne anmelden.
In einer Windows Server 2003 oder Windows Server 2008 Umgebung lässt sich die AD-PowerShell ebenfalls z.B. von einem Windows 7 Client nutzen. Dazu muss jedoch das „AD MGS“ auf mindestens einem DC installiert werden:
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
Das Cmdlet Get-ADAccountAuthorizationGroup liest das Attribut tokenGroups des angegebenen Sicherheitsprinzipals aus. Dabei kann ein Benutzer oder Computer angegeben werden, aber keine Gruppe! Es werden zum einen alle direkten und verschachtelten Sicherheits-Gruppenmitgliedschaften (domänenlokale, globale und universelle Gruppen) innerhalb der Domäne und zum anderen die direkten und verschachtelten domänenübergreifenden universellen Gruppenmitgliedschaften eines Benutzers angezeigt. Es werden jedoch keine Verteilergruppen angezeigt!
Das mehrwertige Attribut tokenGroups ist zwar im Schema definiert, es enthält jedoch selbst keinen Wert. Die Attributwerte werden erst im Moment der Abfrage errechnet. Diese Art von Attribut bezeichnet man als Constructed Attribute oder auch Computed Attribute. Da das Attribut tokenGroups "constructed" ist, kann es nicht repliziert werden. Sein Wert wird auch nicht in den GC übertragen.
Siehe auch:
Die konstruierten Attribute abfragen
Die Gruppenmitgliedschaften eines Benutzers werden wie folgt in eine CSV-Datei exportiert:
Get-ADAccountAuthorizationGroup Yusuf | Export-CSV C:\Yusuf.csv -NoTypeInformation
Soll die Ausgabe bis auf wenige Attribute gekürzt werden, lautet der Befehl wie folgt:
Get-ADAccountAuthorizationGroup Yusuf | Select distinguishedName,sAMAccountName,GroupCategory,GroupScope,objectClass | Export-CSV C:\Yusuf.csv -NoTypeInformation
Die Ausgabe sieht wie folgt aus:
Die Hilfe zu dem Cmdlet lässt sich mit diesem Befehl anzeigen:
Get-Help Get-ADAccountAuthorizationGroup -Full
Weitere Informationen:
Delegierte Berechtigungen im AD verstehen
Active Directory – Abfrage
AD-PowerShell Befehle
Token-Groups Attribute (Windows)
How to enumerate a user's security group membership using Visual Basic or Visual Basic Script
Im Active Directory-Schema sind verschiedene Arten von Attribute definiert. Die meisten davon sind in der Active Directory-Datenbank (NTDS.dit) gespeichert und können einen festen Wert enthalten.
Aber längst nicht alle Attribute für ein Objekt sind in der AD-Datenbank gespeichert. Diese Art von Attribut bezeichnet man als Constructed Attribute, auch bekannt als Computed Attribute.
Die Merkmale eines solchen Attributs sind:
-
Constructed Attribute, zu Deutsch „konstruierte Attribute“ sind zwar im Schema definiert, sie enthalten jedoch selbst keinen Wert. Die Attributwerte werden erst von einem Domänencontroller im Moment der LDAP-Anfrage gebildet.
-
Da diese Attribute "constructed" sind, können sie auch nicht repliziert werden. Die Werte können auch nicht in den globalen Katalog (GC) übertragen werden.
-
Wird eine Abfrage nach solch einem Attribut durchgeführt, bildet jeder DC eigenständig den Wert.
-
Ein Wert eines konstruierten Attributs kann nicht vergeben bzw. geschrieben werden. Diese Art von Attribut wird lediglich für eine gezielte Abfrage vom DC zusammengesetzt.
-
Konstruierte Attribute können in der Regel nicht für Abfragen verwendet werden (die Ausnahme stellt das Attribut aNR oder memberOf dar).
-
In einigen Fällen muss bei der Abfrage im Parameter -Scope die Option BASE angegeben werden, wie z.B. für das Attribut tokenGroups. Mit dieser Option wird auf ein einziges Objekt zugegriffen.
-
Eine Abfrage nach allen Objekten in einem Container, die ein konstruiertes Attribut der Objekte die sich in dem Container befinden anzeigt, bringt kein Ergebnis.
Ein konstruiertes Attribut wird durch das dritte Bit im System-Flags Attribut definiert. Verbindet man sich in LDP z.B. mit dem konstruierten Attribut CN=Token-Groups,CN=Schema,CN=Configuration,DC=Root-Domäne lässt sich das System-Flag folgendermaßen kontrollieren:
Die konstruierten Attribute einer Gesamtstruktur anzeigen
In der AD-Powershell
Get-ADObject -LDAPFilter “(&(objectClass=attributeSchema)(systemflags:1.2.840.113556.1.4.803:=4))” -Searchbase “CN=Schema,CN=Configuration,DC=Root-Domäne” | Select Name
Oder:
Get-ADObject -LDAPFilter "(objectClass=attributeSchema)" -Searchbase "CN=Schema,CN=Configuration,DC=Root-Domäne" -Properties Systemflags | Where {$_.Systemflags -band 4} | Select Name
Mit LDP
-
Nach dem Starten von LDP gilt es zuerst eine Verbindung zu einem DC herzustellen.
-
Im zweiten Schritt muss man sich mit dem AD binden.
-
Anschließend gibt man im Suchfenster (unter Browse/Durchsuchen-Search/Suchen) als Basis-DN CN=Schema,CN=Configuration,DC=Root-Domäne ein und verwendet als Filter (&(objectcategory=attributeSchema)(systemFlags:1.2.840.113556.1.4.803:=4)).
-
Als Scope/Bereich gilt es One Level/Eine Ebene zu wählen.
-
Im Feld Attribute können dann die gewünschten Attribute angegeben werden.
In der Kommandozeile mit Dsquery, ab Windows Server 2003
dsquery * “CN=Schema,CN=Configuration,DC=Root-Domäne” -Scope Onelevel -attr Name -Filter "(&(objectcategory=attributeSchema)(systemFlags:1.2.840.113556.1.4.803:=4))"
Weitere Informationen:
AD-PowerShell Befehle
Microsoft Windows 2000 Scripting Guide - Operational Attributes
How to query Active Directory by using a bitwise filter
System-Flags Attribute
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:
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
Bisher konnte der Domänen- sowie Gesamtstrukturfunktionsmodus über die grafische Oberfläche, zum einen über die MMC Active Directory-Benutzer und -Computer und zum anderen über die MMC Active Directory-Domänen und -Vertrauensstellung hochgestuft werden. Der Domänenfunktionsmodus lässt sich entweder in der MMC Active Directory-Benutzer und -Computer oder Active Directory-Domänen und -Vertrauensstellung hochstufen. Der Gesamtstrukturfunktionsmodus hingegen lässt sich ausschließlich in der MMC Active Directory-Domänen und -Vertrauensstellung hochstufen.
Beide Funktionsebenen lassen sich (neben LDIFDE und VBSkript) auch mit LDP und ADSIEdit heraufstufen. Dazu muss für den Domänenfunktionsmodus im Attribut msDS-Behavior-Version, das sich in der Domänenpartition in den Eigenschaften des Containers <DC=Domäne,DC=TLD> befindet, der entsprechende Wert eingetragen werden.
Für den Gesamtstrukturfunktionsmodus ist ebenfalls im Attribut msDS-Behavior-Version, das sich in der Konfigurationspartition in den Eigenschaften des Containers <CN=Partitions,CN=Configuration,DC=Root-Domäne,DC=TLD> befindet, der entsprechende Wert einzutragen.
Die MMCs oder die AD-PowerShell machen auch nichts anderes, als den Wert im Attribut msDS-Behavior-Version an entsprechender Stelle zu ändern.
Der Wert im Attribut msDS-Behavior-Version das sich in den Eigenschaften der Domänenpartition befindet, entspricht dem folgenden Domänenfunktionsmodus:
0 = Domänenfunktionsmodus: Windows 2000 gemischt und Windows 2000 pur
1 = Domänenfunktionsmodus: Windows Server 2003 Interim
2 = Domänenfunktionsmodus: Windows Server 2003
3 = Domänenfunktionsmodus: Windows Server 2008
4 = Domänenfunktionsmodus: Windows Server 2008 R2
Der Wert im Attribut msDS-Behavior-Version das sich in der Konfigurationspartition in den Eigenschaften des Objekts CN=Partitions befindet, entspricht dem folgenden Gesamtstrukturfunktionsmodus:
0 = Gesamtstrukturfunktionsmodus: Windows 2000
1 = Gesamtstrukturfunktionsmodus: Windows Server 2003 Interim
2 = Gesamtstrukturfunktionsmodus: Windows Server 2003
3 = Gesamtstrukturfunktionsmodus: Windows Server 2008
4 = Gesamtstrukturfunktionsmodus: Windows Server 2008 R2
Weitere Details werden im folgenden Artikel erläutert:
Domänen- und Gesamtstrukturfunktionsmodus
Mit der Einführung des Windows Server 2008 R2 und der AD-PowerShell lässt sich der Domänen- und Gesamtstrukturfunktionsmodus nun auch über die AD-PowerShell hochstufen.
Den Domänenfunktionsmodus mit der AD-PowerShell heraufstufen
Der Domänenfunktionsmodus lässt sich mit Domänen-Admin Rechten mit diesem Befehl heraufstufen:
Set-ADDomainMode -Identity <Domäne> -DomainMode <Modus>
Der Identity-Parameter gibt die AD-Domäne an, die in den höheren Modus gestuft werden soll. Die Domäne kann dabei durch den:
Mit der Angabe des definierten Namen der Domäne sieht der Befehl so aus:
Set-ADDomainMode -Identity „DC=blog,DC=dikmenoglu,DC=de“ -DomainMode <Modus>
Durch die Angabe der ObjectGUID der Domäne sieht der Befehl wie folgt aus:
Set-ADDomainMode -Identity e7057501-108f-4320-9f55-d40a400acbe7 -DomainMode <Modus>
Der Befehl zum Heraufstufen in einen höheren Domänenfunktionsmodus mit der Angabe der Object-SID ist folgender:
Set-ADDomainMode -Identity S-1-5-21-4256209546-3580370902-1950063504 -DomainMode <Modus>
Mit der Angabe des DNS-Domänennamen lautet der Befehl so:
Set-ADDomainMode -Identity „blog.dikmenoglu.de“ -DomainMode <Modus>
Zum Heraufstufen des Domänenfunktionsmodus mit der Angabe des NetBIOS-Domänennamen gilt es diesen Befehl anzugeben:
Set-ADDomainMode -Identity „blog-dikmenoglu“ -DomainMode <Modus>
Da die AD-PowerShell Pipeline-fähig ist, kann ein Domänenobjekt über die Pipeline an den Identity-Parameter übergeben werden. Z. B. kann mit dem Cmdlet Get-ADDomain ein Domänenobjekt abgerufen und dieses anschließend über die Pipeline an das Cmdlet Set-ADDomainMode übergeben werden. Der Befehl würde so aussehen:
Get-ADDomain | Set-ADDomainMode -Identity <Domäne> -DomainMode <Modus>
Der Parameter -DomainMode gibt den Domänenfunktionsmodus an, auf den die angegebene Domäne hochgestuft werden soll. Bei der Angabe von <Modus> können folgende Werte angegeben werden:
- Windows2000Domain oder 0
- Windows2003InterimDomain oder 1
- Windows2003Domain oder 2
- Windows2008Domain oder 3
- Windows2008R2Domain oder 4
Die Domäne “blog.dikmenoglu.de” lässt sich wie folgt auf den Domänenfunktionsmodus “Windows Server 2008 R2” heraufstufen:
Set-ADDomainMode -Identity blog.dikmenoglu.de -DomainMode 4
Das Heraufstufen einer Domäne kann auch z.B. von einem Windows 7 Client worauf die RSAT installiert sind erfolgen, das Mitglied einer anderen Domäne ist. Natürlich funktioniert das nur, wenn das Benutzerkonto mit dem das Heraufstufen durchgeführt wird, Domänen-Admin Rechte in der Zieldomäne hat oder dem Benutzer die entsprechenden Rechte delegiert wurden.
Den Gesamtstrukturfunktionsmodus mit der AD-PowerShell heraufstufen
Der Gesamtstrukturfunktionsmodus lässt sich mit Organisations-Admin Rechten mit diesem Befehl heraufstufen:
Set-ADForestMode -Identity <Wert> -ForestMode <Modus>
Der -identity Parameter gibt die Root-Domäne der Gesamtstruktur an. Als Wert kann der:
Verwendet man den vollqualifizierten Domänennamen, sieht der Befehl so aus:
Set-ADForestMode -Identity „Root-Domäne.de“ -ForestMode <Modus>
Die Gesamtstruktur kann durch die Angabe der ObjectGUID der Root-Domäne wie folgt heraufgestuft werden:
Set-ADForestMode -Identity e7057501-108f-4320-9f55-d40a400acbe7 -ForestMode <Modus>
Mit der Angabe des NetBIOS-Namen der Root-Domäne wird die Gesamtstruktur folgendermaßen heraufgestuft:
Set-ADForestMode -Identity „Root-Domäne“ -ForestMode <Modus>
Mit Angabe des DNS-Hostnamen (FQDN) wird die Gesamtstruktur so heraufgestuft:
Set-ADForestMode –Identity “DCON01.Root-Domäne.de” -ForestMode <Modus>
Eine weitere Möglichkeit die Gesamtstruktur in den höheren Modus zu stufen, ist durch die Pipeline-Fähigkeit der AD-PowerShell möglich. Mit dem Cmdlet Get-ADForest können zuerst die Gesamtstrukturinformationen abgerufen und anschließend über die Pipeline an das Cmdlet Set-ADForestMode übergeben werden:
Get-ADForest | Set-ADForestMode -Identity <Wert> -ForestMode <Modus>
Der Parameter -ForestMode gibt den Gesamtstrukturfunktionsmodus an, auf den die angegebene Gesamtstruktur hochgestuft werden soll. Bei der Angabe von <Modus> können folgende Werte angegeben werden:
- Windows2000Forest oder 0
- Windows2003InterimForest oder 1
- Windows2003Forest oder 2
- Windows2008Forest oder 3
- Windows2008R2Forest oder 4
Der Gesamtstrukturfunktionsmodus lässt sich wie folgt auf „Windows Server 2008 R2“ heraufstufen:
Set-ADForestMode -Identity „root.dikmenoglu.de“ -ForestMode Windows2008R2Forest
Erstmals kann der Domänen- sowie Gesamtstrukturfunktionsmodus unter gewissen Umständen sogar zurückgestuft werden. Was das genau auf sich hat, wird in diesem Artikel beschrieben:
Den Domänen- und Gesamtstrukturfunktionsmodus zurückstufen
Den Domänen- und Gesamtstrukturfunktionsmodus anzeigen
Neben den MMCs Active Directory-Benutzer und -Computer sowie Active Directory-Domänen und -Vertrauensstellung lässt sich der Domänen- und Gesamtstrukturfunktionsmodus unter anderem mit der AD-PowerShell, LDP und Dsquery wie folgt anzeigen.
Die Funktionsebenen in der AD-PowerShell anzeigen
-
Den Domänenfunktionsmodus kann man sich mit diesem Befehl anzeigen lassen:
Get-ADDomain | Select DomainMode | FL
-
Der Gesamtstrukturfunktionsmodus lässt sich mit diesem Befehl anzeigen:
Get-ADForest | Select ForestMode | FL
-
Man kann sich aber auch mit dem RootDSE-Objekt verbinden und die Informationen aus den beiden Attributen ForestFunctionality und DomainFunctionality entnehmen. Der Befehl lautet so (alles in einer Zeile):
[ADSI]"LDAP://RootDSE" | Select ForestFunctionality,DomainFunctionality
LDP
Startet man das LDP und verbindet sich mit einem DC, werden die Attribute vom RootDSE-Objekt angezeigt. Dort kann man ebenfalls den Domänen- sowie Gesamtstrukturfunktionsmodus entnehmen.
Dsquery
-
Das Attribut msDS-Behavior-Version lässt sich für den Domänenfunktionsmodus wie folgt abfragen:
dsquery * “DC=Domäne,DC=de” -Scope Base -attr msDS-Behavior-Version
-
Die Abfrage für den Gesamtstrukturfunktionsmodus lautet folgendermaßen:
dsquery * “CN=Partitions,CN=Configuration,DC=Root-Domäne” -Scope Base -attr msDS-Behavior-Version
Weitere Informationen:
How to raise domain and forest functional levels in Windows Server 2003
3.1.1.3.2 rootDSE Attributes
Was bis Windows Server 2003 möglich ist, funktioniert ab Windows Server 2008 nicht mehr. Bis Windows Server 2003 ist es möglich einen zusätzlichen Server in einer Subdomäne zum Domänencontroller (DC) zu stufen, ohne das eine Verbindung zwischen der Sub- und Root-Domäne besteht.
Ab Windows Server 2008 ist das nicht mehr möglich. Existiert zum Zeitpunkt des Heraufstufens zwischen der Sub- und Root-Domäne keine (VPN-) Verbindung, kann ein Server nicht als zusätzlicher DC in einer Subdomäne heraufgestuft werden. Dabei spielt es keine Rolle, ob es sich um einen Standalone- oder Mitgliedsserver handelt!
Das Heraufstufen eines zusätzlichen DCs schlägt über die grafische Oberfläche mit dem DCPROMO-Assistenten und in der Kommandozeile (CMD) mit der Unattendedvariante (unbeaufsichtigte DC-Installation) fehl. Es schlägt auch dann fehl, wenn lediglich die DNS- und LDAP-Kommunikation zwischen der Sub- und Root-Domäne gestört ist.
Die irreführende Fehlermeldung über den DCPROMO-Assistenten lautet wie folgt:
Auch die Fehlermeldung mit der Unattendedvariante in der Kommandozeile ist nicht Aufschlussreich:
Die Ursache für dieses Fehlverhalten ab Windows Server 2008 liegt darin begründet, dass das DCPROMO versucht einen DC aus der Root-Domäne zu erreichen, um Gesamtstrukturinformationen abzurufen. Leider weisen die Fehlermeldungen keineswegs darauf hin. Die Gesamtstrukturinformationen können aber von jedem DC egal aus welcher Domäne geliefert werden.
Nun hat Microsoft reagiert und einen Hotfix veröffentlicht. Der Hotfix kann von diesem KB-Artikel aus angefordert werden:
You cannot install Active Directory Domain Services on a member server that is running Windows Server 2008 in a branch office if the DNS and LDAP communication between the branch office and the forest root domain is blocked
Nach der Installation des Hotfixes ist kein Neustart notwendig.
Anschließend ist das Heraufstufen über die grafische Oberfläche und in der CMD möglich, ohne das eine Verbindung zwischen der Sub- und Root-Domäne existiert.
Das Problem besteht leider auch unter Windows Server 2008 R2!
Auch für die „2008 R2“ Version wird Microsoft einen Hotfix veröffentlichen. Sobald dieser verfügbar ist, wird ein entsprechender Hinweis an dieser Stelle erfolgen.
16.10.2009: Leider gibt es zur Zeit mit der x32Bit Version des Hotfixes ein Problem. Microsoft ist bereits informiert und wird es schnellstmöglich beheben. Die x64 Version funktioniert ohne Probleme.
|
Copyright © 2010 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|