LDAP://Yusufs.Directory.Blog/ - Active Directory|Administration

Alle Mitglieder einer Gruppe in eine neue Gruppe kopieren

Yusuf Dikmenoglu — Sun, 15 Aug 2010 11:28:43 GMT

Die Mitglieder einer Gruppe werden im mehrwertigen Attribut member des AD-Objekts der Gruppe gespeichert. Bei diesem Attribut handelt es sich um das Forward-Link Attribut und das Pendant dazu ist das mehrwertige Attribut memberOf, das im Benutzerobjekt gespeichert ist und als Back-Link bezeichnet wird.

Mehr über verknüpfte Attribute gibt es hier: Verknüpfte Attribute

Möchte man die Mitglieder einer bestimmten Gruppe in eine andere kopieren, so hat man neben skriptbasierten Lösungen folgende Möglichkeiten

In der AD-PowerShell

In einem Einzeiler sieht der AD-PowerShellbefehl zum Kopieren der Mitglieder einer Gruppe in eine andere so aus:

Get-ADGroupMember <Quell-Gruppe> | Select sAMAccountName | ForEach { Add-ADGroupMember <Ziel-Gruppe> -Members $_.sAMAccountName }

Möchte man den Befehl mit Hilfe einer Variablen ausführen, so lautet der Befehl wie folgt:

$Gruppe = Get-ADGroupMember <Quell-Gruppe> | Select sAMAccountName
$Gruppe | ForEach { Add-ADGroupMember <Ziel-Gruppe> -Members $_.sAMAccountName } >

Wenn es gewünscht ist einen bestimmten Benutzer zu den gleichen Gruppen hinzufügen in denen bereits ein anderer Benutzer Mitglied ist,
so kann man das ebenfalls mit der AD-PowerShell erledigen.

Den Benutzer Kaan kann man mit dem folgenden AD-PowerShellbefehl zu den gleichen Gruppen hinzufügen, in denen Yusuf Mitglied ist:

Get-ADPrincipalGroupmembership Yusuf | % {Add-ADPrincipalGroupmembership Kaan -MemberOf $_}

Mit den ds*-Tools

Mit den ds*-Tools die sich seit Windows Server 2003 on Bord befinden, lassen sich ebenfalls die Mitglieder einer Gruppe in eine andere Gruppe kopieren.
Mit den beiden Tools dsget sowie dsmod lässt sich das wie folgt bewerkstelligen:

dsget group "DN der Quell-Gruppe" -members | dsmod group "DN der Zielgruppe" -addmbr -c >

Mit einer gespeicherten Abfrage

Durch eine gespeicherte Abfrage kann man ebenfalls alle Mitglieder einer Gruppe in eine andere kopieren.
Dazu erstellt man in der MMC Active Directory-Benutzer und -Computer eine gespeicherte Abfrage mit diesem benutzerdefinierten Filter:

(objectCategory=user)(memberOf=CN=<Quell-Gruppe>,OU=<OU>,DC=Domäne,DC=de)

Ist die Abfrage erfolgt, markiert man mit STRG+A alle Benutzer, ruft mit einem Rechtsklick die Option "Einer Gruppe hinzufügen..." aus und wählt
anschließend die entsprechende Ziel-Gruppe aus. >

Gespeicherte Abfragen
Gespeicherte Abfragen für dsa.msc

In der Kommandozeile mit dem Tool NET

Mit dem Kommandozeilentool NET müssen zuerst alle Benutzer der entsprechenden Gruppe in eine Textdatei exportiert werden.
Der Befehl dazu lautet folgendermaßen:

Net Group <Quell-Gruppe> /Domain > C:\Benutzer.txt

Danach kann man automatisiert mit einer FOR-Schleife die exportierten Benutzer zur Zielgruppe wie folgt importieren:

FOR /F "delims=" %i IN (C:\Benutzer.txt) DO (Net Group <Ziel-Gruppe> %i /Add /Domain)

Das funktioniert jedoch nur mit globalen und universellen Sicherheits- sowie Verteilergruppen.
Domänenlokale Sicherheits- sowie Verteilergruppen werden ignoriert. >

Mit LDIFDE

Mit Ldifde lassen sich die Mitglieder einer bestimmten Gruppe wie folgt in eine andere Gruppe kopieren.
Dazu muss im ersten Schritt mit dem folgenden Befehl ein Export der Mitglieder aus der Quell-Gruppe durchgeführt werden:

Ldifde -f C:\Mitglieder.txt -r "(sAMAccountName=<Quell-Gruppe>)" -l member

Nach dem Export erhält man eine Datei mit folgendem Inhalt:

dn: CN=<Quell-Grupp>,OU=<OU>,DC=Domäne,DC=de
changetype: add
member: CN=Yusuf,OU=IT,DC=AD2008R2,DC=dikmenoglu,DC=de
member: CN=Kaan Dikmenoglu,OU=IT,DC=AD2008R2,DC=dikmenoglu,DC=de
member: CN=Aysim Dikmenoglu,OU=IT,DC=AD2008R2,DC=dikmenoglu,DC=de

Die Exportdatei muss dann wie folgt angepasst werden (der Bindestrich am Ende ist zwingend notwendig!):

dn: CN=<Ziel-Gruppe>,OU=<OU>,DC=Domäne,DC=de
changetype: modify
add: member
member: CN=Dikmenoglu\,Yusuf,OU=IT,DC=AD2008R2,DC=dikmenoglu,DC=de
member: CN=Kaan Dikmenoglu,OU=IT,DC=AD2008R2,DC=dikmenoglu,DC=de
member: CN=Aysim Dikmenoglu,OU=IT,DC=AD2008R2,DC=dikmenoglu,DC=de
-

Der Import muss dann mit diesem Befehl erfolgen:

Ldifde -i -f C:\Mitglieder.txt

LDIFDE - LDAP Data Interchange Format Data Exchange

Weitere Informationen:
Alle Benutzer einer OU aus einer bestimmten Gruppe entfernen
Alle Gruppenmitgliedschaften eines Benutzers exportieren
Active Directory - Abfrage

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Warum es ein dedizierter DC sein sollte!

Yusuf Dikmenoglu — Sun, 01 Aug 2010 10:24:05 GMT

Was in größeren und weltweiten AD-Umgebungen für selbstverständlich gehalten wird, sieht in kleineren und mittelständischen Unternehmen (KMUs) ganz anders aus.

Diese Frage wird oft gestellt: Warum sollte der Server ausschließlich als DC betrieben werden und kann der DC nicht weitere Dienste oder Applikationen zur Verfügung stellen?

Die Antwort darauf lautet: Ja, ein DC kann und darf weitere Dienste zur Verfügung stellen. Beispielsweise ist seitens Microsoft auch unterstützt, Applikationen wie z.B. Exchange oder SQL auf einem DC zu installieren. Doch es ist keineswegs empfohlen weitere Dienste oder Applikationen auf einem DC zu betreiben. Die Gründe folgen.

Viele Administratoren bringen an dieser Stelle nun den Einwand, dass der SBS doch das Paradebeispiel dafür ist. Ein SBS muss ein DC und darf nicht ein Mitgliedsserver sein. Des Weiteren existieren doch auch Exchange und SQL auf einem SBS. Die Antwort auf diese Argumentation lautet jedoch: Der SBS ist ein Spezialfall und ist gezielt für die Produktpositionierung so konzipiert worden. Mit dem SBS 2008 (Premium) wurde das entsprechend angepasst, in dem bspw. eine extra Windows Server Lizenz für die SQL Serverinstallation mitgeliefert wird.

Ein Schelm, wer Böses dabei denkt, dass der SBS kein echter Server sei. ;-)

Die Gründe weshalb es empfohlen ist, den Server nur als dedizierten DC zu betreiben und keine anderen Dienste zur Verfügung zu stellen sind:

Performance: Werden auf einem DC weitere Applikationen und Dienste installiert, kostet das Ressourcen. Damit steigt das Risiko, dass wenn sich viele Benutzer zur gleichen Zeit an der Domäne authentisieren, dem DC nicht genügend Ressourcen zur Verfügung stehen um jede Authentisierung eines Benutzers erfolgreich durchzuführen. Wenn intensiv mit AD-Abfragen gearbeitet wird, können die fehlenden Ressourcen den DC unnötig auslasten und von Nachteil sein.
Sicherheit: Werden auf einem DC Applikationen oder Dienste installiert, muss man bei entsprechender Rollentrennung dem Betreuer dieser Applikation bzw. der Dienste Rechte auf dem DC einräumen. Oftmals wird dann der Benutzer in die Gruppe der BuiltIn\Administratoren oder in die Gruppe der Domänen-Admins hinzugefügt, was beides selbstverständlich keineswegs gewünscht ist. Denn zum einen sind das zu viele Rechte die man dem Benutzer einräumt und zum anderen, birgt das Gefahren. Der Benutzer, wenn der DC auch noch der Einzige in der Domäne ist, könnte die Domäne gefährden.

Mit Einführung von Windows Server 2008 und dem RODC hat man die Situation entschärft, was die Sicherheit der AD DS anbetrifft. Der Administrator für die Anwendung kann auf einem RODC lokale Adminrechte erhalten und hat dennoch keine weiteren Rechte auf die AD DS.

Es sollten alle Server hinter Schloss und Riegel stehen und nur Befugten sollte der Zugang erlaubt sein. Doch aus AD-Sicht ist es nicht weiter tragisch wenn „nur“ der Applikationsserver anstatt eines DCs unter dem Schreibtisch steht.
Rollentrennung: Folgt man der Empfehlung und betreibt dedizierte DCs, kann man in einem Problemfall einen DC in einer Umgebung mit mehreren DCs einfach ersetzen. Ist jedoch auf dem DC eine wichtige Applikation installiert, gestaltet sich der Austausch besonders schwierig!
Stabilität: Das Installieren von Applikationen und Diensten gefährdet die Stabilität eines DCs (RWDC und RODC). Denn bereits das Installieren eines zusätzlichen nicht kompatiblen (Drucker?) Treibers kann zu Instabilitäten führen, so dass es regelmäßig zum BSOD (Blue Screen of Death) kommt. Dies kann natürlich auch zum Totalausfall des Active Directories führen, bspw. durch Inkonsistenzen die durch solche Abstürze entstehen. Wenn sich in der Domäne mehrere DCs befinden, kann man einen dedizierten DC im laufenden Betrieb herunterstufen, den Computernamen ändern und anschließend wieder zum DC heraufstufen. Ob das die installierte Applikation auf dem DC verkraftet ist fraglich. Ein installierter Exchange Server verhindert dies sehr wirkungsvoll.

Das sind die Hauptargumente warum es ein dedizierter DC sein sollte. Natürlich ist die Welt da draußen alles andere als rosarot und die Realität in der Praxis sieht anders aus. Man muss selbstverständlich unterscheiden, ob es sich um ein fünf-Mann oder um ein weitweites Unternehmen mit 500.000 Mitarbeitern handelt. In einem fünf Mann Unternehmen ist das Budget für IT-Kosten meist knapp und mit einem dedizierten DC würde man in solch einer Umgebung sicherlich mit Kanonen auf Spatzen schießen.

Daher gilt für Unternehmen die sich aus welchen Gründen auch immer keinen dedizierten DC leisten (können oder wollen), folgende Empfehlung:

Was die Performance des DCs anbetrifft, sollte eine Applikation bzw. Dienst vor dem Einsatz auf einem DC in einer produktiven Umgebung, ausgiebig in einer Testumgebung möglichst realitätsgetreu getestet werden. Das wichtigste dabei ist das Monitoring. Erst wenn die Tests nach mehreren Tagen zufriedenstellende Ergebnisse geliefert haben, sollte man die Applikation oder den Dienst auf dem DC in der produktiven Umgebung installieren. Bei den Tests die als Referenz dienen, sollte man über mehrere Tage die Auslastung des DCs (CPU, RAM, HDD, NIC) zu verschiedenen Zeitpunkten verteilt über den Tag aufzeichnen. Wurde die Applikation bzw. der Dienst auf dem produktiven DC installiert, sollte man die Auslastung des DCs ständig mit der Referenz vergleichen.
Natürlich ist das ein Kraftakt den sich ein Unternehmen mit 5 Angestellten zwei Mal überlegt, ob er diese Tests durchführen soll bzw. kann. Ich kann es aber jedem nur ans Herz legen!
Derjenige der die Applikation bzw. den Dienst auf einem DC mit Domänen-Adminrechten betreut, muss vertrauenswürdig sein. Schließlich kann der Betreuer mit Domänen-Adminrechten der Domäne schaden bis hin zu zerstören! Die Virtualisierung ist eine Möglichkeit, die einem bei der Rollentrennung behilflich sein kann.
Es sollten ausschließlich vertrauenswürdige Applikationen und Dienste die vorher ausgiebig getestet wurden auf einem DC installiert werden. Dabei sollte die Datensicherung mit höchster Priorität sichergestellt sein. Sowohl die tatsächliche Durchführung einer funktionierenden System State Sicherung auf der einen Seite, als auch die Sicherung der Daten auf der anderen Seite sollte stets überprüft werden.

Deshalb lautet die Empfehlung: Wann immer möglich sollte ein dedizierter DC eingesetzt werden! Ist das aus welchen Gründen auch immer nicht möglich, sollten vorher ausreichende Tests und eine regelmäßig Datensicherung durchgeführt werden. Dabei sollte die regelmäßige Überprüfung des Gesundheitszustands des DCs nicht vernachlässigt werden (Eventlog, DCDIAG etc.).

Warum Exchange nicht auf einem DC installiert werden sollte

Das Installieren von Exchange auf einem DC ist zwar seitens Microsoft supportet, es wird jedoch nicht empfohlen!

Die Gründe die zusätzlich zu den oben genannten Punkten gegen das Installieren von Exchange auf einem DC sprechen sind:

Wiederherstellung: Beide Technologien, AD und Exchange erfordern im Falle eine Rücksicherung eine hohe Aufmerksamkeit. Für die Rücksicherung beider Technologien müssen bestimmte Arbeitsschritte durchgeführt werden. Erschwerend kommt dann noch hinzu, dass bei einem Servercrash die Zeit für die Rücksicherung eine umso größere Rolle spielt. Wenn der DC der Einzige in der Domäne ist, dann umso mehr. Deshalb ist es aus Wiederherstellungsgründen einfacher, lediglich eine Technologie rücksichern zu müssen.
Abhängigkeit: Exchange benötigt zwingend ein funktionierendes AD! Wenn auf einem (wo möglich Einzigen?) DC ein Problem besteht, hat das evtl. Auswirkungen auf Exchange. Wenn sich das DC-Problem nicht lösen lässt, steht unter Umständen Exchange nicht zur Verfügung.
Sicherheit: Stellt man den Benutzern Outlook Web Access (OWA) zur Verfügung, hat der Benutzer durch den IIS aus dem Internet per HTTP Zugriff auf den DC. Doch meistens ist das nicht gewünscht, dass ein DC von extern egal über welches Protokoll erreichbar ist.

Der Exchange Administrator ist standardmäßig Mitglied in der Gruppe BuiltIn\Administratoren und ist dadurch Administrator auf den DCs! Das ist natürlich zwecks Rollentrennung und vor allem in größeren Umgebungen mit verteilter Administration nicht erwünscht.
Alle Exchange Dienste werden als LocalSystem ausgeführt, was ein größeres Sicherheitsrisiko darstellt wenn eine Sicherheitslücke entsteht. Existiert z.B. ein Sicherheitsloch im AD das einem Angreifer den Zugriff auf das AD erlaubt, kann dieser auch auf Exchange (und umgekehrt) zugreifen.
Ressourcen: Werden die zur Verfügung stehenden Ressourcen auf dem Exchange Server knapp (CPU, RAM, HDD, NIC), leidet darunter auch der DC. Denn läuft z.B. Exchange aus welchen Gründen auch immer voll, hat nicht nur Exchange ein Problem sondern auch der DC! Oder wenn sich ein Exchange-Dienst aufhängt und somit den ganzen Server auslastet, zieht das auch den DC in Mitleidenschaft so das dieser unter Umständen keine Anfragen mehr beantworten kann.
Neustart: Es kann bis zu zehn Minuten dauern den DC herunterzufahren bzw. neu zu starten. Denn standardmäßig wird der Dienst LSASS.exe in dem das AD ausgeführt wird eher beendet, bevor die Exchange Dienste die vom AD abhängig sind beendet werden. Dadurch kommt es zu mehreren Timeouts und deshalb zu dem langsamen Verhalten. Eine mögliche Abhilfe für dieses Problem ist die Exchange-Dienste (insbesondere den Informationstore) manuell zu stoppen, bevor der DC heruntergefahren oder neu gestartet wird.
DCPROMO: Des Weiteren ist das Ausführen von DCPROMO auf einem Exchange Server nicht supportet! Das bedeutet, wurde Exchange auf einem DC installiert, darf der DC nicht heruntergestuft werden. Zuerst müsste Exchange deinstalliert werden, ehe der DC anschließend heruntergestuft werden kann. Oder wenn Exchange auf einem Mitgliedsserver installiert wurde, darf dieser nicht mit DCPROMO zum DC heraufgestuft werden.

Siehe (unter dem Abschnitt "Directory Server Architecture\Installing Exchange 2010 on Directory Servers"):
Exchange 2010 System Requirements: Exchange 2010 Help
Exchangeabhängigkeit vom GC: Selbst wenn man mehr als einen DC/GC in der Domäne besitzt, wird Exchange immer den DC/GC nutzen, auf dem es installiert ist. Das bedeutet im Umkehrschluss, dass Exchange den Betrieb einstellt, sollte mit der DC Funktion auf dem Server etwas im Argen liegen.

Exchange resident on domain controller that is not a global catalog server >

Fazit: Als Best Practice ist es empfehlenswert einen dedizierten DC zu betreiben und Exchange auf einem Mitgliedsserver anstatt auf einem DC zu installieren. Ist das aus organisatorischen Gründen (Kosten etc.) nicht möglich, ist eine funktionierende Datensicherung neben dem Monitoring das Mindeste das regelmäßig durchgeführt werden sollte! Bei der Rollentrennung und bei der Installation von Exchange ist die Virtualisierung eine hilfreiche Option.

Virtualization Support Wizard
Exchange Server Supportability Matrix

Weitere Informationen:
Wie viele DCs pro Domäne werden benötigt?
Die Besonderheiten eines Small Business Server`s (SBS)
Images als Sicherung?
Zwei wichtige IDs eines DCs: DC GUID und InvocationId
Security Considerations for a SQL Server Installation

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Password Setting Objects erstellen und verwalten

Yusuf Dikmenoglu — Sat, 17 Jul 2010 22:19:47 GMT

Bis einschließlich Windows Server 2003 kann mit Bordmittel nur eine Kennwort- und Kontosperrungsrichtlinie innerhalb einer Domäne auf Domänenbenutzer wirken. Damit die Richtlinien auf Domänenbenutzer wirken, müssen diese zwingend auf Domänenebene verlinkt werden. Wenn stattdessen die beiden Richtlinien auf eine Organisationseinheit (OU) verlinkt werden, wirkt sich das lediglich auf die Computer die sich in dieser OU befinden aus und die Kennwortvorgaben gelten somit nur für die lokalen Benutzerkonten, die sich auf diesen Computern befinden!

Möchte man bis Windows Server 2003 mit Bordmittel mehrere Kennwortrichtlinien nutzen, muss man weitere Domänen erstellen, was natürlich den Ressourceneinsatz sowie den Verwaltungsaufwand wesentlich erhöht. Man kann sich aber auch zusätzliche Kennwortfilter erstellen oder weicht auf Dritt-Anbieter Lösungen aus.

Die Kennwort- und Kontosperrungsrichtlinie sollten in allen Serverversionen stets in der Default Domain Policy (DDP) konfiguriert werden, nicht zuletzt, da die DDP standardmäßig ohnehin schon auf der Domänenebene verlinkt ist. Ein weiterer viel wichtiger Punkt ist, das man in den Eigenschaften der Domänenpartition die Attribute die für beide Richtlinien relevant sind (maxPwdAge, minPwdAge, minPwdLength, pwdHistoryLength, pwdProperties, lockoutDuration, lockOutObservationWindow, lockouThreshold etc.) auf dem PDC-Emulator auch direkt konfigurieren kann. Die Konfiguration der Kennwortvorgaben muss nicht zwingend in der DDP vorgenommen werden. Durch einen automatisierten Prozess werden dann die Änderungen die man in den Attributen vorgenommen hat vom PDC-Emulator in die beiden Richtlinien, aber nur in die DDP übertragen!

Es gilt zu beachten, dass die Kennwortoptionen unter den Computerkonfigurationen in der Gruppenrichtlinie und nicht wie man annehmen könnte, unter den Benutzerkonfigurationen konfiguriert wird! Die Benutzerobjekte können mit den Kennworteinstellungen nichts anfangen. Die Kennwortoptionen werden nur von Computerobjekten verwertet und befinden sich unter:

Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Kontorichtlinien\Kennwortrichtlinien

und

Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Kontorichtlinien\Kontosperrungsrichtlinien

Die fein abgestimmten Kennwortrichtlinien

Seit Windows Server 2008 ist es mit Bordmittel nun endlich möglich, mehrere Kennwort- und Kontosperrungsrichtlinien für verschiedene Benutzergruppen innerhalb einer einzigen Domäne zu erstellen. Genau genommen sind es keine weiteren Richtlinien, sondern Active Directory (AD) Objekte. Die AD Objekte nennen sich Kennworteinstellungsobjekte und lauten im Fachjargon Password Setting Objects, kurz PSO.

Mit dieser Funktion die auch als granulare Kennwort- und Kontosperrungsrichtlinien oder als fein abgestimmte/abgestufte Kennwortrichtlinien (auf Englisch: Fine-Grained Password Policy, FGPP) bezeichnet wird, können getrennte Kennwort- und Kontosperreinstellungen für bestimmte Benutzer in der Domäne eingerichtet werden. Standardmäßig können die Mitglieder der Gruppe Domänen-Admins verschiedene Kennwortbeschränkungen und Kontosperreinstellungen für verschiedene Benutzertypen in der Domäne einrichten. Das Erstellen und administrieren von PSOs kann aber auch an eine entsprechende Gruppe delegiert werden.

Durch die beiden neuen Objektklassen Password Settings Container (PSC) und Password Settings die dem AD-Schema ab Windows Server 2008 hinzugefügt wurden, ist das Erstellen und Speichern von PSOs möglich. Der PSC in dem die PSOs für die Domäne gespeichert werden wird standardmäßig im Container System erstellt, dass sich in jeder Domänenpartition befindet. Der LDAP-Pfad zum PSC lautet CN=Password Settings Container,CN=System,DC=Domäne,DC=de.

Aktiviert man in der MMC Active Directory-Benutzer und -Computer unter Ansicht die „Erweiterten Features“, kommt der System Container in dem sich der PSC befindet zum Vorschein. Das systemflags Attribut in den Eigenschaften des PSCs verhindert, dass der Container weder verschoben, noch umbenannt oder gar gelöscht werden kann.

Die Voraussetzungen

Der Domänenfunktionsmodus muss sich mindestens auf der Ebene Windows Server 2008 befinden! Der Gesamtstrukturfunktionsmodus wiederum kann sich z.B. auf der Ebene Windows Server 2003 befinden. Somit dürften sich in der Gesamtstruktur noch Domänen mit Windows Server 2003 DCs befinden, die dann aber keine PSOs einsetzen können!
PSOs können nur auf Benutzerobjekte, globale Sicherheitsgruppen und auf inetOrgPerson-Objekte angewendet werden. Die Gruppenbereiche „Lokal (in Domäne)“ und „Universal“ sowie der Gruppentyp „Verteiler“ werden nicht berücksichtigt! Es ist empfehlenswert PSOs lediglich auf globale Gruppen zu verlinken. Dadurch müssen die Benutzer die eine andere Kennwortvorgabe erhalten sollen, nur noch zur entsprechenden Gruppe hinzugefügt werden.
Auf eine OU können PSOs nicht direkt angewendet werden! Stattdessen kann man eine Schattengruppe (shadow group) verwenden, die der OU logisch zugeordnet ist. Eine Schattengruppe ist nichts anderes als eine globale Sicherheitsgruppe. Alle Benutzer einer OU werden dann zu dieser Schattengruppe hinzugefügt und die PSO wird dieser Schattengruppe zugewiesen. Wird ein Benutzer aus einer OU in eine andere verschoben, muss die Mitgliedschaft der Schattengruppe angepasst werden, falls der Benutzer die PSO der neuen OU zugewiesen bekommen soll.
Auf einen Benutzer kann immer nur ein einziges PSO wirken!
PSOs können nur im PSC erstellt werden!
Das ein und dasselbe PSO kann auf mehrere Benutzer und/oder Gruppen angewandt werden, die sich in der gleichen Domäne befinden wie das PSO.
Es gibt kein eigenes Bordmittel für PSOs. Ein PSO kann nicht in der MMC Active Directory-Benutzer und -Computer erstellt werden, lediglich das Anzeigen ist möglich. PSOs können mit Bordmittel mit der MMC ADSIEdit, mit dem Kommandozeilentool LDIFDE, LDP oder der AD-PowerShell erstellt und administriert werden. Zusätzlich gibt es aber im Internet kostenlose Tools, die einem das Leben mit den PSOs erleichtern.

Die Attribute eines PSO

Ein PSO in dem die Kennwortvorgaben und Kontosperreinstellungen konfiguriert werden, hat Attribute für alle Kennwortoptionen, die ebenfalls in der DDP festgelegt werden können (bis auf die Kerberos-Einstellungen).

In einem PSO existieren die Attribute für die folgenden Kennwort- und Kontosperreinstellungen:

Vorrang: Das Attribut msDS-PasswordSettingsPrecedence dient zum Lösen von Konflikten, wenn auf ein Benutzer- oder Gruppenobjekt mehrere PSOs verlinkt sind. Dieses Attribut entscheidet letztendlich darüber welches PSO angewendet wird, falls mehrere PSOs auf ein Benutzer- oder Gruppenobjekt verlinkt sind. Das PSO, das den niedrigsten Wert in diesem Attribut enthält wird angewendet. Existieren mehrere PSOs mit dem gleichen Wert, gewinnt das PSO dessen GUID niedriger ist! Als Werte wird jeder Wert akzeptiert, der größer als 0 ist.
Kennwörter mit umkehrbarer Verschlüsselung speichern: Diese Option wird im Attribut msDS-PasswordReversibleEncryptionEnabled konfiguriert. Als Werte können FALSE und TRUE vergeben werden. Es versteht sich von selbst, dass man der Empfehlung folgen und hier als Wert FALSE vergeben sollte. Ansonsten würden die Kennwörter im Klartext abgespeichert werden, was ein erhebliches Sicherheitsrisiko darstellt!
Kennwortchronik erzwingen: Für diese Option ist das Attribut msDS-PasswordHistoryLength zuständig. Hiermit wird die Anzahl der zu speichernden Kennwörter festgelegt. Wird als Wert 10 konfiguriert, werden die letzten 10 Kennwörter die der Benutzer vergeben hatte gespeichert. Wenn der Benutzer aufgefordert wird ein neues Kennwort zu vergeben, darf es kein Kennwort von den letzten 10 Kennwörtern sein. Der Wert muss zwischen 0 und 1024 liegen. Wird als Wert 0 vergeben, werden keine Kennwörter gespeichert.
Kennwort muss Komplexitätsvoraussetzungen entsprechen: Hinter dieser Option steckt das Attribut msDS-PasswordComplexityEnabled. Als Werte können hier FALSE (Deaktiviert) und TRUE (Aktiviert) vergeben werden, wobei TRUE empfohlen ist. Mit dieser Option wird festgelegt, dass das Kennwort komplex sein muss.

Komplex bedeutet:

1. Das Kennwort darf nicht den Kontonamen des Benutzers oder mehr als zwei Zeichen enthalten, die nacheinander im vollständigen Namen des Benutzers vorkommen.
2. Das Kennwort muss mindestens sechs Zeichen lang sein.
3. Das Kennwort muss Zeichen aus drei der folgenden Kategorien enthalten:
- Großbuchstaben (A bis Z)
- Kleinbuchstaben (a bis z)
- Zahlen zur Basis 10 (0 bis 9)
- Nicht alphabetische Zeichen (zum Beispiel !, $, #, %)
Minimale Kennwortlänge: Die minimale Kennwortlänge wird im Attribut msDS-MinimumPasswordLength konfiguriert. In diesem Attribut muss angegeben werden, aus wie vielen Zeichen das Kennwort mindestens bestehen muss. Als Wert kann 0 bis 255 vergeben werden, wobei mit 0 der Benutzer selbst die Länge seines Kennworts bestimmen kann.
Minimales Kennwortalter: Das minimale Kennwortalter im PSO konfiguriert man im Attribut msDS-MinimumPasswordAge. Dieses Attribut gibt vor, wie alt ein Kennwort mindestens sein muss ehe es geändert werden darf. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) erfolgen. Soll der Benutzer erst nach fünf Tagen sein Kennwort ändern dürfen, so muss als Wert 5:00:00:00 eingetragen werden. Man kann aber auch als Wert mit Klammern (Nie) oder 0 eingeben, um kein Mindestalter zu definieren. Dadurch kann der Benutzer noch am selben Tag sein Kennwort erneut ändern. Der Wert von msDS-MinimumPasswordAge muss „kleiner als“ oder „gleich“ dem Wert von msDS-MaximumPasswordAge sein.
Maximales Kennwortalter: Das Attribut das hinter dieser Option steckt lautet msDS-MaximumPasswordAge. Mit dieser Option wird angegeben, nach wie vielen Tagen spätestens der Benutzer sein Kennwort ändern muss. Dieser Wert muss „gleich“ oder „größer“ als der Wert im Attribut msDS-MinimumPasswordAge sein. Die Zeitangabe muss in diesem Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) eingegeben werden. Vergibt man als Wert mit Klammern (Nie), läuft das Kennwort des Benutzers nicht ab. Als Wert kann nicht 0 konfiguriert werden.

Des Weiteren existieren im PSO Attribute, mit denen man die folgenden Kontosperreinstellungen konfigurieren kann:

Kontensperrungsschwelle: Die Anzahl maximal möglicher Fehlversuche bei der Benutzeranmeldung bestimmt das Attribut msDS-LockoutThreshold. Als Wert kann man 0 bis 65535 eintragen, wobei 0 diese Option deaktiviert. Dann erfolgt niemals eine Kontosperrung. Das ist allerdings aus Sicherheitsgründen, z.B. wegen Brute Force Attacken nicht zu empfehlen!
Zurücksetzungsdauer des Kontosperrungszählers: Wie lange die fehlgeschlagenen Anmeldeversuche zwischengespeichert werden, bevor der Kontosperrungszähler auf 0 zurückgesetzt wird, bestimmt das Attribut msDS-LockoutObservationWindow. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) angegeben werden. Möchte man als Wert 30 Minuten eintragen, so gilt es die Zeit wie folgt einzugeben 00:00:30:00. Der Wert von msDS-LockoutObservationWindow darf nicht „größer“ als der Wert von msDS-LockoutDuration sein, höchstens „gleich“! Denn es ist nicht möglich, den Kontosperrungszähler länger aktiv zu halten als die Zeit, die das Konto gesperrt und somit im Attribut msDS-LockoutDuration konfiguriert ist.
Kontosperrdauer: Wie lange ein Benutzerkonto nach den Anmeldefehlversuchen (es zählt der Wert im Attribut msDS-LockoutThreshold) gesperrt werden soll, ehe es automatisch entsperrt wird, definiert man im Attribut msDS-LockoutDuration. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) erfolgen. Wird als Wert mit Klammern (Nie) eingetragen, entsperrt sich das Benutzerkonto nicht automatisch. Stattdessen muss ein Administrator manuell das Konto entsperren. Der Wert im Attribut msDS-LockoutDuration darf nicht „kleiner“ sondern höchstens „gleich“ sein, als der Wert in msDS-LockoutObservationWindow.

Ferner existiert im PSO zusätzlich noch dieses Attribut:

PSO-Link: Im PSO-Link hinter dem das mehrwertige Attribut msDS-PSOAppliesTo steckt, konfiguriert man auf welche Objekte das PSO angewendet werden soll. Das bedeutet, ein PSO kann auf mehrere Benutzer und/oder Gruppen angewendet werden. In diesem Forward-Link muss der LDAP-Pfad bzw. der Distinguished Name (DN) des Objekts eingetragen werden, auf dem das PSO wirken soll.

Das Pendant zum Forward-Link ist das Back-Link, dass Attribut msDS-PSOApplied. In diesem Back-Link das den Benutzer und Gruppenobjekten ab Windows Server 2008 hinzugefügt wurde, ist das PSO bzw. wenn mehrere PSOs auf ein Benutzerobjekt direkt oder indirekt infrage kommen, sind die PSOs enthalten, mit dem das Objekt verknüpft ist. Welches PSO dann letztendlich auf ein Benutzerkonto angewandt wird, entscheidet der Richtlinienergebnissatz (Resultant Set of Policy, RSOP), genauer das Attribut msDS-ResultantPSO das sich ebenfalls in den Eigenschaften eines Benutzerobjekts befindet.
Back-Links werden als constructed Attributes bezeichnet was nichts anderes bedeutet, als dass diese Art von Attribut von jedem DC selbst veraltet wird und der Wert eines solchen Attributs auch nicht vom Administrator bearbeitet werden kann. Es ist ein system-only Attribut und wird auch nicht auf andere DCs repliziert. Des Weiteren wird ein Back-Link und sein Wert erst zum Zeitpunkt der Abfrage generiert.

Verknüpfte Attribute
Die konstruierten Attribute abfragen

Die PSO-Attribute mit einer Zeitangabe

Es gibt im PSO vier Attribute die als Wert eine Zeitangabe im Form von Tage:Stunden:Minuten:Sekunden verlangen.
Die vier Attribute sind:

- msDS-MaximumPasswordAge
- msDS-MinimumPasswordAge
- msDS-LockoutObservationWindow
- msDS-LockoutDuration

Erstellt man ein PSO in der AD-PowerShell oder mit ADSIEdit, muss man die Zeitangabe nach der Vorgabe tt:ss:mm:ss konfigurieren. Möchte man jedoch ein oder mehrere PSOs mit LDIFDE erstellen, so müssen die Werte in diesen Attributen im I8-Format angegeben werden! Im I8-Format wird die Zeit in Intervallen von -100 Nanosekunden (Schema: attributeSyntax = 2.5.5.16 (I8)) gespeichert. Unter Windows Server 2003 wird in der Default Domain Policy genau diese Zeiteinheit für die entsprechenden Zeit-bezogenen Attribute verwendet. Um in diesen vier Attributen die entsprechenden Werte zu konfigurieren, gilt es die Zeitangabe in Tage, Stunden oder Minuten in die Intervalle von -100 Nanosekunden zu konvertieren. Anschließend muss dem konvertierten Ergebnis noch ein negatives Vorzeichen (das Minuszeichen „-„) vorangestellt werden.

Zum umrechnen der Zeit können die folgenden Umrechnungsformel verwendet werden, um die entsprechenden I8-Werte zu erhalten:

Tage: Die Umrechnungsformel für einen Tag lautet = -24*60*60*(10^7) = -864000000000.
Demzufolge würde der Wert für fünf Tage so lauten: -4320000000000 (5*864000000000).

Stunden: Eine Stunde wird wie folgt umgerechnet: -60*60*(10^7) = -36000000000.
Der Wert für zwei Stunden lautet -72000000000 (2*36000000000).

Minuten: Die Formel für eine Minute lautet = -60*(10^7) = -600000000.
Sollen 30 Minuten ins I8-Format konvertiert werden, so lautet das Ergebnis -18000000000 (30*600000000).

Welches PSO wird angewendet und hat Vorrang, falls mehrere PSOs infrage kommen?

PSOs können sowohl Benutzerobjekten als auch globalen Sicherheitsgruppen zugewiesen werden. Der Richtlinienergebnissatz (RSOP) kann jedoch nur für das Benutzerobjekt berechnet werden. Sind mehrere PSOs mit einem Benutzer oder einer globalen Gruppe verknüpft, wird der RSOP wie folgt berechnet:

Es wird zuerst geprüft, ob ein PSO direkt mit dem Benutzerkonto verknüpft ist. Ist das der Fall, wird dieses PSO angewendet. Sind mehrere PSOs direkt mit dem Benutzerkonto verknüpft, gewinnt das PSO, das den niedrigsten Wert im Attribut msDS-PasswordSettingsPrecedence enthält! Existieren mehrere PSOs mit demselben Wert im Attribut msDS-PasswordSettingsPrecedence, wird das PSO auf das Benutzerkonto angewendet dessen GUID niedriger ist!
Wenn kein PSO direkt mit dem Benutzerobjekt verknüpft ist, werden die Mitgliedschaften in den globalen Sicherheitsgruppen des betreffenden Benutzers überprüft. Existiert darunter eine Gruppe das mit einem PSO verknüpft ist, wird das PSO auf Umwege auf das Benutzerkonto angewendet. Befindet sich der Benutzer in mehreren globalen Gruppen auf denen verschiedene PSOs verknüpft sind, wird das PSO auf das Benutzerkonto angewendet, das den niedrigsten Wert im Attribut msDS-PasswordSettingsPrecedence hat! Wenn mehrere PSOs mit demselben Wert im Attribut msDS-PasswordSettingsPrecedence existieren, wird das PSO auf das Benutzerkonto angewendet dessen GUID niedriger ist!
Wenn kein PSO direkt oder indirekt per globaler Sicherheitsgruppe mit einem Benutzerobjekt verknüpft ist, werden die Kennwort- und Kontosperrungsrichtlinien aus der Default Domain Policy angewandt! Deshalb sollten immer die Kennwort- und Kontosperrungsrichtlinien in der DDP konfiguriert werden, um eine Mindestanforderung an die Benutzerkennwörter zu stellen.
Existiert ein PSO das direkt oder indirekt mit einem Benutzerobjekt verknüpft ist, hat das PSO stets vor der DDP Vorrang! Erst wenn ermittelt wurde, dass letztendlich einem Benutzerobjekt kein PSO zugewiesen wurde, greifen die Kennwortbeschränkungen aus der DDP.
Welches PSO letzten Endes auf ein Benutzerkonto angewendet wird, entscheidet das RSOP! Denn ein weiteres neues constructed Attribut das dem Benutzerobjekt ab Windows Server 2008 hinzugefügt wurde, lautet msDS-ResultantPSO. In diesem Attribut ist der DN des PSOs gespeichert, das letztendlich nach den o.g. Regeln auf den Benutzer angewandt wird.

Mehr über constructed Attribute gibt es hier:
Die konstruierten Attribute abfragen
Es gibt jedoch drei Einstellungen die direkt im Benutzerobjekt vorgenommen werden können, um stets die Kennwortvorgaben eines PSOs auszuhebeln. Die drei Optionen lassen sich mit den Flags des userAccountControl Attributs konfigurieren und sind:
- Kennwort läuft nie ab
- Kennwort mit umkehrbarer Verschlüsselung speichern
- Kennwort nicht erforderlich

How to use the UserAccountControl flags to manipulate user account properties

Im Übrigen setzen diese drei Flags die Kennwortvorgaben die in der DDP konfiguriert sind, ebenso außer Kraft!

PSOs mit der AD-PowerShell erstellen und verwalten

Unter „Windows Server 2008“ konnten PSOs mit Bordmittel lediglich mit ADSIEdit, LDIFDE sowie LDP erstellt und administriert werden. Ab „Windows Server 2008 R2“ können PSOs mit einem weiteren Bordmittel, mit dem State of the Art Werkzeug der AD-PowerShell erstellt und verwaltet werden.

Auch unter Windows Server 2003 und Windows Server 2008 kann man die AD-PowerShell nach vorheriger Installation der AD-Management Gateway Services nutzen.

Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008

Zum Überprüfen und konfigurieren der Kennwort- und Kontosperrungsrichtlinie in der DDP gibt es ebenfalls die beiden AD-PowerShell Cmdlets Get-ADDefaultDomainPasswordPolicy und Set-ADDefaultDomainPasswordPolicy. Das Cmdlet Get-ADDefaultDomainPasswordPolicy mit dem die Kennwortoptionen direkt aus den Attributen (und nicht aus der DDP) die sich in der Domänenpartition befinden abgerufen werden, zeigt die Kennwortvorgaben die mit der DDP verteilt werden an.

Das Cmdlet Set-ADDefaultDomainPasswordPolicy ändert nicht etwa die Kennworteinstellungen in der DDP, sondern direkt die Attribute die sich in der Domänenpartition befinden. Wie die einzelnen Kennwortoptionen zum Konfigurieren in der AD-PowerShell lauten, erfährt man mit dem Befehl Get-Help <Cmdlet> -Full. Also z.B. Get-Help Set-ADDefaultDomainPasswordPolicy –Full.>>>>>

Zum Administrieren der PSOs in der AD-PowerShell stellt Microsoft diese acht Cmdlets zur Verfügung:

- Add-ADFineGrainedPasswordPolicySubject
- Get-ADFineGrainedPasswordPolicy
- Get-ADFineGrainedPasswordPolicySubject
- Get-ADUserResultantPasswordPolicy
- New-ADFineGrainedPasswordPolicy
- Remove-ADFineGrainedPasswordPolicy
- Remove-ADFineGrainedPasswordPolicySubject
- Set-ADFineGrainedPasswordPolicy >

Mit diesem Einzeiler lässt sich ein PSO wie folgt erstellen:

New-ADFineGrainedPasswordPolicy –Name “PSO für die GF” –Precedence 20 –ComplexityEnabled $true –Description “Dieses PSO gilt nur für die GF” –Displayname “GF-PSO” –LockoutDuration “0.00:15:00” –LockoutObservationWindow “0.00:15:00” –LockoutThreshold 15 -MaxPasswordAge "60.00:00:00" -MinPasswordAge "5.00:00:00" -MinPasswordLength 8 -PasswordHistoryCount 10 -ReversibleEncryptionEnabled $false
Ist das PSO erstellt, muss es anschließend mit dem folgenden Befehl an einen Benutzer oder eine Gruppe wie folgt zugewiesen werden:

Add-ADFineGrainedPasswordPolicySubject <Name der PSO> <Benutzer/Gruppe>
Einzelne Optionen lassen sich in einem bestehenden PSO folgendermaßen ändern:

Set-ADFineGrainedPasswordPolicy “CN=<Name der PSO>,CN=Password Settings Container,CN=System,DC=Domäne,DC=de” –Precedence 15 -MinPasswordLength 12
Alle PSOs mit den konfigurierten Kennwortoptionen lassen sich mit diesem Befehl Anzeigen:

Get-ADFineGrainedPasswordPolicy -Filter { Name -Like "*" }
Welches PSO letzten Endes auf einen Benutzer wirkt und wie die einzelnen Kennwortoptionen konfiguriert sind, erfährt man mit diesem Befehl:

Get-ADUserResultantPasswordPolicy <Benutzer>
Mit der AD-PowerShell kann man sogar abfragen, auf welche Benutzer- und/oder Gruppenobjekte ein bestimmtes PSO verlinkt ist. Der Befehl lautet:

Get-ADFineGrainedPasswordPolicySubject <Name der PSO>
Um die Verlinkung einer PSO von einem Benutzer oder von einer Gruppe zu entfernen, muss dieser Befehl ausgeführt werden:

Remove-ADFineGrainedPasswordPolicySubject <Name der PSO> -Subjects <Benutzer/Gruppen> -Confirm:$False
Eine PSO kann man in der AD-PowerShell so löschen:

Remove-ADFineGrainedPasswordPolicy <Name der PSO> -Confirm:$False

Ein PSO mit ADSIEdit erstellen

Die Attribute eines PSO, müssen zwingend in dieser Reihenfolge bei der Erstellung mit ADSIEdit konfiguriert werden.
Das Erstellen eines PSOs erfolgt mit Bordmittel in ADSIEdit wie folgt:

Zuerst verbindet man sich in ADSIEdit mit der Domänenpartition und navigiert zum Container CN=Password Settings Container,CN=System,DC=Domäne,DC=de.
Mit einem Rechtsklick auf den PSC kann man unter Neu - Objekt… ein PSO, das zur Klasse msDS-PasswordSettings gehört erstellen.
Mit einem Klick auf Weiter muss der Common-Name im Attribut cn angegeben werden. Der CN ist ein Name, der das PSO eindeutig identifiziert (z.B. „PSO für GF“ etc.).
Im nächsten Schritt muss der Password Settings Precedence, der Wert für das Attribut msDS-PasswordSettingsPrecedence angegeben werden. Der Wert (der größer 0 sein muss!) der hier eingetragen wird entscheidet darüber, welches PSO auf das Objekt letztendlich angewendet wird, falls mehrere PSOs auf das Objekt verlinkt sind. Das PSO das den niedrigsten Wert in diesem Attribut enthält, wird auf das Objekt angewendet. Existieren mehrere PSOs mit dem gleichen Wert, gewinnt das PSO dessen GUID niedriger ist.
Dann muss für die Option Password reversible encryption status for user accounts im Attribut msDS-PasswordReversibleEncryptionEnabled entweder als Wert FALSE (was empfohlen ist!) oder TRUE eingegeben werden.
Als nächstes muss bei der Option Password History Length for user accounts ein Wert zwischen 0 und 1024 im Attribut msDS-PasswordHistoryLength vergeben werden.
Bei der Option Password complexity status for user accounts muss im Attribut msDS-PasswordComplexityEnabled als Wert FALSE oder TRUE vergeben werden. Wobei TRUE die empfohlene Einstellung ist.
Danach gibt man bei der Option Minimum Password Length for user accounts im Attribut msDS-MinimumPasswordLength die Mindestlänge, die ein Kennwort zwingend haben muss an! Es kann ein Wert zwischen 0 und 255 vergeben werden.
Nun muss im Attribut msDS-MinimumPasswordAge für die Option Minimum Password Age for user accounts das minimale Kennwortalter angegeben werden, ehe es vom Benutzer geändert werden darf. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) angegeben werden (z.B. 7:00:00:00 für sieben Tage). Wird als Wert mit Klammern (Nie) eingetragen, wird kein Mindestalter definiert.
Im darauffolgenden Schritt muss man in der Option Maximum Password Age for user accounts im Attribut msDS-MaximumPasswordAge diesmal das maximale Alter eines Kennworts eingeben. In diesem Attribut wird definiert, nach wie vielen Tagen spätestens der Benutzer sein Kennwort ändern muss! Auch hier muss die Zeitangabe im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) erfolgen. Es dürfte jedem klar sein, dass dieser Wert gleich oder höher sein muss als der Wert im Attribut msDS-MinimumPasswordAge.
Bei der nächsten Option Lockout threshold for lockout of user accounts muss im Attribut msDS-LockoutThreshold der Wert für die Kontosperrschwelle eingegeben werden. Wie oft der Benutzer sein Kennwort falsch eingeben darf ehe sein Benutzerkonto gesperrt wird, legt man in diesem Attribut fest. Als Wert kann zwischen 0 und 65535 gewählt werden. Gibt man als Wert 0 ein, wird das Benutzerkonto nie gesperrt.
Mit der Option Observation Window for lockout of user accounts bestimmt man im Attribut msDS-LockoutObservationWindow, wie lange die Anmeldefehlversuche gespeichert werden sollen, ehe der Kontosperrungszähler zurückgesetzt wird. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) angegeben werden. Möchte man die Zeit auf 20 Minuten festlegen, so muss der Wert folgendermaßen konfiguriert werden 00:00:20:00.
Zum Schluss muss man noch für die Option Lockout duration for locked out user accounts im Attribut msDS-LockoutDuration die Kontosperrdauer angeben. Das Format der Zeitangabe muss so aussehen Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss). Wenn also der Benutzer sein Kennwort mehr als der Wert, der im Attribut msDS-LockoutThreshold definiert ist falsch eingegeben hat und das Benutzerkonto für zehn Minuten gesperrt werden soll, muss man diesen Wert eintragen 00:00:10:00.
Nun gelangt man auf die letzte Seite, auf der man zum einen Fertig stellen und zum anderen auf Weitere Attribute klicken kann. Mit einem Klick auf Weitere Attribute öffnet sich ein weiteres Dialogfenster in dem man die Benutzer und Gruppen angeben kann, mit denen dieses PSO verknüpft werden soll. Dort gilt es im Feld Anzuzeigende Eigenschaften den Eintrag Optional und im Feld Anzuzeigende Eigenschaft das Attribut msDS-PSOAppliesTo auszuwählen. Daraufhin muss im Feld Attribut bearbeiten der DN des Objekts angegeben werden, auf dem das PSO angewendet werden soll. Da es sich hierbei um ein mehrwertiges Attribut handelt, können mehrere Objekte angegeben werden, auf denen dasselbe PSO wirken soll. Wenn ein DN eingetragen wurde, muss der Wert mit Hinzufügen in das Feld Wert(e) übernommen werden. Wurden alle Werte eingetragen, gelangt man mit OK zum Dialogfeld Objekt erstellen zurück.
Mit einem Klick auf Fertig stellen wird nun endlich das PSO im „Password Settings Container“ erstellt. Falls ein Attribut einen ungültigen Wert enthält, erscheint nach dem Klick auf Fertig stellen eine Fehlermeldung.

Nach dem bestätigen der Fehlermeldung mit OK kann man im Dialogfenster Objekt erstellen zurück zum bemängelten Attribut navigieren, um den Wert zu korrigieren. Die Verdächtigen sind dabei die Attribute, die eine Zeitangabe in Form von Tage:Stunden:Minuten:Sekunden enthalten. Z.B. darf der Wert im Attribut msDS-LockoutObservationWindow nicht größer sein (höchstens gleich) als der Wert im Attribut msDS-LockoutDuration. Auch das UAC kann schuld sein. Das ADSIEdit sollte explizit als Administrator gestartet werden.

PSOs mit LDIFDE erstellen

Es gibt auch eine skriptbasierte Alternative, mit dem PSOs erstellt werden können. Das Erstellen von PSOs kann auch mit dem Kommandozeilentool LDIFDE automatisiert durchgeführt werden.

Die Einträge in der LDF Datei müssen folgendermaßen aussehen:

dn:CN=PSO,CN=Password Settings Container,CN=System,DC=Domäne,DC=de
changetype:add
objectClass:msDS-PasswordSettings
msDS-MaximumPasswordAge:-51840000000000 (entspricht 60 Tage)
msDS-MinimumPasswordAge:-1728000000000 (entspricht 2 Tage)
msDS-MinimumPasswordLength:8
msDS-PasswordHistoryLength:20
msDS-PasswordComplexityEnabled:TRUE
msDS-PasswordReversibleEncryptionEnabled:FALSE
msDS-LockoutObservationWindow:-36000000000 (entspricht 60 Minuten)
msDS-LockoutDuration:-36000000000 (entspricht 60 Minuten)
msDS-LockoutThreshold:0
msDS-PasswordSettingsPrecedence:10
msDS-PSOAppliesTo:CN=<Gruppe>,OU=<OU>,DC=Domäne,DC=de

Der Import erfolgt mit diesem Befehl:

Ldifde -i -f C:\PSO.ldf>>>>>

Weitere Informationen:
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
Domänen- und Gesamtstrukturfunktionsmodus
LDIFDE - LDAP Data Interchange Format Data Exchange

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Was passiert in der AD-Datenbank wenn ein Objekt gelöscht wird?

Yusuf Dikmenoglu — Sun, 04 Jul 2010 13:06:25 GMT

Das Active Directory (AD), das auf dem Extensible Storage Engine (ESE) Datenbankmodul basiert organisiert Objekte in einer hierarchischen Baumstruktur und stellt die Hierarchie der Objekte für eine Gesamtstruktur. Das AD speichert die transaktionale Datenbank intern in drei Tabellen: Datentabelle (Data-Table), Verknüpfungstabelle (Link-Table) und in der erweiterten Sicherheitseinstellungen Tabelle (Security Descriptor-Table, kurz SD-Table). Die beiden wichtigsten Tabellen in der sich die Daten des AD befinden ist die Datentabelle, die alle Objekte sowie Attribute enthält und die Verknüpfungstabelle, in der die Beziehungen zwischen den Objekten gespeichert werden.

Siehe auch: Verknüpfte Attribute

In der Datentabelle wird jedes Attribut und jedes Objekt in einer einzelnen Zeile, mit einer Spalte pro Attribut gespeichert. Das bedeutet, jede Zeile in der Datentabelle entspricht einem Attribut bzw. Objekt. Die Einträge die sich auf einem Domänencontroller (DC) in der Datentabelle befinden, sind aus der Schema-, Konfigurations-, Anwendungs- und Domänenpartition. Die Datentabelle eines globalen Katalogs (GC) enthält neben den Einträgen aus den bereits erwähnten Verzeichnispartitionen, zusätzlich noch die Einträge aus allen anderen Domänenpartitionen innerhalb der Gesamtstruktur. Denn bekanntermaßen werden alle Objekte aus allen Domänen innerhalb einer Gesamtstruktur, lediglich mit den Attributen die für eine Suche relevant sind in den GC repliziert.

Um jede Zeile in der Datentabelle eindeutig identifizieren zu können, verwendet das AD als eindeutige Kennung das Distinguished Name Tag (DNT). Bei dem DNT handelt es sich um einen vier Byte (32Bit) Integer Wert und dieser wird zum internen Verweis auf Attribute und Objekte verwendet. Der Distinguished Name Tag ist eine lokale Kennung der nicht zwischen den DCs repliziert wird und lautet bei jedem DC anders.

Der DNT gibt die Zeile in der AD-Datenbank an, in der das Attribut bzw. Objekt gespeichert ist. Jedes Objekt das erstellt wird erhält im DNT eine fortlaufende Nummer. Oder wenn z.B. ein Benutzer einer Gruppe hinzugefügt wird, speichert das AD den DNT des Benutzerobjekts im member Attribut der Gruppe und nicht den Distinguished Name (DN). Dadurch das sich der DNT selbst beim Umbenennen eines Objekts nicht ändert kann ein Benutzerobjekt umbenannt werden, ohne dass das AD alle Gruppen durchsuchen muss um den DN des Benutzers in jedem member Attribut der Gruppe aktualisieren zu müssen.

Im AD hat jedes Objekt genau ein übergeordnetes Objekt und ein Verweis auf das übergeordnete Objekt ist mit dem Objekt selbst gespeichert. Für die Beziehung zwischen den über- und untergeordneten Objekten speichert das AD in einer zusätzlichen Spalte innerhalb der Datentabelle den Parent Distinguished Name Tag (PDNT). In dieser Spalte wird der DNT vom übergeordneten Objekt gespeichert. Die Auflösung der Beziehung zwischen den über- und untergeordneten Objekten ist optimiert, da der DNT und PDNT indizierte Felder in der AD-Datenbank sind.

Um sich das genauer vor Augen zu führen empfiehlt es sich einen Export der AD-Datenbank mit LDP zu generieren. Diese Möglichkeit, einen Export der AD-Datenbank und das sogar im laufenden Betrieb durchzuführen, existiert seit Windows 2000 und ist dank des speziellen Attributs dumpdatabase möglich, das nur für diesen Zweck existiert. Nach dem man LDP gestartet hat, muss man sich zunächst mit einem DC verbinden. Dazu wählt man in LDP unter dem Menüpunkt Remotedesktopverbindung die Option Verbinden… und gibt den gewünschten DC an, von dem aus ein Export der lokalen AD-Datenbankkopie durchgeführt werden soll. Danach muss man ebenfalls unter dem Menüpunkt Remotedesktopverbindung die Option Gebunden… wählen, um sich mit dem AD zu binden. Anschließend gilt es unter dem Menüpunkt Durchsuchen die Option Ändern aufzurufen. Nun muss im Feld Attribut das Attribut dumpdatabase eingetragen werden. Im Feld Werte können die gewünschten Attribute angegeben werden die mit exportiert werden sollen. Das Feld darf dabei nicht leer bleiben und es muss mindestens ein Attribut angegeben werden. Standardmäßig werden unter Windows Server 2008 R2 bereits diese Werte exportiert: DNT - PDNT - CNT - NCDNT - OBJ – DelTime - RecTime - INST - RDNTyp – RDN. Hat man die entsprechenden Attribute eingegeben, muss im Bereich Vorgang die Option Hinzufügen gewählt und mit einem Klick auf Eingabe die getätigten Einträge in die Eingabeliste übernommen werden. Mit einem Klick auf Ausführen wird der Export dann durchgeführt.

Je nach Anzahl der Attribute, Objekte und Größe der AD-Datenbank kann der Export einige Zeit in Anspruch nehmen. Daher ist es empfehlenswert, den Export auf einem DC zu einem Zeitpunkt zu generieren, wenn gerade keine größere Last auf dem DC besteht!

Die exportierte Datei mit dem Dateinamen NTDS.dmp kann mit einem Texteditor geöffnet werden (z.B. Notepad) und wird im gleichen Verzeichnis erstellt, in der sich auch die AD-Datenbank NTDS.dit befindet (standardmäßig %windir%\NTDS).

Was passiert denn nun in der AD-Datenbank wenn ein Objekt, z.B. ein Benutzer gelöscht wird?

Es heißt wenn ein Objekt, z.B. ein Benutzer gelöscht wird, wandert es in den versteckten Container Deleted Objects das sich in der Domänenpartition befindet.
Näheres zum Container Deleted Objects liefert der folgende Artikel:

Der Container Deleted Objects

Doch bevor das Objekt überhaupt gelöscht wird, findet anhand bestimmter Kriterien eine Überprüfung statt, ob das Objekt auch tatsächlich gelöscht werden darf.
Welche Kriterien das hauptsächlich sind, steht im diesem Artikel:

Active Directory Wiederherstellung

Wenn die Kriterien erfüllt und das Objekt gelöscht werden darf, werden folgende Änderungen am dem gelöschten Objekt vorgenommen:

Lingering Objects (veraltete Objekte) >

In Wirklichkeit wird in der AD-Datenbank das Objekt das gelöscht wurde, also z.B. ein Benutzer nicht verschoben. Stattdessen bleibt das Objekt nach dem Löschen weiterhin in der AD-Datenbank an seinem Platz bestehen! Lediglich die Beziehung zu dem übergeordneten Objekt, also der PDNT im gelöschten Objekt ändert sich. Das gelöschte Objekt erhält in der Spalte PDNT den DNT vom Container Deleted Objects.

Im Übrigen trifft das nicht nur auf das Löschen von Objekten zu. Auch wenn ein Objekt in eine andere OU verschoben wird, bleibt das Objekt weiterhin an seinem Ursprungsort in der AD-Datenbank bestehen. Das Einzige was sich auch hier ändert, ist die Beziehung zum übergeordneten Objekt, also der Wert in der Spalte PDNT.

Schauen wir uns das im folgenden Beispiel an:

Das Benutzerobjekt Yusuf Dikmenoglu enthält in der Spalte DNT den Wert 3702. Das Objekt befindet sich also in der Zeile 3702. In der Spalte PDNT ist als Wert 3697 eingetragen. Im PDNT ist der DNT vom übergeordneten Objekt gespeichert. Schaut man sich nun in der Spalte DNT die Zeile 3697 an wird schnell klar, das sich der Benutzer Yusuf Dikmenoglu in der OU „IT“ befindet.

Löscht man jetzt das Benutzerobjekt Yusuf Dikmenoglu, bleibt das Objekt weiterhin in der Zeile 3702 bestehen. Der Wert in der Spalte PDNT, sprich die Beziehung zum übergeordneten Objekt ändert sich jedoch! Das übergeordnete Objekt des gelöschten Benutzerobjekts Yusuf Dikmenoglu ist jetzt nicht mehr die OU „IT“, sondern der Container Deleted Objects in der Domänenpartition.

Wie zu erkennen ist wurde der Wert in der Spalte PDNT im gelöschten Benutzerobjekt Yusuf Dikmenoglu, von 3697 auf 1802 geändert.

Was an dieser Stelle auch zu erkennen ist, der Relative Distinguished Name (RDN) des gelöschten Benutzerobjekts hat einen eindeutigen Namen erhalten. Das gelöschte Objekt erhält intern den Namen <alterRDN>DEL:<objectGUID>. Durch das Hinzufügen der objectGUID ist sichergestellt, dass das Objekt auch im gelöschten Status einen einmaligen Namen innerhalb der AD-Datenbank besitzt und somit eindeutig zu identifizieren ist. Das ist auch notwendig, denn wenn es ein zweites Benutzerobjekt Yusuf Dikmenoglu geben würde das ebenfalls gelöscht wird, müssen beide Objekte im Container Deleted Objects identifiziert werden können. Diese Vorgehensweise ist insbesondere für das wiederherstellen des Tombstones oder aus dem AD-Papierkorb zwingend notwendig!

Weitere Informationen:
Die unterschiedliche Größe der AD-Datenbank
Domänencontroller vergleichen
Phantome im Active Directory

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Die PowerShell Cmdlets für Gruppenrichtlinien

Yusuf Dikmenoglu — Sun, 16 May 2010 10:07:59 GMT

Wer für die Administration von Gruppenrichtlinien in einem Windows Netzwerk zuständig ist, der sollte und wird die Gruppenrichtlinien-Verwaltungskonsole (auf Englisch: Group Policy Management Console, kurz GPMC) kennen. Installiert man sich unter Windows XP und Windows Server 2003 die GPMC das separat heruntergeladen werden muss, stehen einem 32 Skripte im Verzeichnis %PROGRAMFILES%\GPMC\Scripts zur Verfügung. Mit diesen GPMC-Skripts kann man viele alltägliche Gruppenrichtlinien-Aufgaben leicht und automatisiert durchführen. Viele Gruppenrichtlinien-Administratoren werden diese Skripte zu schätzen wissen.

Doch mit Vista und Windows Server 2008 stehen die GPMC-Skripte erst mal nicht zur Verfügung. Die GPMC steht zwar ab Vista nach der Installation der Remote Server Administration Tools (RSAT) und unter Windows Server 2008, erst nach Aktivierung der Gruppenrichtlinienverwaltung in den Features weiterhin zur Verfügung, doch die GPMC Skripte fehlen hingegen. Stattdessen stellt Microsoft die GPMC Skripte als separaten Download für Vista und Windows Server 2008 zur Verfügung. Nach der Installation stehen die GPMC Skripte in gewohnter Weise zur Verfügung.

GPMC Sample Scripts

Unter Windows 7 und Windows Server 2008 R2 steht die GPMC ohne die GPMC Skripte in den RSAT auch zur Verfügung. Es gibt jedoch keinen separaten Download der GPMC Skripte für Windows 7 und Windows Server 2008 R2. Aber die GPMC Skripte für Vista und Windows Server 2008 lassen sich auch unter Windows 7 und Windows Server 2008 R2 weiterhin nutzen. Wer allerdings für die Administration der Gruppenrichtlinien zukunftsorientiert sein möchte, der nutzt die PowerShell! Microsoft stellt 25 Cmdlets allein für Gruppenrichtlinien bereit, mit denen weitestgehend die gleichen Administrationsaufgaben durchgeführt werden können wie mit den GPMC Skripts. Die GPO Cmdlets die in der Zukunft erweitert werden, sind die Nachfolger der GPMC Skripts.

Damit die 25 GPO Cmdlets zur Verfügung stehen, müssen diese zuerst mit dem PowerShellbefehl Import-Module GroupPolicy geladen werden. Das Laden der GPO Cmdlets muss sowohl in der AD-PowerShell, als auch in der Windows PowerShell v2 durchgeführt werden. Man kann sich natürlich ein PowerShell-Profil erstellen, damit beim Starten der AD-/PowerShell die GPO Cmdlets beim Öffnen der PowerShell Konsole automatisch geladen werden. Nach dem Import kann man sich die folgenden 25 GPO Cmdlets mit Get-Command *-GP* anzeigen lassen. Startet man dagegen die Konsole Windows PowerShell Modules, wird beim Starten der Konsole unter anderem automatisch das GPO-Modul geladen.

Die 25 GPO Cmdlets sind:

Backup-GPO: Mit diesem Cmdlet sichert man das angegebene Gruppenrichtlinienobjekt (GPO) oder alle Gruppenrichtlinienobjekte in einer angegebenen Domäne in ein Sicherungsverzeichnis. Dabei muss das Sicherungsverzeichnis bereits existieren.

Copy-GPO: Dieses Cmdlet erstellt eine neue GPO und kopiert die Einstellungen aus der Quell-GPO in die neue GPO. Mit diesem Cmdlet kann eine GPO aus einer Domäne in eine andere Domäne innerhalb der gleichen Gesamtstruktur kopiert werden.

Get-GPInheritance: Informationen zur Gruppenrichtlinienvererbung für eine angegebene Domäne oder Organisationseinheit kann man sich mit diesem Cmdlet ausgeben lassen.

Get-GPO: Eine bestimmte GPO oder alle GPOs innerhalb einer Domäne kann man sich mit diesem Cmdlet anzeigen lassen.

Get-GPOReport: Hiermit wird ein Bericht im XML- oder HTML-Format generiert, in dem die Eigenschaften und Richtlinieneinstellungen für eine angegebene GPO oder für alle GPOs einer Domäne angezeigt werden. Dieses Cmdlet eignet sich ideal zu Dokumentationszwecken. Möchte man alle Richtlinieneinstellungen aller GPOs innerhalb der Domäne in eine HTML Datei exportieren, so gilt es diesen Befehl auszuführen: Get-GPOReport -All -Domain <Domäne.de> -ReportType HTML -Path C:\GPOReport\GPOReport.html. Das Zielverzeichnis muss bereits existieren, sonst erhält man eine Fehlermeldung.

Get-GPPermissions: Die Berechtigungen für einen oder mehrere Sicherheitsprinzipale kann man mit diesem Cmdlet in der angegebenen GPO abrufen.

Get-GPPrefRegistryValue: Dieses Cmdlet zeigt eine oder mehrere Registrierungseinstellungen die unterhalb der Computerkonfiguration oder der Benutzerkonfiguration in einer GPO getätigt wurden an.

Get-GPRegistryValue: Bei diesem Cmdlet werden eine oder mehrere registrierungsbasierte Richtlinieneinstellungen aus der Computerkonfiguration oder der Benutzerkonfiguration in einer GPO abgerufen.

Get-GPResultantSetOfPolicy: Mit diesem Cmdlet kann man die Richtlinienergebnissatz-Informationen für einen Benutzer, einen Computer oder für beide in eine Datei im HTML- oder XML-Format ausgeben lassen.

Get-GPStarterGPO: Ein bestimmtes oder alle Starter-GPOs werden mit diesem Cmdlet angezeigt.

Import-GPO: Dieses Cmdlet importiert die Einstellungen aus einer gesicherten GPO in die angegebene Ziel-GPO. Dabei kann sich das Ziel-GPO in einer anderen Domäne oder in einer anderen Gesamtstruktur befinden als die Sicherungs-GPO und muss vorher nicht existieren.

New-GPLink: Eine GPO wird auf eine Organisationseinheit (OU), einen AD-Standort oder auf die Domäne mit diesem Cmdlet verlinkt.

New-GPO: Eine neue GPO wird mit diesem Cmdlet erstellt.

New-GPStarterGPO: Mit diesem Cmdlet wird eine neue Starter-GPO erstellt.

Remove-GPLink: Dieses Cmdlet entfernt eine GPO-Verklinkung von einer OU, einem AD-Standort oder von der Domäne.

Remove-GPO: Eine GPO wird mit samt allen Verlinkungen, mit diesem Cmdlet gelöscht.

Remove-GPPrefRegistryValue: Eine oder mehrere Registrierungseinstellungen werden aus der Benutzerkonfiguration oder Computerkonfiguration innerhalb einer GPO mit diesem Cmdlet entfernt.

Remove-GPRegistryValue: Um eine oder mehrere Registrierungsbasierte Richtlinieneinstellungen aus der Benutzerkonfiguration oder Computerkonfiguration innerhalb einer GPO zu entfernen, muss dazu dieses Cmdlet verwendet werden.

Rename-GPO: Mit diesem Cmdlet kann man eine GPO umbenennen bzw. der GPO einen anderen Anzeigenamen zuweisen. Dabei bleibt die GUID der umbenannten GPO erhalten.

Restore-GPO: Dieses Cmdlet stellt eine GPO-Sicherung in der Domäne wieder her, in der sie ursprünglich gespeichert wurde. Ist die ursprüngliche Domäne oder die GPO nicht mehr in der Domäne vorhanden, tritt ein Fehler auf.

Set-GPInheritance: Die Vererbung einer GPO kann mit diesem Cmdlet deaktiviert werden. Oder die Deaktivierung der Vererbung für eine angegebene OU oder Domäne lässt sich ebenfalls mit diesem Cmdlet aufheben.

Set-GPLink: Die Eigenschaften einer GPO-Verknüpfung lassen sich mit diesem Cmdlet festlegen.

Set-GPPermissions: Die Berechtigungen einer GPO oder für alle GPOs innerhalb einer Domäne lassen sich mit diesem Cmdlet bearbeiten.

Set-GPPrefRegistryValue: Dieses Cmdlet konfiguriert eine Registrierungseinstellung unter der Benutzerkonfiguration oder der Computerkonfiguration in einer GPO.

Set-GPRegistryValue: Mit diesem Cmdlet konfiguriert man eine oder mehrere registrierungsbasierte Richtlinieneinstellungen unter der Benutzerkonfiguration oder der Computerkonfiguration in einer GPO. >>

Die Hilfe zu jedem einzelnen Cmdlet lässt sich mit Get-Help <Cmdlet> -Full anzeigen. Also z.B.: Get-Help Get-GPOReports -Full.

Auch an dieser Stelle zeigt sich: Die Zukunft spricht PowerShell! ;-)

Weitere Informationen:
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
AD-PowerShell Befehle

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Alle Benutzer einer OU aus einer bestimmten Gruppe entfernen

Yusuf Dikmenoglu — Sun, 09 May 2010 15:21:16 GMT

Befinden sich alle Benutzer die alle aus einer bestimmten Gruppe entfernt werden sollen in der gleichen OU,
so kann man alle Benutzer in einem Schritt mit dem folgenden AD-PowerShell Befehl aus der Gruppe entfernen:

$Benutzer = Get-ADUser -Filter * -Searchbase "OU=<Benutzer>,DC=Domäne,DC=de"
Remove-ADGroupMember -identity <Gruppe> -Member $Benutzer -Confirm:0

Befinden sich in der OU in der sich die Benutzer befinden auch Benutzer, die nicht Mitglied der entsprechenden Gruppe sind, schlägt der Befehl fehl.

Wenn sich alle Benutzer die Mitglied der Gruppe "Consultants" sind in der OU "IT" befinden, so lautet der Befehl wie folgt:

$Benutzer = Get-ADUser -Filter * -Searchbase "OU=IT,DC=Domäne,DC=de"
Remove-ADGroupMember -identity Consultants -Member $Benutzer -Confirm:0

Dabei spielt es weder eine Rolle um welchen Gruppenbereich es sich dabei handelt (Global, Lokal (in Domäne), Universal),
noch ob es sich um eine Sicherheits- oder Verteilergruppe handelt.

Weitere Informationen:
AD-PowerShell Befehle>>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Alte oder deaktivierte Computerkonten mit der AD-PowerShell löschen

Yusuf Dikmenoglu — Sun, 02 May 2010 13:29:23 GMT

Das Active Directory (AD) stets zu pflegen, ist eines der Aufgaben eines AD-Administrators. Mit der Zeit entstehen Leichen was die Computerkonten im AD betrifft. Clients die verschrottet wurden, sind vorher nicht aus der Domäne entfernt worden. Aber auch wenn Clients oder Mitgliedsserver aus der Domäne entfernt und zu einer Arbeitsgruppe (AG) hinzugefügt werden, wird nicht automatisch das Computerkonto im AD gelöscht. Es wird lediglich deaktiviert und bleibt im AD bestehen. Im Nachgang muss dann das Computerkonto manuell entfernt werden.

State oft the Art löscht man die Computerkonten mit der AD-PowerShell. Weitere Möglichkeiten findet man im folgenden Artikel:

Computerkonto löschen

# Alle deaktivierten Computerkonten, also alle Computer (Clients und Mitgliedsserver) die aus der Domäne entfernt und in eine AG hinzugefügt oder manuell deaktiviert wurden, werden mit diesem Befehl angezeigt:
Search-ADAccount -AccountDisabled -ComputersOnly | Sort-Object | FT Name -A

Sollen die deaktivierten Computerkonten aus einer bestimmten Organisationseinheit (OU) angezeigt werden, so gilt es diesen Befehl zu verwenden:
Search-ADAccount -AccountDisabled -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Sort-Object | FT Name -A

# Alle deaktivierten Computerkonten werden auf Nachfrage, nacheinander mit diesem Befehl gelöscht:
Search-ADAccount -AccountDisabled -ComputersOnly | Sort-Object| Remove-ADComputer

Deaktivierte Computerkonten aus einer bestimmten OU werden auf Nachfrage mit diesem Befehl entfernt:
Search-ADAccount -AccountDisabled -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Sort-Object| Remove-ADComputer

Sollen alle deaktivierten Computerkonten auf einmal ohne Nachfrage gelöscht werden, so muss der Parameter „-Confirm:“ mit dem Wert „$False“ mit angegeben werden. Sprich:
Search-ADAccount –AccountDisabled -ComputersOnly | Remove-ADComputer -Confirm:$False

Ohne Nachfrage werden die deaktivierten Computerkonten aus einer OU wie folgt gelöscht:
Search-ADAccount –AccountDisabled -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Remove-ADComputer -Confirm:$False

# Alle Computer die sich seit 180 Tagen nicht am AD angemeldet haben werden mit dem folgenden Befehl angezeigt. Damit der Parameter AccountInactive verwendet werden kann, muss sich jedoch der Domänenfunktionsmodus mindestens auf der Ebene “Windows Server 2003” befinden:
Search-ADAccount -AccountInactive –Timespan 180 –ComputersOnly | Sort-Object | FT Name -A

Möchte man sich alle Computer aus einer bestimmten OU anzeigen, die sich seit 180 Tagen nicht mehr am AD angemeldet haben, so sieht der Befehl folgendermaßen aus:
Search-ADAccount -AccountInactive –Timespan 180 -Searchbase “OU=<OU>,DC=Domäne,DC=de” –ComputersOnly | Sort-Object | FT Name -A

Gelöscht werden die Computerkonten dann wie folgt:
Search-ADAccount -AccountInactive –Timespan 180 -ComputersOnly | Remove-ADComputer -Confirm:$False

Aus einer bestimmten OU werden die Computerkonten so entfernt:
Search-ADAccount -AccountInactive –Timespan 180 -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Remove-ADComputer -Confirm:$False

# Alle Computer die seit dem 01.01.2010 inaktiv sind und sich nicht mehr am AD angemeldet haben, werden wie folgt angezeigt:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" –ComputersOnly | Sort-Object | FT Name -A

Alle Computer aus einer bestimmten OU, die sich seit dem 01.01.2010 nicht mehr am AD angemeldet haben, werden so angezeigt:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" -Searchbase “OU=<OU>,DC=Domäne,DC=de” –ComputersOnly | Sort-Object | FT Name -A

Alle Computerkonten die sich seit dem 01.01.2010 nicht mehr am AD angemeldet haben, lassen sich dann mit diesem Befehl löschen:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" –ComputersOnly | Remove-ADComputer -Confirm:$False

Die Computer einer bestimmten OU, die seit dem 01.01.2010 inaktiv sind, werden wie folgt gelöscht:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" -Searchbase “OU=<OU>,DC=Domäne,DC=de” –ComputersOnly | Remove-ADComputer -Confirm:$False

Weitere Informationen:
Das Erstellungsdatum eines AD-Objekts mit der AD-PowerShell abfragen
AD-PowerShell Befehle

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Zwei wichtige IDs eines DCs: DC GUID und InvocationId

Yusuf Dikmenoglu — Sun, 18 Apr 2010 12:18:07 GMT

Zwei wichtige IDs eines Domänencontrollers (DC) sind der DC GUID (Globaly Unique Identifier) und der Datenbank GUID. Beide IDs sind wichtige Bestandteile bei der AD-Replikation. Mit dem Kommandozeilenbefehl Repadmin /Showrepl <DC> kann man sich beide IDs anzeigen lassen. Gibt man den <DC> nicht an, wird der Befehl gegen den DC ausgeführt, auf dem man den Repadmin Befehl ausführt. Führt man den Befehl auf einem Windows Server 2003 DC aus, so erhält man diese Ausgabe auf dem ersten DC einer Gesamtstruktur:

Auf einem Windows Server 2008 R2 DC sieht das Ergebnis auf dem ersten DC wie folgt aus:

Jeder DC besitzt eine eindeutige DC GUID innerhalb einer Gesamtstruktur, der auch als Directory Service Agent GUID (kurz DSA-GUID) bekannt ist. Mit der DC GUID der im Attribut objectGUID gespeichert ist, wird der DC in der Gesamtstruktur identifiziert. Dabei spielt es auch keine Rolle in welcher Domäne sich der DC innerhalb einer Gesamtstruktur befindet. Der DC GUID eines DCs ist in der Gesamtstruktur einmalig und ändert sich solange der DC existiert (im Gegensatz zu der invocationId) niemals! Es sei denn, der DC wird zuerst herunter- und anschließend wieder zum DC heraufgestuft. Denn der DC GUID eines DCs wird beim heraufstufen eines Servers zu einem DC erstellt und beim herunterstufen eines DCs entfernt. Natürlich ist das manuelle bearbeiten des DC GUIDs ebenso nicht möglich, weil das Attribut objectGUID system-only ist. Das Attribut objectGUID findet man in den Eigenschaften des „NTDS Settings“ Objekts unterhalb des entsprechenden DC-Objekts in der Konfigurationspartition und ist als ein Oktett-String gespeichert. Der LDAP-Pfad zum “NTDS Settings” Objekt lautet: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne.

Die objectGUID wird unter anderem auch dazu verwendet, um die Reihenfolge der DCs einer ringförmigen Replikationstopologie zu bestimmen und ist außerdem bei der Wahl des Bridgeheadservers eines AD-Standorts von Bedeutung. Damit der DC für seine Replikationspartner erreichbar ist, erstellt dieser mit der objectGUID in der Forward Lookup Zone _msdcs.Root-Domäne im DNS einen CNAME Eintrag.

Beim heraufstufen eines Servers zu einem DC wird der AD-Datenbank (NTDS.dit) ebenfalls eine GUID zugeordnet, die als Datenbank GUID bezeichnet wird. Diese GUID wird dazu verwendet, um die AD-Datenbank eines DCs bei einem Replikationsaufruf zu identifizieren. Bei der Datenbank GUID handelt es sich um das Attribut invocationId und befindet sich so wie die objectGUID ebenfalls in der Konfigurationspartition, in den Eigenschaften des NTDS Settings Objekts eines DCs im LDAP-Pfad: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne. Auch die invocationId wird wie die objectGUID beim heraufstufen eines Servers zu einem DC erstellt und beim herunterstufen eines DCs entfernt. Replikationspartner nutzen die invocationId und die Update Sequence Number (USN) um die aktuellen Änderungen für die AD-Replikation zu bestimmen.

Die invocationId des ersten DCs mit dem die Gesamtstruktur erstellt wurde, hat den gleichen Wert wie die objectGUID. Bei allen weiteren DCs einer Gesamtstruktur werden unterschiedliche Werte in den beiden Attributen objectGUID und invocationId gespeichert.

Im Gegensatz zur objectGUID ändert sich die invocationId wenn:

eine neue Anwendungsverzeichnispartition erstellt wird. Oder wenn eine bestehende Anwendungsverzeichnispartition entfernt und erneut erstellt wird.
der DC mit einer gültigen Sicherung und einer unterstützten Rücksicherungsmethode (supportet von Microsoft!) rückgesichert wird. Eine gültige Sicherung ist eine Sicherung die mit einer Sicherungssoftware durchgeführt wurde, dass das entsprechende API des Betriebssystems verwendet und somit das AD in Kenntnis setzt, dass eine Sicherung durchgeführt wurde. Nur wenn eine gültige und somit eine supportete Sicherung mindestens vom System State durchgeführt wird, erspart man sich je nach Umgebung größeren Schaden im Fall einer Rücksicherung! Ab Windows Server 2003 SP1 kann man mit dem Kommandozeilenbefehl Repadmin /Showbackup überprüfen, ob eine Verzeichnispartition jemals supportet gesichert wurde.

Eine unterstützte Rücksicherung findet in Abstimmung mit der AD-Replikation statt. Denn nur wenn das AD durch eine ordnungsgemäß durchgeführte System State Sicherung und einer supporteten Rücksicherungsmethode rückgesichert wird, erhält die invocationId auf dem rückgesicherten DC einen neuen Wert. Dadurch erkennen alle anderen DCs, dass die Metadaten für die AD-Replikation zu dem rückgesicherten DC hinfällig sind und das die AD-Replikation ab dem durchgeführten Sicherungsdatum mit dem der DC rückgesichert wurde, neu aufgebaut und durchgeführt werden muss. Einige Sicherungsprogramme (bis Windows Server 2003 NTBACKUP und ab Windows Server 2008 Wbadmin, ARCServe…) führen eine ordnungsgemäße Sicherung und Rücksicherung des System States durch und darauf kommt es an!

Das entscheidende bei der Rücksicherung ist nun mal, dass die invocationId einen neuen Wert erhalten muss! Das ist genau der Nachteil bei Image-Programmen. Beim klassischen Imagen zieht man sich eine eins zu eins Kopie des DCs. Sollte es nun zum Rückspielen des Images kommen, erhält die invocationId keinen neuen Wert und somit erfahren je nach Umgebung die Replikationspartner auch nicht, dass ein DC rückgesichert wurde und das die Replikation mit dem rückgesicherten DC neu aufgebaut werden muss. Beim rücksichern eines Images schafft man sich ein USN Rollback, was je nach Fall zu einem größeren Schaden für die AD-Umgebung bedeutet! Im günstigsten Fall hätte man sich lediglich den zurück-geimageten DC zerstört. Diesen müsste man dann gewaltsam herunterstufen und anschließend die Metadaten des AD bereinigen (siehe weiterführende Informationen). Im ungünstigsten Fall hätte man mindestens doppelte RIDs verteilt, nicht mehr gültige Computerkontokennwörter und keine funktionierende AD-Replikation mit diesem DC mehr!

Wenn eine unterstützte Rücksicherung stattgefunden hat, wird der nicht mehr gültige Wert aus dem Attribut invocationId in das Attribut retiredReplDSASignatures (das sich ebenfalls im NTDS Settings Objekt eines DCs befindet) gesetzt.

Auch eine IFM (Install from Media) Installation eines DCs kommt einer Rücksicherung eines DCs gleich. Denn bei einer IFM-Installation wird der Wert aus dem Attribut invocationId das von der Sicherung stammt, in das Attribut retiredReplDSASignatures auf dem neuen DC geschrieben. Der Grund dafür ist, wenn ein Verbindungsobjekt für die Replikation erstellt wird, überprüft der neue DC sein Attribut retiredReplDSASignatures um festzustellen ob das Attribut einen Wert enthält, der mit den invocationIds im Up-To-Dateness Vector (UTDV) des Ziel-DCs übereinstimmt. Durch diese Vorgehensweise ist sichergestellt, dass nur eine Teilmenge der AD-Datenbank, nämlich nur die Änderungen die ab der Sicherung durchgeführt wurden repliziert wird.

Durch die ausschließlich ordnungsgemäß durchgeführte Sicherung und der Rücksicherungsmethode wird ein USN Rollback und somit Schaden verhindert! Wenn man sich nicht sicher ist ob das eingesetzte Sicherungsprogramm eine unterstützte Sicherung sowie Rücksicherung durchführt, sollte man ein klärendes Telefonat mit dem Hersteller führen. Von ungültigen Sicherungsmethoden wie das Rücksichern eines Images, VM-Images und VM-Snapshots (mindestens auf Servern die transaktionale Datenbanken bereitstellen wie ein DC, Exchange und SQL) sollte man stets Abstand halten und wird seitens Microsoft auch nicht supportet!

Auf einem DC ist es Pflicht mindestens das System State zu sichern und das kann man bereits mit Windows-Bordmittel (NTBACKUP, Wbadmin) durchführen!

Weiterführende Informationen:
Domänencontroller-Installation von einer Sicherung
Images als Sicherung?
Das Active Directory gewaltsam vom DC entfernen
Die Metadaten des Active Directory unter Windows Server 2008 bereinigen
Der RID-Master und sein RID-Pool
Lingering Objects (veraltete Objekte)
How to detect and recover from a USN rollback in Windows Server 2003
How To Convert a String Formatted GUID to a Hexadecimal String Form For Use When Querying the Active Directory

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Den gefilterten Attributsatz abfragen

Yusuf Dikmenoglu — Sun, 07 Mar 2010 22:32:34 GMT

Mit Windows Server 2008 führte Redmond den Read Only Domänencontroller (kurz RODC) ein. Der RODC der für Außenstellen die eine geringe bis keine physikalische Sicherheit den Servern bieten können konzipiert wurde, ist ein Domänencontroller (DC) der ausschließlich einen lesenden Zugriff auf die Active Directory-Domänendienste (AD DS) hat. Der RODC kann keine Änderungen in den AD DS und im AD-integrierten DNS vornehmen (RODNS). Clients oder Applikationen die einen Lesezugriff auf die AD DS benötigen erhalten Zugriff auf den RODC, während Clients oder Applikationen die einen Schreibvorgang in die AD DS durchführen wollen, diesen nicht auf dem RODC durchführen können sondern vom RODC an einen beschreibbaren DC verwiesen werden.

Der RODC besitzt ein vollständiges Replikat der AD-Datenbank, mit allen Attributen und Objekten die sich auch auf einem beschreibbaren DC befinden. Neben dem Unterschied das der RODC lediglich das Leserecht auf die AD-Datenbank hat, werden im Gegensatz zu einem beschreibbaren DC standardmäßig auch keine Benutzer- oder Computeranmeldeinformationen auf dem RODC gespeichert, außer das eigene Computerkonto sowie ein besonderes krbtgt-Konto für diesen RODC. Damit die Anmeldeinformationen der entsprechenden Benutzer-, Computer- und Dienstkonten auf dem RODC gespeichert werden können, muss das explizit in der Kennwortreplikationsrichtlinie (Password Replication Policy, kurz PRP) auf einem beschreibbaren DC gestattet werden, damit der RODC Authentifizierungs- und Dienstticketanforderungen eigenständig verarbeiten kann. Mit der Kennwortreplikationsrichtlinie wird bestimmt, ob die Anmeldeinformationen eines Benutzer- oder Computerkontos von einem beschreibbaren DC auf den RODC repliziert werden können.

Weitere Informationen zum RODC bekommt man in den folgenden beiden Artikeln:

Read-Only Domain Controller (RODC)
Die Installation eines RODC

Der gefilterte Attributsatz vom RODC

Diverse Applikationen könnten die AD-Domänendienste als Datenspeicher verwenden und sensible Daten darin speichern. Oder evtl. möchte man einfach nicht, dass bestimmte Daten von Benutzern (z.B. die Adressdaten oder die Personalnummer) auf einen RODC repliziert werden. Natürlich sollen diese kritischen Daten ebenfalls geschützt sein und nicht auf einem RODC gespeichert werden, falls der RODC kompromittiert, gestohlen oder die Sicherheit gefährdet wird. Und für genau diesen Anwendungstyp gibt es den gefilterten Attributsatz. Der gefilterte Attributsatz (auf Englisch: Filtered Attribute Set, kurz FAS) ist ein dynamischer Attributsatz, die nie auf einen RODC in der Gesamtstruktur repliziert werden da sie sensible oder vertrauliche Daten enthalten. Der gefilterte Attributsatz kann aber erst ab Windows Server 2008 konfiguriert werden.

Damit ein Attribut das wichtige Daten enthält nicht auf einen RODC repliziert wird, sollten die folgenden Schritte durchgeführt werden:

Das entsprechende Attribut sollte zu dem gefilterten Attributsatz (FAS) hinzugefügt werden. Damit wird verhindert, dass das Attribut an die RODCs in der Gesamtstruktur repliziert wird. Die Konfiguration des gefilterten Attributsatzes betrifft die Gesamtstruktur und kann nicht pro Domäne konfiguriert werden!
Des Weiteren sollte das Attribut als vertraulich gekennzeichnet werden. Dies ist eine weitere Sicherheitseinstellung das konfiguriert werden sollte, wenn man nicht möchte das ein sensibles Attribut zu einem RODC repliziert werden soll! Ein Attribut wird als vertraulich gekennzeichnet, in dem die Leseberechtigung für das entsprechende Attribut für die Gruppe Authentifizierte Benutzer entfernt wird. Somit können diese Attribute von den Mitgliedern der Gruppe Authentifizierte Benutzer (das betrifft alle Benutzer- sowie Computerkonten, inklusive RODCs) nicht mehr gelesen werden. Auch die Konfiguration eines vertraulichen Attributs betrifft die Gesamtstruktur und kann nicht pro Domäne konfiguriert werden! Doch bevor ein Attribut als vertraulich gekennzeichnet wird, sollte der Vorgang in einer Testumgebung ausgiebig getestet werden!
Der Gesamtstrukturfunktionsmodus sollte sich aus Sicherheitsgründen mindestens auf Windows Server 2008 befinden. Denn die Attribute die sich im gefilterten Attributsatz befinden, werden nur von DCs die mindestens unter Windows Server 2008 laufen berücksichtigt! Windows Server 2003 DCs ignorieren die Konfiguration das ein Attribut geschützt ist und replizieren die Attribute die sich in dem gefilterten Attributsatz befinden trotzdem auf einen RODC.
Die Domänenpartition in der sich der RODC befindet wird zwar erst ab einem beschreibbaren Windows Server 2008 DC auf den RODC repliziert, doch wenn auf dem RODC der globale Katalog (ROGC) aktiviert wird, baut sich eine eigene Replikationstopologie für die Replikation des GCs auf. Existieren in der Gesamtstruktur noch weitere Domänen mit Windows Server 2003 GCs in denen ebenfalls ein gefilterter Attributsatz konfiguriert wurde, ist es durchaus möglich das ein Windows Server 2003 GC den gefilterten Attributsatz aus seiner Domäne zu einem RODC repliziert.
Das Hinzufügen eines systemkritischen Attributs zum gefilterten Attributsatz ist nicht möglich! Ein systemkritisches Attribut ist ein Attribut, das z.B. für die ordnungsgemäße Funktion der AD DS oder für das Kerberos-Authentifizierungsprotokoll benötigt wird. Erst wenn in den Eigenschaften des entsprechenden Attributs im Attribut schemaFlagsEx, das aus einer Bitmaske besteht, das Flag FLAG_ATTR_IS_CRITICAL aktiviert ist, handelt es sich um ein systemkritisches Attribut. Dieses Flag existiert aber erst seit Windows Server 2008 und Windows Server 2003 DCs würden diese Einstellung ignorieren.
Daher ist es umso mehr wichtig, dass sich nicht nur der Schemamaster auf mindestens einem Windows Server 2008 DC, sondern der Gesamtstrukturfunktionsmodus sich zwingend im Modus Windows Server 2008 oder höher befindet. Denn wäre der Schemamaster ein Windows Server 2003 DC, würde sich ein systemkritisches Attribut dem gefilterten Attributsatz scheinbar erfolgreich hinzufügen lassen. Aber da ein Windows Server 2003 DC die Konfiguration eines gefilterten Attributsatzes sowieso nicht kennt, sollte in einer Gesamtstruktur in der ein gefilterter Attributsatz genutzt wird ein Windows Server 2003 DC ohnehin nicht mehr existieren!

Die technische Umsetzung wie ein Attribut zum gefilterten Attributsatz hinzugefügt wird, findet wie folgt statt

Um ein Attribut zum gefilterten Attributsatz hinzuzufügen und somit die Replikation des entsprechenden Attributs zu einem RODC zu verwehren, muss im zu schützenden Attribut das zehnte Bit (also Bit 9) im searchFlags Attribut gesetzt werden. Im searchFlags Attribut kann unter anderem bestimmt werden, dass ein Attribut zum gefilterten Attributsatz hinzugefügt wird und das es vertraulich ist. Im searchFlags Attribut das aus einer Bitmaske besteht, muss im zehnten Bit als Wert in Hexadezimal 0x200 und in Dezimal 512 eingetragen werden. Anschließend wird das entsprechende Attribut zu keinem RODC in der Gesamtstruktur repliziert.
Im Attribut searchFlags liegt auch das Geheimnis, warum ein Windows Server 2003 DC die Attribute im gefilterten Attributsatz nicht berücksichtigt. Denn das zehnte Bit, also Bit 9 in searchFlags ist erst mit Windows Server 2008 und der Einführung des RODCs hinzugekommen.
Soll ein Attribut zum gefilterten Attributsatz hinzugefügt werden, sollte es auch als vertraulich deklariert werden. Als vertraulich deklariert und somit die Leseberechtigung den Authentifizierten Benutzern entzogen, wird ein Attribut durch das Setzen des achten Bits (Bit 7) ebenfalls im searchFlags Attribut. Dieses Flag kam mit Windows Server 2003 SP1 hinzu. Daher sollte darauf geachtet werden, dass wenn mit diesem Flag Attribute als vertraulich definiert werden, alle DCs in der Gesamtstruktur mindestens unter Windows Server 2003 SP1 installiert sind. Alle älteren Serverversionen ignorieren die Kennzeichnung als vertraulich! Im achten Bit des searchFlags Attributs muss als Wert in Hexadezimal 0x080 und in Dezimal 128 eingetragen werden.
Demnach erhält also searchFlags als Wert 640 in Dezimal (in Hexadezimal 0x280), damit zum einen das gewünschte Attribut zum gefilterten Attributsatz hinzugefügt und zum anderen, als vertraulich definiert wird. Trägt man als Wert 641 ein, wird zugleich das Attribut indiziert. Sollten bereits andere Flags im searchFlags Attribut konfiguriert sein, müssen die Werte addiert werden!

Den gefilterten Attributsatz abfragen

Standardmäßig befinden sich die folgenden Attribute ab Windows Server 2008 im gefilterten Attributsatz:

ms-FVE-KeyPackage

ms-FVE-RecoveryPassword

ms-PKI-AccountCredentials
ms-PKI-DPAPIMasterKeys
ms-PKI-RoamingTimeStamp

ms-TPM-OwnerInformation

Um die Attribute die sich im gefilterten Attributsatz befinden abzufragen, muss eine Abfrage nach dem Attribut searchFlags mit dem Wert 512 (das zehnte Bit in searchFlags) durchgeführt werden.

Die Abfrage mit der AD-PowerShell könnte wie folgt lauten

Get-ADObject -LDAPFilter "(objectClass=attributeSchema)" -Searchbase "CN=Schema,CN=Configuration,DC=Root-Domäne" -Properties searchFlags | Where {$_.searchFlags -band 512} | Select Name,searchFlags | Sort Name | FT -Autosize -Wrap

Auch mit diesem AD-PowerShell Befehl lassen sich die gefilterten Attribute anzeigen:

Get-ADObject -LDAPFilter "(&(ObjectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=512))" -SearchBase “CN=Schema,CN=Configuration,DC=Root-Domäne” -SearchScope Subtree | Select Name | Sort Name | FT -Autosize -Wrap

Mit LDP lässt sich der gefilterte Attributsatz folgendermaßen anzeigen

Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN die Schemapartition und als Filter (searchFlags:1.2.840.113556.1.4.803:=512) angeben.

Weitere Informationen:
How to mark an attribute as confidential in Windows Server 2003 Service Pack 1
Anhang D: Schritte zum Hinzufügen eines Attributs zu einem Attributsatz mit RODC-Filter
Search-Flags Attribute
>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Hinweise zu ADPREP

Yusuf Dikmenoglu — Sun, 21 Feb 2010 13:21:44 GMT

Bevor der erste Server, der mit einem neueren Serverbetriebssystem installiert ist als die bereits bestehenden Domänencontroller (DCs) einer Gesamtstruktur, als DC zur Gesamtstruktur hinzugefügt werden kann, muss vorher zwingend mit dem Active Directory Preparation Tool (ADPREP) das Active Directory-Schema aktualisiert werden. Erst nachdem ADPREP ausgeführt wurde, kann der neue Server als DC zur Gesamtstruktur hinzugefügt werden. Dabei muss ADPREP stets von der CD/DVD ausgeführt werden, mit dem der neue Server installiert wurde. Möchte man also einen Windows Server 2008 oder Windows Server 2008 R2 in eine Windows 2000 bzw. Windows Server 2003 Gesamtstruktur hinzufügen, so muss das ADPREP von der Windows Server 2008 bzw. Windows Server 2008 R2 DVD ausgeführt werden.

ADPREP muss aber nur dann ausgeführt werden, wenn der Server mit dem neueren Serverbetriebssystem zum DC gestuft werden soll! Wird der neue Server lediglich als Mitgliedsserver zur Domäne hinzugefügt, so muss das ADPREP nicht ausgeführt werden.

Soll der Server, der mit einem neuerem OS (Operating System = Betriebssystem) installiert ist als die existierenden DCs, zu einer bestehenden Domäne als zusätzlicher DC hinzugefügt werden, muss zuerst ADPREP /FORESTPREP auf dem Schemamaster und anschließend ADPREP /DOMAINPREP /GPPREP auf dem Infrastrukturmaster in der Domäne ausgeführt werden, zu der der neue Server als DC hinzugefügt werden soll.

Wird jedoch mit dem neuen Server eine neue Subdomäne in einer bestehenden Gesamtstruktur erstellt, muss lediglich das ADPREP /FORESTPREP ausgeführt werden. Das ADPREP /DOMAINPREP /GPPREP muss und kann in diesem Szenario nicht ausgeführt werden, da es keine zu aktualisierende Domäne gibt. Schließlich wird mit dem neuen DC erst eine (weitere) Subdomäne erstellt.

Weitere Details beschreibt der folgende Artikel: >

Das Active Directory Preparation Tool - ADPREP

Fehler die beim Ausführen von ADPREP auftreten können

Wenn das Ausführen von ADPREP aus welchen Gründen auch immer fehl schlagen sollte, ist es empfehlenswert als erstes immer ins ADPREP-Protokoll zu schauen. Das ADPREP-Log wird im Verzeichnis %windir%\System32\Debug\Adprep\Logs erstellt und enthält einen detaillierten Bericht zur Domänen- und Gesamtstrukturvorbereitung.
Bevor der erste Server mit neuerem OS als die bereits existierenden DCs, als DC zur Gesamtstruktur hinzugefügt werden kann, muss zuerst das ADPREP /FORESTPREP in der Kommandozeile auf dem Schemamaster ausgeführt werden. Das Benutzerkonto mit dem dieser Befehl ausgeführt wird, muss Mitglied in den Gruppen Schema-Admins, Organisations-Admins und Domänen-Admins in der Domäne sein, in der sich der Schemamaster befindet.
Wenn ADPREP /FORESTPREP auf dem Schemamaster mit den notwendigen Rechten ausgeführt wurde und es trotzdem zu einem Fehler führt, weil ADPREP keinen Kontakt zum Schemamaster herstellen konnte (in seltenen Fällen), sollte der Schemamaster zuerst auf einen anderen DC und erneut zurück verschoben werden. Anschließend ist der Befehl ADPREP /FORESTPREP nochmals auszuführen.
Befindet sich das Benutzerkonto beim ausführen von ADPREP hingegen nicht in den entsprechenden Gruppen, kommt es zu diesem Fehler:

Adprep encountered a Win32 error.
Error code: 0x5 Error message: Access is denied

Das Benutzerkonto muss zum ausführen von ADPREP /FORESTPREP Mitglied in den folgenden Gruppen sein:

- Schema-Admins
- Organisations-Admins
- Domänen-Admin in der Domäne, in der sich der Schemamaster befindet.
Zum ausführen von ADPREP /DOMAINPREP /GPPREP muss das Benutzerkonto Mitglied in der Gruppe Domänen-Admins in der Domäne sein, in der dieser Befehl auf dem Infrastrukturmaster ausgeführt wird.
Kommt es beim ausführen von ADPREP /FORESTPREP zu diesem Fehler:

Es war Adprep nicht möglich, das Schema zu erweitern.

[Status/Folgen]

Der Schemamaster schloss einen Replikationszyklus nach dem letzten Neu-Start nicht ab. Der Schemamaster muss mindestens einen Replikationszyklus, bevor das Schema erweitert werden kann, abschließen.

[Benutzeraktion]

Überprüfen Sie, dass der Schemamaster mit dem Netzwerk verbunden ist, und mit anderen Domäne-Controllern kommunizieren kann…

liegt ein AD-Replikationsproblem vor. Es ist zwingend, dass zuerst das Replikationsproblem behoben wird, bevor das Ausführen von ADPREP erfolgreich durchgeführt werden kann. Einen ersten Ansatz zur Fehlersuche bei der AD-Replikation sollte neben dem Eventlog, auch das Schweizer Messer der AD-Replikation REPADMIN zum Vorschein bringen. Mit ausführen von Repadmin /Showreps bzw. Repadmin /Showrepl auf dem Schemamaster sieht man recht schnell, mit welchen DCs der Schemamaster nicht replizieren kann.

Wenn die DCs identifiziert wurden mit denen der Schemamaster nicht replizieren kann, sollte man versuchen sich per UNC auf die DCs zu verbinden. Bekommt man auf dem Schemamaster mit \\DC-Computername und \\FQDNdesDCs keine Verbindung zu den betroffenen DCs hin, liegt entweder ein Netzwerkproblem, ein DNS Problem, ein gebrochener sicherer Kanal (secure channel) oder ein Zeitunterschied von mindestens fünf Minuten zwischen den DCs vor. Gerade das DNS ist für eine AD-Umgebung von großer Bedeutung! Ein Ping sowohl auf die IP-Adresse als auch auf den Computernamen sollte von und zu den betroffenen DCs erfolgreich sein. Funktioniert ein Ping auf die IP-Adresse nicht, liegt höchstwahrscheinlich ein Netzwerkproblem vor. Es sollte der Weg vom Schemamaster zum betroffenen DC untersucht werden.

Funktioniert hingegen ein Ping auf den Computernamen oder FQDN des DCs nicht, liegt höchstwahrscheinlich ein DNS-Problem vor. In den TCP/IP-Einstellungen des DCs sollte ein zentraler DNS-Server als primärer DNS-Server eingetragen werden. Des Weiteren sollte in der Forward Lookup Zone überprüft werden, ob die SRV-Einträge existieren.
Mit Repadmin /KCC <DC> sollte anschließend die eingehende Replikationstopologie auf den DCs neu berechnet werden.
Auch durch Schemakonflikte kann ADPREP Fehler verursachen. Wurden benutzerdefinierte Schemaänderungen vorgenommen oder Schemaänderungen durch Drittanbieterlösungen durchgeführt die mit einer Schemaaktualisierung durch ADPREP in Konflikt stehen, kann es ebenfalls zu Fehlern kommen. Die Fehler die angezeigt werden können darauf hindeuten, dass der Object Identifier (OID) nicht geändert wurde und somit keine neuen Klassen dem AD-Schema hinzugefügt werden können. Das Konfliktobjekt wird im ADPREP-Protokoll protokolliert. Wenn das Objekt das den Konflikt verursacht hat durch eine Drittanbieterlösung ins AD-Schema hinzugefügt wurde, sollte man sich für eine Lösung des Problems an den Hersteller wenden. Andernfalls sollte man sich an den (kostenpflichtigen) Microsoft Produkt Support Service (MS PSS) wenden.
Ein weiterer Schemakonflikt könnte entstehen, wenn eine Verknüpfungskennung (Link Identifier) für ein Attribut durch eine Drittanbieterlösung bereits vergeben ist und ADPREP beim aktualisieren von bestehenden Attributen oder beim hinzufügen von neuen, dieselbe Verknüpfungskennung ebenfalls vergeben möchte. In diesem Fall sollte der MS PSS kontaktiert werden.
Wenn beim ausführen von ADPREP /FORESTPREP der Fehler Adprep konnte wegen eines Fehlers der Rückruffunktion nicht abgeschlossen werden erscheint, ist der Schuldige der Virenscanner. Der Echtzeitscanner (On-Access) agiert im Hintergrund als Systemdienst und scannt unsichtbar alle Dateien, Programme und den Arbeitsspeicher. Hat der Echtzeitscanner eine Datei oder ein Verzeichnis im Zugriff worauf ebenfalls beim ausführen von ADPREP /FORESTPREP der Zugriff auf dieselben Dateien oder Verzeichnisse benötigt wird, erscheint diese Fehlermeldung. Wenn dieser Fehler erscheint, muss der Virenscanner deaktiviert und anschließend erneut ADPREP /FORESTPREP ausgeführt werden. Danach kann der Virenscanner aktiviert werden.
Die Fehlermeldung Adprep konnte wegen eines Fehlers der Rückruffunktion nicht abgeschlossen werden kann auch erscheinen, wenn ADPREP /DOMAINPREP /GPPREP ausgeführt wurde. Dann muss der Virenscanner zuerst deaktiviert und anschließend ADPREP /DOMAINPREP /GPPREP erneut ausgeführt werden. Oder wenn im ADPREP-Protokoll der Fehler Error 0x80070020 (Error_sharing_Violation) protokolliert wird, liegt das ebenso am Virenscanner. Das Deaktivieren des Virenscanners sollte auch in diesem Fall zum Erfolg führen.

Führt das deaktivieren des Virenscanners nicht zum Ziel, könnte es noch an den folgenden Ursachen liegen:

1. Der Registry-Eintrag HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SYSVOL ist nicht vorhanden oder zeigt nicht auf das echte SYSVOL Verzeichnis %windir%\SYSVOL\sysvol. Wenn der Eintrag fehlt, muss ein REG_SZ Eintrag mit dem Pfad zum SYSVOL-Verzeichnis erstellt werden.

2. Die Default Domain Policy (die GUID ist {31B2F340-016D-11D2-945F-00C04FB984F9} ) und Default Domain Controllers Policy (die GUID ist {6AC1786C-016F-11D2-945F-00C04fB984F9} ) fehlen im SYSVOL Verzeichnis.

3. Im SYSVOL Verzeichnis fehlt das SCRIPTS Verzeichnis.
4. Der NTFS-Bereitstellungspunkt und/oder die Bereitstellungspunkte zwischen %windir%\SYSVOL\sysvol\domain und %windir%\SYSVOL existieren nicht (mehr). Sollten die Bereitstellungspunkte fehlen, so können diese mit dem Tool LINKD erneut gesetzt werden.

Die Befehle lauten:

LINKD %windir%\SYSVOL\SYSVOL\<DNS-Domänenname> %windir%\sysvol\domain
LINKD %windir%\SYSVOL\staging areas\<DNS-Domänenname> %windir%\SYSVOL\staging\domain
LINKD %windir%\SYSVOL\sysvol\<FQDN>
Wenn ADPREP /FORESTPREP ausgeführt wurde, müssen die Änderungen zuerst auf den Infrastrukturmaster in der Domäne repliziert werden, in der der neue Server als zusätzlicher DC hinzugefügt werden soll. Erst dann kann mit Domänen-Admin Rechten der Befehl ADPREP /DOMAINPREP /GPPREP auf dem Infrastrukturmaster ausgeführt werden. Wurden die Änderungen noch nicht auf den Infrastrukturmaster repliziert oder wenn ADPREP /FORESTPREP nicht ausgeführt wurde, meldet das ADPREP /DOMAINPREP /GPPREP einen Fehler der darauf hinweist, dass die Gesamtstrukturweiten Informationen zuerst aktualisiert werden müssen.
Der Domänenfunktionsmodus muss sich im einheitlichen Modus (Windows 2000 pur, Windows Server 2003 oder Windows Server 2008) befinden. Ansonsten schlägt das Ausführen von ADPREP /DOMAINPREP /GPPREP fehl!

Domänen- und Gesamtstrukturfunktionsmodus
Wenn ADPREP /RODCPREP mit Organisations- und Domänen-Admin Rechten auf einem Infrastrukturmaster ausgeführt wird, kann es zu folgendem Fehler kommen:

Adprep konnte kein Replikat für Partition DC=ForestDnsZones,DC=Root-Domäne erreichen.
ADPREP hat einen LDAP-Fehler festgestellt.
Fehlercode: 0x0. Erweiterter Server-Fehlercode: 0x0, Server-Fehlermeldung:(null).

und

Adprep konnte kein Replikat für Partition DC=DomainDnsZones,DC=Domäne,DC=de erreichen.
ADPREP hat einen LDAP-Fehler festgestellt.
Fehlercode: 0x0. Erweiterter Server-Fehlercode: 0x0, Server-Fehlermeldung:(null).
Dann muss der Infrastrukturmaster den entsprechenden DNS-Anwendungsverzeichnispartition idealerweise auf den aktuellen Infrastrukturmaster der Domäne verschoben werden. Wie das vonstattengeht, beschreibt der folgende Artikel:

Die Infrastrukturmaster der Anwendungsverzeichnispartitionen

Weitere Informationen:
Die FSMO-Rollen verschieben

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Den Security Descriptor vom Container "Deleted Objects" anzeigen

Yusuf Dikmenoglu — Sun, 17 Jan 2010 17:46:07 GMT

Den Security Descriptor (SD - die erweiterten Sicherheitseinstellungen) vom Container Deleted Objects, den es in der Domänen-, Konfigurations- sowie den beiden DNS-Anwendungsverzeichnispartitionen DomainDNSZones sowie ForestDNSZones gibt, kann man nicht so ohne weiteres abfragen bzw. auslesen.

Doch ab Windows Vista und Windows Server 2008 können mit LDP, das sich in den Remote Server Administration Tools (kurz RSAT) befindet, die Access Control Entries (ACEs) vom Deleted Objects Container angezeigt werden.

Nach dem man sich in LDP mit einem Domänencontroller verbunden und mit dem AD gebinded hat, trägt man unter Ansicht – Struktur entweder den Distinguished Name (DN) der Verzeichnispartition ein oder gibt direkt den LDAP-Pfad des Deleted Objects Container aus der gewünschten Verzeichnispartition an.

Anschließend ruft man mit einem Rechtsklick den Security Descriptor von Deleted Objects auf. Wie im Screenshot dargestellt muss man dazu auf Schwer – Sicherheitsbeschreibung klicken.

Im darauffolgenden Fenster muss bestätigt werden, dass man den SD von Deleted Objects aufrufen möchte.

Als Besitzer wird <null> angezeigt, was ein gewünschtes Verhalten ist. Denn bevor man sich die ACEs anzeigen lassen kann, muss man vorher die Besitzrechte von Deleted Objects übernehmen.

Gibt man im Feld „Besitzer“ z.B. nicht explizit den „Administrator“ (also den Domänen-Admin) an, wird als Besitzer die Gruppe „Domäne\Domänen-Admins“ für den Deleted Objects Container in der Domänenpartition eingetragen.

Nach der Besitzübernahme sieht man die eingetragenen ACEs. Es gibt lediglich zwei ACEs. Die Gruppe Builtin\Administratoren die das Leserecht besitzt und NT-AUTORITÄT\System, das den Vollzugriff besitzt.

Da in der Builtin\Administratoren Gruppe standardmäßig der Administrator und die beiden Gruppen „Domänen-Admins“ sowie „Organisations-Admins“ Mitglied sind, haben automatisch diese Konten das Leserecht auf den Container Deleted Objects. Selbstverständlich sollten nicht nur die bestehenden ACEs nicht verändert werden, sondern die gesamte Zugriffssteuerungsliste sollte nicht verändert und die Standardeinträge beibehalten werden.

Weitere Informationen:
Der Container Deleted Objects
Der Active Directory-Papierkorb im Windows Server 2008 R2
>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Massenimporte- und -exporte mit CSVDE und der AD-PowerShell durchführen

Yusuf Dikmenoglu — Sun, 10 Jan 2010 13:35:20 GMT

Neben dem CSVDE das seit Windows 2000 „on Bord“ existiert, kann mit der AD-PowerShell und einer Comma-Separated Value (CSV)-Datei ebenfalls ein Massenimport- sowie -export von Objekten durchgeführt werden. CSVDE steht bis einschließlich Windows Server 2003 nur auf einem Serverbetriebssystem zur Verfügung. Erst ab Windows Vista steht das CSVDE in den Remote Server Administration Tools (kurz RSAT) auf dem Client zur Verfügung. Doch auch unter Windows 2000 und Windows XP ist es möglich die Csvde.exe von einem Server aus dem Verzeichnis „%windir%\system32“ auf eine Admin-Workstation zu kopieren, um das Kommandozeilentool unter diesen beiden Clientversionen zu verwenden. Denn CSVDE steht weder im Adminpak, noch in den Windows Support Tools zur Verfügung.

Die AD-PowerShell steht ab Windows Server 2008 R2 sowie Windows 7 in den RSAT (Remote Server Administration Tools) zur Verfügung und kann ab Windows Server 2003 und Windows XP nachinstalliert werden.

Siehe:
Windows Management Framework (Windows PowerShell 2.0, WinRM 2.0, and BITS 4.0)

Mit der AD-PowerShell lässt sich ebenfalls eine CSV-Datei mit den Cmdlets Import-CSV sowie New-ADUser (für den Import von Benutzern) ins AD importieren und mit dem Cmdlet Export-CSV, Daten aus dem AD exportieren.

Der Vorteil eines Massenimports mit einer CSV-Datei ist, dass man sich die Datei mit den zu importierenden Objekten und Daten in Excel übersichtlich erstellen und als CSV-Datei speichern kann. Nach anschließender Überarbeitung der CSV-Datei kann dann der Import ins AD stattfinden. Auch der Export von vielen Objekten in eine CSV-Datei hat seine Vorteile. Die exportierte CSV-Datei lässt sich zur weiteren Bearbeitung in Excel importieren.

CSVDE und die AD-PowerShell können mit der Dateiendung CSV und TXT einen Im- sowie Export durchführen.

CSVDE zum Im- und Export verwenden

Mit CSVDE, das im Übrigen für Comma Separated Value Data Exchange steht, können Daten im kommaseparierten Format importiert sowie exportiert werden. CSVDE liest beim Import die Informationen aus einer Datendatei und erstellt anschließend AD-Objekte entsprechend den Anweisungen in der Datendatei. Es können jedoch keine bestehenden Objekte geändert werden. Nur das Hinzufügen von neuen Objekten ist möglich! Mit CSVDE können auch keine Benutzerkennwörter gesetzt werden.

Ist neben dem Im- oder Export das Ändern von bestehenden Objekten gewünscht, kann das neben der AD-PowerShell mit LDIFDE durchgeführt werden, das sich auch seit Windows 2000 standardmäßig auf einem Server befindet. LDIFDE kann zwar ebenfalls beim Import von neuen Benutzerobjekten keine Kennwörter setzen, doch dafür kann es Kennwörter von bestehenden Benutzerobjekten ändern, wenn vorher eine 128Bit SSL-Verbindung zum DC hergestellt wurde.>

LDIFDE - LDAP Data Interchange Format Data Exchange

CSVDE kann beliebige Objekte, wie beispielsweise Organisationseinheiten (OU), Benutzer-, Gruppen- und Computerkonten ins AD importieren. Damit CSVDE seine Arbeit korrekt verrichtet, müssen alle notwendigen Parameter angegeben werden.

Die Parameter die für den Im- sowie Export gelten:

-c Dieser Parameter ersetzt bestimmte Daten der Datendatei. Hat man z.B. eine Datendatei zur Hand in der der Distinguished Name der Objekte angepasst werden muss, so hat man zwei Möglichkeiten: Entweder man nutzt im Editor (Notepad) die „Ersetzen…“ Funktion oder man verwendet diesen Parameter, ohne die Datei bearbeiten zu müssen. Die Eingabe würde so aussehen: „-c <DC=alte,DC=Domäne> <DC=neue,DC=Domäne>“.
-f Mit diesem Parameter wird die Datei für den Im- bzw. Export angegeben.
-j Wenn ein Im- oder Export aus welchen Gründen auch immer nicht funktioniert, sollte man diesen Parameter angeben, gefolgt von einem Pfad (z.B. „-j C:\“). Im Fehlerfall werden zwei Protokolldateien erstellt „csv.log“ und „csv.err“. Bei Erfolg wird lediglich die „csv.log“ erstellt.
-s Mit diesem Parameter kann man gezielt einen DC angeben, der für den Im- oder Export verwendet werden soll.
-v Bei der Angabe dieses Parameters wird der ausführliche Modus aktiviert. Es werden in der CMD mehr Informationen angezeigt.
-t Dieser Parameter gibt den LDAP-Port an. Standardmäßig wird der LDAP-Port 389 verwendet. Möchte man aber Daten z.B. von einem globalen Katalog exportieren, so muss der Port 3268 angegeben werden.
-u Umlaute in den zu exportierenden Daten werden mit diesem Parameter korrekt dargestellt. Dieser Parameter verwendet das Unicodeformat.
csvde -? In gewohnter Windows Manier zeigt dieser Befehl die Hilfe zu CSVDE an.

Die relevanten Parameter für einen Import sind:

-f Mit diesem Parameter wird die Datei für den Import angegeben.
-i Dieser Parameter aktiviert den Importmodus. Standardmäßig wird CSVDE ohne Angabe dieses Parameters im Export-Modus ausgeführt.
-k Damit die Fehler „Beschränkungsverletzung“ und „Objekt ist bereits vorhanden“ beim Import ignoriert werden, gilt es diesen Parameter anzugeben.

Die relevanten Parameter für einen Export sind:

-d Dieser Parameter gibt den DN für den zu exportierenden LDAP-Pfad an.
-f Mit diesem Parameter wird die Datei für den Export angegeben.
-g Deaktiviert die seitenweise Suche.
-l Die zu exportierenden Attribute werden mit diesem Parameter angeben (durch Komma getrennt). Dieser Parameter sollte nicht zusammen mit dem Parameter -i verwendet werden, da beide Parameter für andere Szenarien gedacht sind.
-m Aktiviert die SAM-Logik beim Export. Mit diesem Parameter werden die Systemattribute wie z.B. ObjectGUID, objectSID und pwdLastSet nicht exportiert. Daher ist es sinnvoll stets diesen Parameter beim Export zu verwenden. Denn wenn die gleiche Datendatei zum Import verwendet werden soll, müssen ohnehin die Systemattribute aus der Datendatei entfernt werden, da ansonsten der Import fehlschlägt.
-n Exportiert keine Binärwerte.
-o Die Liste der Attribute (durch Komma getrennt), die beim Export ausgelassen werden sollen, werden mit diesem Parameter angegeben.
-p Den Suchbereich (Base/OneLevel/SubTree) gibt man mit diesem Parameter an.
-r Mit diesem Parameter gibt man den LDAP-Suchfilter an. Wird der Parameter nicht angegeben, nimmt CSVDE standardmäßig diesen Suchfilter "(objectClass=*)".

Einen Import mit CSVDE durchführen

Für den Import wird zuerst eine Dateidatei mit den zu importierenden Attributen sowie gewünschten Werten benötigt. Diese Datei lässt sich einfach und übersichtlich in Excel erstellen.>

Für den erfolgreichen Import muss die Datendatei folgenden Bedingungen entsprechen:

In der ersten Zeile der Exceldatei müssen die zu importierenden AD-Attribute angegeben werden. Welche Attribute hinter den Feldnamen stecken, erfährt man in diesem Artikel:

Die Active Directory-Attribute hinter den Feldnamen
Zwingende- und Mindestangaben für den Import von Benutzern und Gruppen sind: DN, objectClass und sAMAccountName. Für den Import von Organisationseinheiten (OUs) sind es die beiden Attribute DN und objectClass.
Die Reihenfolge in der die Attribute in der ersten Zeile angegeben werden, spielt keine Rolle.
Die Reihenfolge der Werte bzw. Feldinhalte ab der zweiten Zeile in der Datendatei, müssen allerdings mit der ersten übereinstimmen.
Sollen neben Benutzern auch Gruppen importiert werden, in denen die zu importierenden Benutzer Mitglied sein sollen, so müssen die Benutzereinträge vor den Gruppeneinträgen in der Datendatei enthalten sein. Oder wenn auch die OU importiert werden soll, in der die Benutzer und Gruppen erstellt werden sollen, so muss der Eintrag zum erstellen der OU ebenfalls vor den Benutzer- und Gruppenobjekten zuerst in der Datendatei enthalten sein. Beide Fälle sind in diesem Beispiel aufgeführt.
Wird ein Wert für ein angegebenes Attribut nicht eingetragen, muss es dennoch in der Datendatei durch ein Komma angegeben werden.
Systemattribute wie z.B. die ObjectSID oder ObjectGUID können nicht importiert werden. Wie es der Name „Systemattribute“ schon verrät, sind das Attribute die vom System vergeben werden.
Die Exceldatei könnte z.B. so aussehen:
Ist die Exceldatei fertiggestellt, muss diese als CSV-Datei abgespeichert werden. Dazu klickt man in Excel in der Menüleiste auf das Diskettensymbol oder verwendet das Tastaturkürzel „STRG + S“. Das Fenster „Speichern unter“ öffnet sich. Als Dateityp wählt man die Option „CSV (Trennzeichen-getrennt)(*.csv)“ aus und vergibt einen Dateinamen. Mit einem Klick auf Speichern folgt eine Warnung die darauf hinweist, dass der gewählte Dateityp keine Arbeitsmappen mit mehreren Blättern unterstützt und deshalb nur das aktuelle Blatt gespeichert wird. Mit einem Klick auf OK erscheint eine weitere Information die darauf hinweist, dass in der CSV-Datei Merkmale enthalten sein können, die mit „CSV (Trennzeichen-getrennt)“ nicht kompatibel sind. Mit einem Klick auf „Ja“ wird nun endlich die CSV-Datei gespeichert.
Nun muss die CSV-Datei mit dem „Editor“ (Notepad) noch bearbeitet werden. Mit einem Rechtsklick auf die CSV-Datei wählt man à Öffnen mit à Editor. Danach öffnet sich die CSV-Datei im Editor.
Als Trennzeichen verwendet Excel das Semikolon (;), das durch das Komma (,) ersetzt werden muss. Dies kann man am einfachsten, wenn man im Editor auf Bearbeiten – Ersetzen… klickt. Dort gibt man dann im Feld „Suchen nach“ das Semikolon an und im Feld „Ersetzen durch“ das Komma. Anschließend werden mit einem Klick auf „Alle ersetzen“ die Änderungen durchgeführt.
Werte die selbst ein Komma enthalten, müssen in Anführungszeichen (im Volksmund auch als „Gänsefüßchen“ bekannt) gesetzt werden. Das kann man ebenfalls durch die Ersetzen-Funktion im Editor durchführen. In diesem Beispiel müssen die Werte von DN, displayName und Member in Anführungszeichen gesetzt werden.

Vorsicht: Importiert man so wie in diesem Beispiel auch eine Gruppe in der ebenfalls die zu importierenden Benutzer Mitglied sein sollen, müssen die DNs der Benutzer zwingend durch eine Semikolon getrennt werden. Des Weiteren darf das Anführungszeichen nur am Anfang und am Ende der Einträge stehen. Also: „<DN Benutzer1>;<DN Benutzer2>;<DN Benutzer3>“.
Die fertige Datendatei sieht dann wie folgt aus:
Die gelben Markierungen in dem Beispiel kennzeichnen die Werte die Kommas enthalten und somit in Anführungszeichen gesetzt werden müssen und die roten Markierungen kennzeichnen die nicht enthaltenen Werte, die trotzdem durch ein Komma gesetzt werden müssen.
Zur Vollständigkeit, hier der komplette Inhalt der Datendatei:

DN,objectClass,givenname,sn,displayname,description,sAMAccountName,userPrincipalName,Member,groupType,userAccountControl
"OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",organizationalUnit,,,,,,,,,
"CN=Sabine Mueller,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Sabine,Mueller,"Mueller, Sabine",Festangestellte,sabine,sabine@ad2008r2.dikmenoglu.de,,,544
"CN=Klara Tolle,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Klara,Tolle,"Tolle, Klara",,Klara,Klara@ad2008r2.dikmenoglu.de,,,544
"CN=Simone Wagner,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Simone,Wagner,"Wagner, Simone",Aushilfe,Simone,Simone@ad2008r2.dikmenoglu.de,,,544
"CN=Maria Schmitt,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Maria,Schmitt,"Schmitt, Maria",,Maria,Maria@ad2008r2.dikmenoglu.de,,,544
"CN=Bettina Bauer,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Bettina,Bauer,"Bauer, Bettina",Befristet,Bettina,Bettina@ad2008r2.dikmenoglu.de,,,544
"CN=Andrea Schmidt,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Andrea,Schmitt,"Schmitt, Andrea",,Andrea,Andrea@ad2008r2.dikmenoglu.de,,,544
"CN=Sonja Neu,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Sonja,Neu,"Neu, Sonja",Praktikant,Sonja,Sonja@ad2008r2.dikmenoglu.de,,,544
"CN=Silke Vogt,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Silke,Vogt,"Vogt, Silke",Festangestellte,Silke,Silke@ad2008r2.dikmenoglu.de,,,544
"CN=AD-Consultants,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",group,,,,,AD-Consultants,,"CN=Sabine Mueller,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de;CN=Silke Vogt,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",-2147483644,
Die Datendatei kann dann mit diesem Befehl importiert werden:
Csvde -i -f C:\Datendatei.txt
Wenn beim Import ein Fehler auftritt, sollte man den Parameter -j verwenden damit die beiden Protokolldateien erstellt werden, um dann dem Fehler auf die Schliche zu kommen. Der Befehl würde dann so aussehen:
Csvde -i –v -f C:\Datendatei.txt –j C:\

Mit dem Attribut userAccountControl den Kennwortstatus der zu importierenden Benutzer steuern

Gibt man beim Import von Benutzern das Attribut userAccountControl in der Datendatei nicht oder mit dem Wert 514 an, erhält man anschließend deaktivierte Benutzer im AD. Denn wie bereits anfangs in diesem Artikel erwähnt, kann CSVDE keine Kennwörter setzen, was zwingend notwendig ist um hinterher aktive Benutzer zu erhalten. Der Wert 512 im userAccountControl würde zwar aktive Benutzer erstellen, jedoch reicht dass alleine nicht aus, da auch hierbei kein Kennwort vergeben wird. Das Deaktivieren der Kennwortrichtlinie würde zwar den gewünschten Erfolg bringen, nämlich nach dem Import aktivierte Benutzer im AD zu erhalten, jedoch ist das in einer produktiven Umgebung keineswegs empfohlen! Das ist höchstens für eine Testumgebung zulässig!

Aber das Abschalten der Kennwortrichtlinie ist auch nicht notwendig. Bekanntlich besteht das userAccountControl aus einer Bitmaske, bestehend aus mehreren Flags. Kombiniert man zwei davon, erhält man nach dem Import aktivierte Benutzer ohne ein Kennwort vergeben zu haben!

Kombiniert man die beiden Flags:

NORMAL_ACCOUNT	512
PASSWD_NOTREQD	32

und trägt in der Datendatei als Wert für userAccountControl 544 ein (wie im o.g. Beispiel), erhält man aktive Benutzerkonten im AD!

Die Benutzer melden sich ohne ein Kennwort an und werden direkt aufgefordert ein neues Kennwort zu vergeben. Denn das userAccountControl mit dem Wert 544 in den Benutzerobjekten aktiviert die Kontooption „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“.

How to use the UserAccountControl flags to manipulate user account properties >

Gruppen mit CSVDE importieren

Die Werte die in der Datendatei für einen Import von Gruppen zwingend angegeben werden müssen sind: DN,objectClass und sAMAccountName. Somit werden aber lediglich „globale Sicherheitsgruppen“ erstellt. Daher ist es ratsam noch das Attribut groupType anzugeben, um den „Gruppenbereich“ und „Gruppentyp“ zu bestimmen.

Der Import der Datendatei erfolgt mit diesem Befehl:
Csvde -i -f C:\Gruppen.txt

Beispiele einer Datendatei zum Import von Gruppen

# Eine domänenlokale Sicherheitsgruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=DLSG,OU=<OU>,DC=Domäne,DC=de",group,DLSG,-2147483644

# Eine globale Sicherheitsgruppe importieren:
DN,objectClass,sAMAccountName
„CN=GG1,OU=<OU>,DC=Domäne,DC=de“,group,GG1

Oder:
DN,objectClass,sAMAccountName,groupType
„CN=GG1,OU=<OU>,DC=Domäne,DC=de“,group,GG1,-2147483646

# Eine universelle Sicherheitsgruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=USG,OU=<OU>,DC= Domäne,DC=de ",group,USG,-2147483640

# Eine domänenlokale Verteilergruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=DLVG,OU=<OU>,DC= Domäne,DC=de ",group,DLVG,4

# Eine globale Verteilergruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=GVG,OU=<OU>,DC= Domäne,DC=de ",group,GVG,2

# Eine universelle Verteilergruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=UVG,OU=<OU>,DC= Domäne,DC=de ",group,UVG,8 >

Einen Export mit CSVDE durchführen

CSVDE wird standardmäßig ohne die Angabe eines Parameters im Export-Modus ausgeführt. Die Kunst beim Export ist es, lediglich die Informationen zu exportieren die von Interesse sind. Daher ist das entscheidende beim Export der Filter, der mit dem Parameter -r eingeleitet wird und die Attribute, die mit dem Parameter –l angegeben werden.

Beispiel Exportbefehle:

# Alle Benutzer mit den Attributen sAMAccountName und name exportieren:
Csvde -m -n -u -f C:\AlleBenutzer.txt -r "(&(objectclass=user)(objectcategory=person))" -l sAMAccountName,name

# Alle Benutzer aus einer OU mit den Attributen sAMAccountName und name exportieren:
Csvde -m -n -u -f C:\ExportBenutzer.txt -s DCON01 -d "OU=<OU>,DC=Domäne,DC=TLD" –p OneLevel –r "(&(objectClass=user)(objectcategory=person))" -l sAMAccountName,name

# Alle Kontakte mit den angegebenen Attributen exportieren:
Csvde -m -n -u -r "(objectClass=Contact)" -d "OU=<OU>,DC=Domäne,DC=de" -l displayname,telephoneNumber,othertelephone,mobile,homePhone,Pager,facsimileTelephoneNumber,ipPhone,otherHomePhone,otherPager,otherMobile,otherFacsimileTelephoneNumber,otherIpPhone -f C:\Kontakte.txt

# Mitglieder einer bestimmten Gruppe exportieren:
Csvde -m -n -u -f C:\Benutzer.txt -r "(&(objectcategory=user)(memberof=CN=<Gruppe>,OU=<OU>,DC=Domäne,DC=de))" -l samaccountname,name

# Alle Benutzer anzeigen, die NICHT Mitglied einer bestimmten Gruppe sind:
Csvde –m –n –u –f C:\Benutzer.txt -r „(&(objectCategory=person)(objectClass=user)(!memberof=CN=<Gruppe>,OU=<OU>,DC=Domäne,DC=de))“ –l name,sAMAccountName

# Alle Benutzer mit ihrem DN und dem LastLogon exportieren:
Csvde -m -n -u -f C:\Benutzer.txt -r "(&(objectClass=user)(objectCategory=person))" -l DN,LastLogon

Der Wert von LastLogon kann dann folgendermaßen in unsere Zeitangabe umgerechnet werden:

Einen Large Integer Wert umrechnen

# Alle Benutzer mit ihrem Anmeldenamen und dem eingetragenen Anmeldeskript exportieren:
Csvde -f C:\BenutzermitAnmeldeskript.txt -r "(&(objectClass=user)(scriptPath=*))" -l sAMAccountName,scriptPath

# Alle Benutzerobjekte exportieren, die NICHT deaktiviert sind (also aktive Benutzer):
Csvde -m -n -u -f C:\AktiveBenutzer.txt -r "(&(objectClass=user)(objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))" –l sAMAccountName,name

# Alle Benutzer exportieren und überprüfen, bei wem die Option „Zugriff gestatten“ im Reiter „Einwählen“ aktiviert ist. Steht als Wert TRUE, ist die Option aktiviert:
Csvde -f C:\Ras.txt -u -r "(&(objectClass=user)(objectCategory=person))" -l name,sAMAccountName,msNPAllowDialin

# Alle deaktivierten Computerkonten exportieren:
Csvde –f C:\DeaktiviertePCs.txt –r „(&(objectclass=computer)(userAccountControl:1.2.840.113556.1.4.803:=2))“ –l DN

# Alle Public Folder exportieren:
Csvde -m -n -u -f C:\PublicFolders.txt -r "(objectClass=publicFolder)" -l name

# Alle SMTP-Adressen exportieren:
Csvde -m -n -u -f C:\SMTPList.txt -d "DC=Domäne,DC=de" -L proxyaddresses –r "(proxyaddresses=*smtp:*@*)"

Weitere Filter können aus diesem Artikel entnommen werden:

Gespeicherte Abfragen

Eine Datendatei mit Excel, zum Import mit der AD-PowerShell erstellen

Auch mit der AD-PowerShell können beliebige Objekte, wie beispielsweise Organisationseinheiten (OU), Benutzer-, Gruppen- und Computerkonten ins AD importiert werden. Für den erfolgreichen Import mit der AD-PowerShell wird zum einen eine Datendatei mit den korrekten Angaben benötigt und zum zweiten, der AD-PowerShell Befehl mit dem der Import durchgeführt wird.

Für das Erstellen einer Datendatei um Benutzerobjekte in Verbindung mit der AD-PowerShell zu importieren, gilt es folgendes zu beachten: >

In der ersten Zeile müssen die Felder stehen, für die man einen Wert eintragen möchte. Möchte man Benutzer importieren, ist es hilfreich sich in der AD-PowerShell mit dem Befehl Get-Help New-ADUser -detailed die Syntax des Cmdlets anzuschauen. Dort werden die genauen Feldbezeichnungen genannt, wie es die AD-PowerShell in der Datendatei gerne hätte. Die Angaben unterscheiden sich teilweise von den unter CSVDE, da die AD-PowerShell nicht den LDAP-Display-Name eines Attributs verwendet (anstatt „sn“ für Nachname möchte die AD-PowerShell die Angabe „surname“)
Zwingend notwendige und die Mindestangaben für den Import von Benutzerobjekten sind: Path, Name und sAMAccountName. Für Gruppenobjekte sind es die Werte: Path, GroupScope, Name und sAMAccountName.
Im Gegensatz zu CSVDE darf es nicht DN (für Distinguished Name) heißen, sondern muss Path lauten. Dabei darf auch nicht das eigentliche Objekt (sprich der RDN) mit angegeben werden. Des Weiteren ist auch die Angabe von objectClass (oder userAccountControl) nicht notwendig, da durch das Cmdlet New-ADUser die Information bereits mitgegeben wird.
In welcher Reihenfolge die Felder in der ersten Zeile angegeben werden, spielt keine Rolle. Die Reihenfolge der Werte bzw. Feldinhalte ab der zweiten Zeile müssen jedoch mit der ersten übereinstimmen.
Wird ein Wert für ein angegebenes Feld nicht eingetragen, muss es dennoch in der Datendatei durch ein Komma angegeben werden.
Systemattribute wie z.B. die ObjectSID oder ObjectGUID können nicht importiert werden. Wie es der Name „Systemattribute“ schon verrät, sind das Attribute die vom System vergeben werden.
Beispielsweise könnte die Excel-Datei wie folgt aussehen:
Ist die Exceldatei fertiggestellt, gilt es diese als CSV-Datei abzuspeichern. Dazu klickt man in Excel in der Menüleiste auf das Diskettensymbol oder verwendet das Tastaturkürzel „STRG + S“. Das Fenster „Speichern unter“ öffnet sich. Als Dateityp wählt man die Option „CSV (Trennzeichen-getrennt)(*.csv)“ aus und vergibt einen Dateinamen. Es folgt eine Warnung die darauf hinweist, dass der gewählte Dateityp keine Arbeitsmappen mit mehreren Blättern unterstützt und deshalb nur das aktuelle Blatt gespeichert wird. Mit einem Klick auf OK erscheint eine weitere Information die darauf hinweist, dass in der CSV-Datei Merkmale enthalten sein können, die mit „CSV (Trennzeichen-getrennt)“ nicht kompatibel sind. Mit einem Klick auf „Ja“ wird nun endlich die CSV-Datei gespeichert.
Nun muss die CSV-Datei mit dem „Editor“ (Notepad) noch bearbeitet werden. Mit einem Rechtsklick auf die CSV-Datei wählt man à Öffnen mit à Editor. Danach öffnet sich die CSV-Datei im Editor.
Excel verwendet nämlich als Trennzeichen das Semikolon (;), das durch das Komma (,) ersetzt werden muss. Dies kann man am einfachsten, wenn man im Editor auf Bearbeiten – Ersetzen… klickt. Dort gibt man dann im Feld „Suchen nach“ das Semikolon an und im Feld „Ersetzen durch“ das Komma. Anschließend werden mit einem Klick auf „Alle ersetzen“ die Änderungen durchgeführt.
Werte die selbst ein Komma enthalten, müssen in Anführungszeichen (im Volksmund auch als „Gänsefüßchen“ bekannt) gesetzt werden. Das kann man ebenfalls durch die Ersetzen-Funktion im Editor durchführen. In diesem Beispiel müssen die Werte von „Path“ sowie „Name“ in Anführungszeichen gesetzt werden.
Die fertige Datendatei sieht dann wie folgt aus:
Die gelben Markierungen in dem Beispiel kennzeichnen die Werte die Kommas enthalten und somit in Anführungszeichen gesetzt werden müssen und die roten Markierungen kennzeichnen die nicht enthaltenen Werte, die trotzdem durch ein Komma gesetzt werden müssen. In diesem Fall sind es die Felder „description“ und „HomePage“.
Zur Vollständigkeit, hier der komplette Inhalt der Datendatei:

Path,name,givenname,surname,displayname,description,Office,emailaddress,HomePage,streetAddress,pobox,city,state,postalCode,country,userPrincipalName,sAMAccountName,profilePath,scriptPath,title,department,company
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Mueller, Sabine",Sabine,Mueller,Sabine Mueller,Festangestellte,Buero Mainz,s.mueller@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,sab@ad2008r2.dikmenoglu.de,sab,\\Server\Profile\smueller,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Tolle, Klara",Klara,Tolle,Klara Tolle,,Buero Frankfurt,k.tolle@dikmenoglu.de,,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,kla@ad2008r2.dikmenoglu.de,kla,\\Server\Profile\ktolle,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Wagner, Simone",Simone,Wagner,Simone Wagner,Aushilfe,Buero Istanbul,s.wagner@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,sim@ad2008r2.dikmenoglu.de,sim,\\Server\Profile\swagner,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Schmitt, Maria",Maria,Schmitt,Maria Schmitt,,Buero Berlin,m.schmitt@dikmenoglu.de,,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,mar@ad2008r2.dikmenoglu.de,mar,\\Server\Profile\mschmitt,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Bauer, Bettina",Bettina,Bauer,Bettina Bauer,Befristet,Buero Muenchen,b.bauer@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,bet@ad2008r2.dikmenoglu.de,bet,\\Server\Profile\bbauer,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Schmidt, Andrea",Andrea,Schmidt,Andrea Schmidt,,Buero Hamburg,a.schmidt@dikmenoglu.de,,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,and@ad2008r2.dikmenoglu.de,and,\\Server\Profile\aschmidt,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Neu, Sonja",Sonja,Neu,Sonja Neu,Praktikantin,Buero Stuttgart,s.neu@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,son@ad2008r2.dikmenoglu.de,son,\\Server\Profile\sneu,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Vogt, Silke",Silke,Vogt,Silke Vogt,Festangestellte,Buero Dresden,s.vogt@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,sil@ad2008r2.dikmenoglu.de,sil,\\Server\Profile\svogt,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH

Das Importieren der Datendatei mit der AD-PowerShell

Zum importieren von Benutzerobjekten mit der AD-PowerShell hat man folgende Möglichkeiten.

Variante 1

Der AD-PowerShell Befehl mit dem die Datendatei ins AD importiert wird sieht so aus:

Import-CSV C:\Massenimport.csv | New-ADUser -AccountPassword (ConvertTo-SecureString –AsPlainText “Pa$$w0rd!” -Force) -Enabled:$true -ChangePasswordAtLogon:$true

Wie unschwer aus dem Befehl zu erkennen ist, wird mit dem Cmdlet Import-CSV der Inhalt der Datendatei Massenimport.csv durch die Pipeline-Funktion (|) der AD-PowerShell, in das Cmdlet New-ADUser gepiped. Der Vorteil der AD-PowerShell gegenüber CSVDE ist, dass mit CSVDE keine Kennwörter gesetzt werden können, mit der AD-PowerShell aber sehr wohl! Mit diesem AD-PowerShell Befehl erhält jeder Benutzer das Startkennwort Pa$$w0rd!. Durch die Angabe von -Enabled:$true erhält man nach dem Import aktivierte Benutzer (wozu zwingend ein Kennwort vergeben werden muss). Die Angabe von -ChangePasswordAtLogon:$true aktiviert bei allen importierten Benutzern die Kontooption Benutzer muss Kennwort bei der nächsten Anmeldung ändern.

Variante 2

Eine andere Variante zum importieren von Benutzerobjekten mit dem gleichen Ergebnis, ist dieser Befehl:

Import-Csv C:\Massenimport.csv | Foreach { New-ADUser -Path $_.path -Name $_.name -givenname $_.givenname -surname $_.surname -displayname $_.displayname -office $_.office -emailaddress $_.emailaddress -HomePage $_.HomePage -streetaddress $_.streetaddress -pobox $_.pobox -city $_.city -state $_.state -postalCode $_.postalCode -userPrincipalName $_.userPrincipalName -sAMAccountName $_.sAMAccountName -profilePath $_.profilePath -scriptPath $_.scriptPath -title $_.title -department $_.department -company $_.company -PasswordNotRequired:$true -Enabled:$true }

Die Parameter wie z.B. „-Path $_.path“ entsprechen den Angaben aus der ersten Zeile der Datendatei. Dabei spielt die Reihenfolge bei der Angabe der Werte keine Rolle. Z.B. könnte die erste Zeile in der Datendatei so aussehen: sAMAccountName,Path,Name,… und der Befehl wie folgt:
Import-Csv C:\Massenimport.csv | Foreach { New-ADUser -Name $_.name –sAMAccountName $_.sAMAccountName -Path $_.path …

Die Hauptsache ist, es werden alle Felder im Befehl angegeben, die auch in der Datendatei enthalten sind.

Auch mit diesem Befehl erhält man nach dem Import aktivierte Benutzerkonten im AD! Denn der Parameter -PasswordNotRequired:$true bewirkt nichts anderes, als das im Attribut userAccountControl im Benutzerobjekt als Wert 544 eingetragen wird. Das userAccountControl besteht nämlich aus einer Bitmaske, bestehend aus mehreren Flags.

Der Parameter -PasswordNotRequired mit dem Wert $true kombiniert diese beiden Flags:

NORMAL_ACCOUNT

512

PASSWD_NOTREQD

32

Doch der Eintrag -PasswordNotRequired:$true alleine reicht nicht aus, um aktivierte Benutzerkonten zu erhalten. Es muss zwingend noch der Parameter mit dem Wert -Enabled:$true eingegeben werden. Erst dadurch sind die Benutzerkonten aktiv.

Die Benutzer melden sich dann ohne ein Kennwort an und werden direkt aufgefordert ein neues Kennwort zu vergeben. Denn der Wert 544 im userAccountControl aktiviert bei jedem importierten Benutzerobjekt die Kontooption „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“.

How to use the UserAccountControl flags to manipulate user account properties>

Variante 3 >

Eine weitere Möglichkeit und recht simpel noch dazu, stellt dieser Befehl zum importieren von Benutzerobjekten dar:

Import-Csv -Path C:\Massenimport.txt | New-ADUser -PasswordNotRequired:$true -Enabled:$true

Auch bei diesem Befehl erhält man anschließend aktive Benutzerkonten im AD. Die Benutzer melden sich dann ohne ein Kennwort an der Domäne an und werden direkt aufgefordert
ein neues Kennwort zu vergeben.

Gruppen mit der AD-PowerShell importieren>

Die Werte die in der Datendatei für einen Import von Gruppen zwingend angegeben werden müssen sind: Path, GroupScope, Name und sAMAccountName. Somit werden lediglich Sicherheitsgruppen erstellt. Daher ist es ratsam noch GroupCategory anzugeben, um den „Gruppentyp“ zu bestimmen.

Der Import der Datendatei erfolgt mit diesem Befehl:
Import-CSV C:\Gruppen.csv | New-ADGroup

Beispiele einer Datendatei zum Import von Gruppen:

# Eine domänenlokale Sicherheitsgruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",security,domainlocal,DLSG1,DLSG1,Vertrieb

# Eine globale Sicherheitsgruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",security,global,GSG1,GSG1,Buchhaltung

# Eine universelle Sicherheitsgruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",security,universal,USG1,USG1,Einkauf

# Eine domänenlokale Verteilergruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",distribution,domainlocal,DLVG1,DLVG1,Key Account

# Eine globale Verteilergruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",distribution,global,GVG1,GVG1,Techniker

# Eine universelle Verteilergruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",distribution,universal,UVG1,UVG1,Support

Einen Export mit der AD-PowerShell durchführen

Wie mit jedem Werkzeug mit dem man einen Export durchführt, kommt es auch bei der AD-PowerShell auf die gewünschten Informationen und somit auf den Filter an. Wird ein „falscher“ Filter genutzt, bekommt man unter Umständen gar keine Informationen exportiert. Nutzt man hingegen einen „ungenauen“ Filter, erhält man diesmal ggf. zu viele Informationen die es dann mühselig zu durchforsten gilt. Die wichtigste Aufgabe beim Export ist es zu definieren, welche Informationen benötigt werden und dann den Filter (sofern möglich) zu bauen.

Die folgenden Beispiele zeigen jeweils eine LDAP-Abfrage, die dann durch die Pipeline-Funktion der AD-PowerShell an das Cmdlet Export-Csv übergeben und somit die Ausgabe exportiert wird.

Export Beispiele

# Alle Benutzer aus einer OU mit allen Eigenschaften exportieren:
Get-ADUser -Filter * -Searchbase "OU=<OU>,DC=Domäne,DC=de" -Properties * | Export-Csv C:\Export.txt -NoTypeInformation

Hinweis: Nutzt man das Cmdlet Get-ADUser um Benutzerinformationen zu exportieren, werden in jedem Fall diese Attribute ausgegeben: DistinguishedName, Enabled, givenName, Name, ObjectClass, ObjectGUID, SamAccountName, ObjectSID, Surname, userPrincipalName. Gibt man beim Parameter -Properties eigene Attribute an, werden diese zusätzlich zu den bereits genannten Attributen mit ausgegeben.

# Alle Benutzerkonten exportieren, die als Vorgesetzten „Yusuf“ eingetragen haben:
Get-ADUser -Filter { Manager -eq "Yusuf" } | Export-Csv C:\Export.txt -NoTypeInformation

# Alle Organisationseinheiten (OU) der Domäne exportieren:
Get-ADOrganizationalUnit -Filter {Name -Like „*“} | Export-Csv C:\OUs.txt -NoTypeInformation

# Alle Objekte einer OU exportieren:
Get-ADObject -Filter { Name -Like "*" } -Searchbase "OU=<OU>,DC=Domäne,DC=de” | Export-Csv -NoTypeInformation C:\AlleObjekte.txt

# Alle Attribute und Klassen eines Active Directory exportieren:
Get-ADObject -Filter { Name -Like “*” } -SearchBase “CN=Schema,CN=Configuration,DC=Domäne,DC=de” | Export-Csv -NoTypeInformation C:\Schema.txt

AD-PowerShell Befehle>

Eine Datendatei in Excel importieren

In Excel lässt sich eine Datendatei wie folgt importieren:

Unter Excel 2007 wählt man in der Menüleiste zuerst „Daten“ und danach die Option „Aus Text“ aus.
Danach muss man die zu importierende Textdatei auswählen. Das kann eine CSV- oder TXT-Datei sein. Anschließend startet der Textkonvertierungs-Assistent.
Im Textkonvertierungs-Assistenten wählt man die Option Getrennt aus und klickt auf Weiter.
Im nächsten Schritt wählt man als Trennzeichen die Option Komma und als Texterkennungszeichen das Anführungszeichen aus (was standardmäßig eingestellt ist) aus.
Im darauffolgenden Schritt gilt es als Datenformat der Spalten die Option Standard zu wählen.
Zum Schluss bestätigt man, dass der Import im bestehenden Arbeitsblatt ab der ausgewählten Zelle durchgeführt werden soll.

Weitere Informationen:
How to use CSVDE.EXE to back up and restore connection agreements
>>>>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Wer hat das Objekt gelöscht?

Yusuf Dikmenoglu — Sun, 20 Dec 2009 02:48:50 GMT

Wenn ein Administrator ein Objekt im AD löscht, sollte er das bewusst tun und ein versehentliches löschen sollte nie vorkommen. Jedoch passieren die meisten Missgeschicke gerade im Alltag versehentlich, obwohl die Microsoft Werkzeuge (z.B. die MMCs Active Directory-Benutzer und -Computer sowie Active Directory-Standorte und -Dienste, dsrm, AD-PowerShell etc.) eine Sicherheitsabfrage stellen, ob man das Objekt auch wirklich löschen möchte. Handelt es sich bei dem zu löschenden Objekt um eine OU in dem weitere Objekte enthalten sind (Benutzer, Gruppen, OUs etc.), wird sogar noch eine weitere Sicherheitsabfrage gestellt.

Ein Objekt vor dem versehentlichen Löschen schützen

Damit ein Objekt nicht ausversehen gelöscht werden kann, sollte man ab Windows Server 2008 von der Option Objekt vor zufälligem Löschen schützen (auf Englisch: Protect object from accidental deletion) regen Gebrauch machen. Es ist empfehlenswert diesen Schutz mindestens auf OU-Ebene anzuwenden, sie vererbt sich aber nicht auf die untergeordneten Objekte wie z.B. auf untergeordnete OUs oder auf Benutzer-, Gruppen oder Computerobjekte die sich innerhalb der OU befinden. Einzelne Objekte wie Benutzerobjekte, Sicherheits- sowie Verteilergruppen- und Computerobjekte lassen sich ebenfalls vor dem versehentlichen Löschen schützen. Auch die Objekte in der MMC Active Directory-Standorte und -Dienste (AD-Standorte, Subnetze) lassen sich vor dem versehentlichen Löschen schützen.>>

Die Option Objekt vor zufälligem Löschen schützen lässt sich in den Eigenschaften eines Objekts im Reiter „Objekt“ aktivieren. Dieser Reiter kommt aber in der MMC „Active Directory-Benutzer und -Computer“ erst dann zum Vorschein, wenn unter „Ansicht“ die Option „Erweiterte Features“ aktiviert wurde.

Unter Windows 2000 und Windows Server 2003 existiert zwar die Möglichkeit zum aktivieren der Option „Objekt vor zufälligem Löschen schützen“ nicht, doch man kann natürlich auch unter Windows 2000 und Windows Server 2003 ein Objekt vor dem versehentlichen löschen schützen. Denn das aktivieren der Option „Objekt vor zufälligem Löschen schützen“ bewirkt nichts anderes, als das im Security-Descriptor des Objekts das "Verweigerungsrecht" zum "Löschen" für "Jeder" gesetzt wird. Genau das kann man auch unter Windows 2000 und Windows Server 2003 z.B. auf einer OU oder einem Benutzerobjekt konfigurieren.

Mit DSACLS, das sich unter Windows 2000 und Windows Server 2003 in den Windows Support Tools befindet und ab Windows Server 2008 „on Bord“ ist, lässt sich eine OU folgendermaßen vor dem versehentlichen Löschen schützen:

Dsacls „<DN der OU>“ /D Jeder:SDDT

In der Kommandozeile (CMD) lässt sich mit einer FOR-Schleife und den ds*-Tools die ab Windows Server 2003 "on Bord" sind, eine OU samt den untergeordneten OUs vor dem versehentlichen Löschen wie folgt schützen. Die Objekte wie z.B. Benutzer-, Gruppen- oder Computerobjekte die sich innerhalb dieser OUs befinden, werden dabei aber nicht vor dem versehentlichen Löschen geschützt:

FOR /F "tokens=*" %i in ('Dsquery OU "<DN der OU>" -Limit 0') do Dsacls %i /D "Jeder:SDDCDT"

Alle OUs innerhalb einer Domäne lassen sich in einer CMD mit dieser FOR-Schleife vor dem versehentlichen Löschen schützen:

FOR /F "tokens=*" %i in ('Dsquery OU -Limit 0') do Dsacls %i /D "Jeder:SDDCDT"

Über die AD-Powershell lässt sich diese Option auf einer OU wie folgt aktivieren:

Set-ADOrganizationalUnit „<DN der OU>“ –ProtectedFromAccidentialDeletion 1

bzw.

Set-ADOrganizationalUnit „<DN der OU>“ -ProtectedFromAccidentialDeletion $true

Auf allen bestehenden OUs lässt sich die Option wie folgt aktivieren:

Get-ADOrganizationalUnit -Filter * | Set-ADOrganizationalUnit –ProtectedFromAccidentialDeletion 1

Deaktivieren lässt sich die Option „Objekt vor zufälligem Löschen schützen“ in der AD-PowerShell wie folgt:

Set-ADOrganizationalUnit „<DN der OU>“ –ProtectedFromAccidentialDeletion 0

oder

Set-ADOrganizationalUnit „<DN der OU>“ -ProtectedFromAccidentialDeletion $false

Wird eine bestehende Domäne auf mindestens „Windows Server 2008“ aktualisiert, wird bei bestehenden Objekten diese Option nicht automatisch aktiviert. Auch nach dem installieren einer neuen Windows Server 2008 Domäne ist auf den bestehenden Objekten die Option „Objekt vor zufälligem Löschen schützen“ nicht aktiv. Der Schutz ist standardmäßig nur beim erstellen von neuen OUs ab Windows Server 2008 aktiviert, nicht jedoch beim erstellen von Benutzer-, Gruppen- oder Computerkonten bzw. AD-Standorten und Subnetzen.

Ist hingegen dieser Schutz auf einer OU aktiviert und man möchte diese OU verschieben, erhält man folgende Fehlermeldung. Denn zum Verschieben einer OU benötigt man das Löschrecht am Quell- und Schreibrecht am Zielort. Das Verschieben der OU ist erst dann möglich, wenn die Option deaktiviert wurde.

Das gilt natürlich auch beim löschen einer OU. Erst wenn die Option deaktiviert ist, kann die OU nach bestätigen der Sicherheitsabfrage gelöscht werden. Spätestens mit dieser Option gehört das versehentliche Löschen eines Objekts endlich der Vergangenheit an.

Wer hat den Benutzer gelöscht?

Wenn nun doch mal ausversehen z.B. das Benutzerobjekt des GFs gelöscht wurde, möchte man evtl. aufklären wer das Benutzerobjekt auf welchem DC gelöscht hat. Im Sicherheitsprotokoll des DCs auf dem das Objekt gelöscht wurde, wird unter Windows Server 2003 die EventID 630 und unter Windows Server 2008 sowie Windows Server 2008 R2 die EventID 4726 protokolliert. Denn standardmäßig wird unter Windows Server 2003 und Windows Server 2008 R2 beim Löschen eines Benutzerkontos ein Eventlogeintrag generiert, nicht jedoch unter Windows Server 2008.

Unter Windows Server 2008 muss zuerst die Unterkategorie Verzeichnisdienständerungen mit der Option Erfolgreich durch den folgenden Befehl aktiviert werden:

Auditpol /set /subcategory:Verzeichnisdienständerungen /success:enable

Erst danach wird das Löschen eines Objekts auch unter Windows Server 2008 protokolliert.

Active Directory Domain Services (AD DS) - Protokollierung

Achtung: Eine Protokollierung ist vom Betriebsrat bzw. Datenschutzbeauftragten zu genehmigen!

Die Information auf welchem DC das Objekt gelöscht wurde, wird aber nicht zwischen den DCs repliziert. Die Aufgabe besteht also darin, herauszufinden wann das Benutzerkonto auf welchem DC gelöscht wurde, um anschließend den Eventlogeintrag ausfindig zu machen. Sofern der Eventlogeintrag natürlich noch auf dem betroffenen DC existiert und nicht überschrieben wurde.

Auch das Löschen von Gruppen wird standardmäßig mit folgenden EventIDs protokolliert:

Unter Windows Server 2003

- Domänenlokale Sicherheitsgruppe = EventID 638
- Globale Sicherheitsgruppe = EventID 634
- Universelle Sicherheitsgruppe = EventID 662

- Domänenlokale Verteilergruppe = EventID 652
- Globale Verteilergruppe = EventID 657
- Universelle Verteilergruppe = EventID 667

Unter Windows Server 2008 und Windows Server 2008 R2

- Domänenlokale Sicherheitsgruppe = EventID 4734
- Globale Sicherheitsgruppe = EventID 4730
- Universelle Sicherheitsgruppe = EventID 4758 >

In kleineren AD-Umgebungen lassen sich die Eventlogs auf den DCs vielleicht noch schnell und vor allem manuell durchforsten, doch in großen bzw. weltweiten AD-Umgebungen ist das schier eine unmögliche Aufgabe. Zumindest nicht ohne Zusatzwerkzeuge wie z.B. SCOM, Log Parser oder EventComb.

Doch es gibt auch eine einfache Methode, um den Übeltäter ausfindig zu machen. Mit Hilfe von LDP und REPADMIN kann man in Erfahrung bringen, auf welchem DC das Objekt wann zu welcher Uhrzeit gelöscht wurde. Anschließend öffnet man das Sicherheitsprotokoll des betroffenen DCs und kann anschließend in der Beschreibung des Eventlogeintrags erkennen, wer das Objekt gelöscht hat. Es spielt auch keine Rolle ob unter Windows Server 2008 R2 der AD-Papierkorb aktiviert ist oder nicht.

Dazu sind die folgenden Schritte notwendig.

In LDP

Mit LDP gilt es zuerst herauszufinden, wie der Distinguished Name (DN) des gelöschten Objekts im Deleted Objects Container das sich in der Domänenpartition befindet lautet.

Im ersten Schritt verbindet man sich mit einem DC aus der Domäne, in der das Objekt gelöscht wurde. Unter Windows 2000 und Windows Server 2003 wählt man im Menü „Connection – Connect…“ und unter Windows Server 2008 sowie Windows Sever 2008 R2 „Remotedesktopverbindung – Verbinden…“ und gibt den DC an, mit dem man sich verbinden möchte.
Im zweiten Schritt binded man sich mit dem AD. Unter Windows 2000 und Windows Server 2003 wählt man dazu im Menü „Connection – Bind“ und unter Windows Server 2008 und Windows Server 2008 R2 „Remotedesktopverbindung – Gebunden…“.
Danach wählt man im Menü unter Windows 2000 und Windows Server 2003 „Options – Controls“ sowie unter Windows Server 2008 und Windows Server 2008 R2 „Optionen – Steuerelemente“. Im darauf erscheinenden Fenster „Controls“ bzw. „Steuerelemente” fügt man das LDAP-Control „Return deleted objects“ mit der OID (Object Identifier) 1.2.840.113556.1.4.417 hinzu.
Als nächstes ruft man unter Windows 2000 und Windows Server 2003 im Menü „Browse - Search“ sowie unter Windows Server 2008 und Windows Server 2008 R2 „Durchsuchen - Suchen“ das Suchfenster auf. Dort gibt man als Basis-DN den „Deleted Objects“ Container in der Domänenpartition an. Dieser lautet: CN=Deleted Objects,DC=<Domäne>,DC=<de>

Im Feld Filter gibt man die Kriterien an, nach denen man die Suche im Container “Deleted Objects” durchführen möchte. Ist der Benutzeranmeldename (Prä-Windows 2000), also das Attribut sAMAccountName bekannt, trägt man in dem Feld sAMAccountName=<Benutzeranmeldename> ein. Es kann natürlich auch ein anderes Attribut angegeben werden, dass das gewünschte Benutzerobjekt identifiziert.

Als Scope/Bereich wählt man OneLevel/Eine Ebene aus. Wählt man als Suchbereich Subtree/Unterstruktur aus, funktioniert das ebenfalls.
Unter Windows Server 2008 und Windows Server 2008 R2 gibt man im Feld „Attribute“ die Attribute an, die in der rechten Hälfte von LDP, im Suchergebnis zusätzlich zum DN angezeigt werden sollen. Gibt man keine Attribute an, werden alle Attribute des gelöschten Objekts angezeigt.
Anschließend ruft man mit einem Klick auf Optionen die Suchoptionen auf und konfiguriert die Einstellungen wie folgt. Mit einem Klick auf OK übernimmt man die vorgenommenen Einstellungen.
Unter Windows 2000 und Windows Server 2003 muss man vorher auf Options klicken, um die gewünschten Attribute und die weiteren Einstellungen vornehmen zu können.
Führt man die Suche nun mit einem Klick auf Run/Ausführen aus, erscheint in der rechten Hälfte von LDP unter anderem der gesuchte DN des gelöschten Benutzerobjekts. Dieser sieht z.B. so aus:
Dn: CN=Yusuf Dikmenoglu\0ADEL:3e9e243e-8ba9-473a-a1ee-f1b001337923,CN=Deleted Objects,DC=ad2008R2,DC=dikmenoglu,DC=de

In REPADMIN

Da nun bekannt ist wie der DN des gelöschten Benutzerobjekts lautet, gilt es auf einem DC in der Domäne in der das Benutzerobjekt gelöscht wurde, den folgenden REPADMIN-Befehl in der Kommandozeile auszuführen. Die Ausgabe von REPADMIN wird zur besseren Übersicht in eine Textdatei exportiert.

Repadmin /showobjmeta <DC> "CN=Yusuf Dikmenoglu\0ADEL:2ffa7423-7b00-4962-96f6-69d052e08c51,CN=Deleted Objects,DC=ad2008r2,DC=dikmenoglu,DC=de" > C:\Repadmin.txt

Entscheidend in der Ausgabe ist das Attribut isDeleted.

Daraus kann man erkennen, dass das Benutzerobjekt am 14.11.2009 um 23:05:08 Uhr auf dem DC R2DCON01 gelöscht wurde. Nun kann man hoffen, dass auf dem DC der erwähnte Zeitpunkt im Sicherheitsprotokoll noch nicht überschrieben wurde. Wenn der Eintrag noch existiert, findet man in der Beschreibung des Eventlogeintrags den Übeltäter.

Weitere Informationen:
Der Container Deleted Objects
Repadmin /showobjmeta

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Einen Large Integer Wert umrechnen

Yusuf Dikmenoglu — Sun, 06 Dec 2009 18:17:15 GMT

In einigen Attributen wie z.B. badPasswordTime, Last-Logon, Last-Logon-TimeStamp oder pwdLastSet wird ein Large Integer Wert (im Integer8 Format) gespeichert. Da man mit solch einem Wert herzlich wenig anfangen kann, muss dieser in unser Zeitformat umgerechnet werden. Das geht mit den Windows Support Tools oder mit Bordmitteln wie folgt.

LDP

In LDP das sich unter Windows 2000 und Windows Server 2003 in den Windows Support Tools befindet und ab Windows Server 2008 „on Bord“ ist, werden Large Integer Werte bereits in unserem Zeitformat angezeigt, ohne diese umrechnen zu müssen.

REPADMIN

Eine weitere Möglichkeit einen Large Integer Wert umzurechnen, ist das Schweizer Messer Werkzeug für die AD-Replikation REPADMIN. Unter Windows 2000 und Windows Server 2003 befindet sich REPADMIN in den Windows Support Tools und ist ab Windows Server 2008 bereits „on Bord“. Bei dem REPADMIN-Befehl müssen jedoch die letzten sieben Zeichen des Integer Wert entfernt werden. Der Befehl lautet wie folgt: REPADMIN /SHOWTIME 12903275725>>

NLTEST

Auch mit NLTEST, das sich unter Windows 2000 und Windows Server 2003 in den Windows Support Tools befindet und ab Windows Server 2008 „on Bord“ ist, lässt sich ein Large Integer Wert umrechnen. Doch dazu muss zuerst der Large Integer Wert im Taschenrechner von Windows („Start-Programme-Zubehör-Rechner“ oder „Start-Ausführen-CALC“) in einen Hexadezimal Wert umgerechnet werden. Um das zu tun, wechselt man die Ansicht des Taschenrechners unter dem Menüpunkt „Ansicht“ von „Standard“ auf „Wissenschaftlich“. Anschließend fügt man per Copy&Paste den Integer Wert hinzu. Man muss nur darauf achten, dass der Wert als „Dezimal“ (Dez) hinzugefügt wird. >

Anschließend wandelt man den eingetragenen Wert mit einem Klick auf Hex in einen Hexadezimal Wert um.

Nun gibt man in einer Kommandozeile den Befehl NLTEST /TIME:<HEX> ein. Bei dem Hexadezimal Wert gilt es zu beachten, mit einem Leerzeichen dazwischen, die rechten acht Zeichen voranzustellen. Der Befehl sieht dann so aus: NLTEST /TIME:EC821F4A 1CA6A9B

W32tm

In der Kommandozeile (CMD) lässt sich ein Large Integer Wert, ab Windows Server 2003, mit dem Befehl w32tm /ntte <Wert> in ein lesbares Format umrechnen. >

Der Attribut-Editor

Ab Windows Server 2008 und Windows Vista (mit installiertem RSAT) werden die Large Integer Werte im Attribut-Editor, der in den Eigenschaften eines Benutzerobjekts in der MMC Active Directory-Benutzer und -Computer oder in ADSIEdit zu finden ist, in der Übersicht bereits in unserem Zeitformat angezeigt. Der Reiter „Attribut-Editor“ erscheint aber erst dann, wenn unter „Ansicht“ die „erweiterten Features“ aktiviert wurden. >

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Alle Gruppenmitgliedschaften eines Benutzers exportieren

Yusuf Dikmenoglu — Sun, 22 Nov 2009 20:49:32 GMT

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

Die Gruppenmitgliedschaften eines Benutzers mit den ds*-Tools exportieren

Mit den beiden Kommandozeilentools dsquery und dsget die sich seit Windows Server 2003 "on Bord" befinden, lassen sich ebenfalls die Gruppenmitgliedschaften eines Benutzers exportieren.
Möchte man die direkten Gruppenmitgliedschaften eines Benutzers exportieren, so kann dazu der folgende Befehl verwendet werden:

dsquery user -samid <Benutzername> | dsget user -memberof > C:\Temp\Gruppenmitgliedschaften.txt

oder:

dsget user "DN des Benutzerobjekts" -memberof > C:\Temp\Gruppenmitgliedschaften.txt >

Sollen hingegen auch die verschachtelten Gruppenmitgliedschaften angezeigt werden, dann gilt es diesen Befehl auszuführen:

dsget user "DN des Benutzerobjekts" -memberof -expand > C:\Temp\Gruppenmitgliedschaften.txt

bzw.

dsquery user -samid <Benutzername> | dsget user -memberof -expand > C:\Temp\Gruppenmitgliedschaften.txt >

Hinweis: Unter Windows Server 2008 R2 und Windows 7 liefert dsget nicht die korrekten Daten.
Das lässt sich jedoch durch einen Hotfix beheben:

The "dsget user -memberof -expand" command returns incorrect results in Windows Server 2008 R2 and in Windows 7>

Die Gruppenmitgliedschaften eines Benutzers mit "Net User" exportieren

Auch mit dem Kommandozeilentool NET kann man die Gruppenmitgliedschaften eines Benutzer wie folgt exportieren:

Net User <sAMAccountName> /Domain > C:\Temp\Gruppenmitgliedschaften.txt>

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

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Der RID-Master und sein RID-Pool

Yusuf Dikmenoglu — Sun, 25 Oct 2009 10:25:48 GMT

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

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Den Domänen- sowie Gesamtstrukturfunktionsmodus mit der AD-Powershell hochstufen

Yusuf Dikmenoglu — Sun, 18 Oct 2009 17:30:42 GMT

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:

definierten Namen (Distinguished Name, kurz DN)
die objectGUID
die ObjectSID
DNS-Domänennamen
NETBIOS-Domänennamen angegeben werden.

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

vollqualifizierte Domänenname
ObjectGUID
NetBIOS-Name
DNS-Hostname (FQDN) angegeben werden.

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
>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Ein Server kann in einer Subdomäne nicht als zusätzlicher DC heraufgestuft werden

Yusuf Dikmenoglu — Fri, 16 Oct 2009 16:28:33 GMT

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

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Die letzte interaktive Domänenanmeldung anzeigen

Yusuf Dikmenoglu — Sat, 10 Oct 2009 16:46:57 GMT

Seit Windows Server 2008 gibt es ein neues Feature, das bei der Domänenanmeldung den Zeitpunkt der letzten interaktiven Anmeldung anzeigt.

Bisher hat man seit der Einführung des Active Directory mit Windows 2000 die Möglichkeit den Zeitpunkt der letzten Domänenanmeldung eines Benutzers, durch das Attribut Last-Logon herauszufinden. Der Nachteil an diesem Attribut ist, dass es nicht zwischen den Domänencontrollern (DCs) repliziert wird. Somit muss man jeden DC in der Domäne einzeln abfragen um das aktuellste Datum zu erhalten. Mit Windows Server 2003 hat Microsoft dann das Attribut Last-Logon-Timestamp eingeführt, das sogar zwischen den DCs repliziert wird. Weitere Einzelheiten werden im folgenden Artikel erläutert:

Die letzte Benutzeranmeldung herausfinden

Für das Anzeigen der „letzten interaktiven Domänenanmeldung“ wurden dem AD-Schema ab Windows Server 2008 vier Attribute hinzugefügt, als die wären:

msDS-FailedInteractiveLogonCount: In diesem Attribut wird die Anzahl der fehlgeschlagenen Anmeldeversuche seit der Aktivierung dieser Funktion gespeichert.
msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon: Die Anzahl der fehlgeschlagenen interaktiven Anmeldeversuche bis zur letzten erfolgreichen Anmeldung werden in diesem Attribut gespeichert.
msDS-LastFailedInteractiveLogonTime: Der Zeitpunkt des letzten fehlgeschlagenen Anmeldeversuchs wird in diesem Attribut gespeichert.
msDS-LastSuccessfulInteractiveLogonTime: Wann die letzte erfolgreiche Anmeldung und somit die korrekte Kombination aus Benutzername und Kennwort eingegeben wurde, wird in diesem Attribut gespeichert.

Mit dieser neuen Funktion kann der Mitarbeiter einfach erkennen, ob evtl. sein Benutzerkonto kompromittiert wurde oder dieser ein Opfer einer Brute-Force Attacke ist.

Ist diese Funktion aktiviert, kann man die letzte erfolgreiche Benutzeranmeldung neben dem Attribut Last-Logon und Last-Logon-TimeStamp, auch durch das Attribut msDS-LastSuccessfulInteractiveLogonTime herausfinden.

Die letzte erfolgreiche Anmeldung aller Benutzer einer bestimmten OU kann man z.B. mit diesem Befehl abfragen:

dsquery * "OU=<OU>,DC=Domäne,DC=de" -attr name msDS-LastSuccessfulInteractiveLogonTime

Als Ergebnis wird ein 8 Byte bzw. 64 Bit Integer8 Wert geliefert. Diesen kann man dann in der Kommandozeile mit dem folgenden Befehl in ein leserliches Datumsformat konvertieren: w32tm /ntte <Wert>.

Falls die Daten einer bestimmten OU z.B. in Excel weiterverarbeitet werden sollen, könnte mit CSVDE ein Export der Werte mit diesem Befehl durchgeführt werden:

CSVDE -f Benutzer.csv -r "(&(objectClass=user)(objectCategory=person))" –d "OU=<OU>,DC=Domäne,DC=de" –p onelevel -l "name,sAMAccountName,msDS-LastSuccessfulInteractiveLogonTime"

Wo wird dieses Feature aktiviert?

Diese neue Funktion steht in Form einer neuen GPO zur Verfügung:

Computerkonfiguration\Richtlinien\Administrative Vorlagen\Windows-Komponenten\Windows-Anmeldeoptionen\Informationen zu vorherigen Anmeldungen bei der Benutzeranmeldung anzeigen

Sollen die Informationen nur beim anmelden an DCs angezeigt werden, gilt es diese Richtlinie nur auf die DCs zu verlinken (genauer: Auf die OU „Domain Controllers“). Dazu kann man entweder die Default Domain Controllers Richtlinie oder eine neu erstellte GPO verwenden. Ist es hingegen gewünscht die Infos auch auf den Clients z.B. der Finanzbuchabteilung anzuzeigen, gilt es zusätzlich die GPO auf die Clients der Finanzbuchabteilung (auf einer eigenen OU) zu verlinken.

Wie es unschwer zu erkennen ist, handelt es sich dabei um eine Computerrichtlinie die auf Clients, Mitgliedsserver und DCs verlinkt werden muss und nicht auf OUs, in denen sich ausschließlich Benutzer oder Gruppen befinden!

Die Voraussetzungen

Der Domänenfunktionsmodus muss sich auf Windows Server 2008 oder höher befinden.
Auf der Client Seite wird diese Funktion erst ab Windows Vista unterstützt. Ältere Betriebssysteme ignorieren diese Funktion.
Möchte man die Infos auf den Clients einer bestimmten OU angezeigt bekommen (z.B. auf den Clients der Finanzbuchabteilung), muss die GPO zwingend auch auf die DCs angewendet werden. Somit bekommt man dann die Infos auch bei der Anmeldung an den DCs angezeigt. Das die Infos nur auf den Clients und nicht noch zusätzlich auf den DCs angezeigt werden, ist leider nicht möglich.

Die Funktionsweise der „letzten interaktiven Anmeldung“

Ist das Anzeigen der letzten interaktiven Domänenanmeldung aktiviert, erhält der Domänenbenutzer bei seiner ersten Domänenanmeldung nach Aktivierung dieser Funktion zuerst folgende Information angezeigt, ehe er den Desktop zu Gesicht bekommt:

Ab der zweiten Anmeldung werden dem Benutzer dann die folgenden Informationen angezeigt:

Den Zeitpunkt der letzten erfolgreichen interaktiven Anmeldung.
Den Zeitpunkt des letzten fehlgeschlagenen interaktiven Anmeldeversuchs.
Die Anzahl der fehlgeschlagenen Anmeldeversuche seit der letzten erfolgreichen interaktiven Anmeldung.

Die o.g. vier Attribute werden zwischen den DCs innerhalb einer Domäne repliziert. Sie werden jedoch nicht in den globalen Katalog repliziert und werden auch nicht indiziert (was sich beides in den jeweiligen Attributen ändern lässt).

Hat sich der Benutzer „einmal“ an einem Computer angemeldet auf dem die GPO angewendet wird, werden die Werte in den o.g. Attributen auch dann aktualisiert, wenn sich der Benutzer an Computern anmeldet auf denen die GPO nicht wirkt. Aber die Informationen über die letzte interaktive Anmeldung und über die letzten Anmeldeversuche werden logischerweise dann nicht angezeigt.

Bei der letzten interaktiven Anmeldung wird auch kein Hinweis angezeigt, von welchem Computer aus der Anmeldeversuch durchgeführt wurde. Schließlich sind die Informationen in den Eigenschaften des Benutzer- und nicht Computerobjekts hinterlegt. Um festzustellen von welchem Computer der Anmeldeversuch durchgeführt wurde, müssen dazu die Sicherheitsprotokolle aller DCs innerhalb der Domäne überprüft werden.

Die Besonderheiten bei diesem Feature

Wenn die Voraussetzungen für dieses Feature nicht erfüllt sind, erhält man bei der Anmeldung folgende Meldung:

Aufgrund der Sicherheitsrichtlinien auf diesem Computer werden Informationen über die letzte interaktive Anmeldung angezeigt. Die Informationen konnten nicht ermittelt werden. Wenden Sie sich an den Netzwerkadministrator, um weitere Unterstützung zu erhalten.

Anschließend gelangt man erneut zum Anmeldebildschirm. Eine interaktive Anmeldung (STRG+ALT+ENTF) lokal an dem Computer ist nicht möglich!

Das nicht Erfüllen der Voraussetzungen sind:

Ist der Domänenfunktionsmodus nicht auf mindestens „Windows Server 2008“ und die GPO wird aktiviert und auf eine OU verlinkt, können sich die Benutzer an den Computern die sich in dieser OU befinden nicht anmelden. Das bedeutet, wenn die GPO z.B. auf die OU „Domain Controllers“ verlinkt wird, kann man sich anschließend nicht mehr interaktiv (STRG+ALT+ENTF) an den DCs anmelden!
Wird die GPO nur auf eine OU verlinkt in der sich Windows Server 2008 Mitgliedsserver, Windows Vista oder Windows 7 Clients befinden und nicht noch zusätzlich auf die OU „Domain Controllers“, so bleibt den Benutzern ebenfalls die Anmeldung an den betroffenen Computern verwehrt.

Es sollte unbedingt vor dem Einsatz dieser Funktion ein ausgiebiger Test in einer Testumgebung durchgeführt werden!

>>>>>>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Der Container Deleted Objects

Yusuf Dikmenoglu — Sat, 01 Aug 2009 21:05:05 GMT

Wenn im Active Directory (AD) Objekte gelöscht werden, verschwinden diese nicht sofort aus der AD-Datenbank (NTDS.dit). Das AD markiert das Objekt als gelöscht, indem das Attribut Is-Deleted des Objekts auf den Wert TRUE (Wahr) gesetzt wird. Dabei werden von dem Objekt die meisten Attribute für immer entfernt. Anschließend wandert das Objekt in den Container „Deleted Objects“ (der in fast allen Verzeichnispartitionen existiert) und wird ab diesem Zeitpunkt als Tombstone (zu deutsch: Grabstein) bezeichnet. Im Container Deleted Objects erhält das Tombstone einen speziellen Distinguished Name (DN), der so aussieht: „CN=<alter RDN>\0ADEL:<Object-GUID>“. Der DN des gelöschten Benutzerobjekts „Yusuf Dikmenoglu“ sieht z.B. so aus: CN=Yusuf Dikmenoglu\0ADEL:4b506a93-d721-4cbf-87dc-565939cf07af,CN=Deleted Objects,DC=blog,DC=dikmenoglu,DC=de

Das gelöschte Objekt wandert deshalb zuerst in den Container Deleted Objects, damit jeder Domänencontroller (DC) z.B. in einer weltweit verteilten Umgebung von der Löschung des Objekts in Kenntnis gesetzt wird, ehe das Objekt endgültig aus dem AD gelöscht wird. Gerade in größeren AD-Umgebungen mit einem komplexen Replikationszeitplan, ist diese Vorgehensweise für das Löschen von Objekten zwingend. Denn würde das Objekt nach dem löschen direkt aus der AD-Datenbank entfernt werden, würden die anderen DCs von dieser Löschung nichts mitbekommen und es entständen Lingering Objects (zu Deutsch: herumlungernde Objekte).

Lingering Objects (veraltete Objekte)

Das gelöschte Objekt verbleibt im Container Deleted Objects so lange, bis die Tombstone Lifetime (TSL) abgelaufen ist. Die TSL beträgt standardmäßig bei einer ursprünglich erstellten Windows 2000 sowie Windows Server 2003 Gesamtstruktur 60 Tage. Beim erstellen einer Gesamtstruktur ab Windows Server 2003 SP1 oder ab Windows Server 2003 R2 SP2 beträgt die TSL 180 Tage. Erst nach Ablauf der TSL Zeit, wird das Objekt nun endgültig vom Garbage Collection Prozess der standardmäßig alle 12 Stunden auf jedem DC läuft, aus dem AD entfernt.

Die Tombstone Lifetime

Dabei können Objekte aus der Konfigurations-, Domänen- und Anwendungsverzeichnispartition (wie z.B. ForestDNSZones und DomainDNSZones) gelöscht werden, aber nicht aus der Schemapartition! Schemaobjekte (Attribute und Klassen) können nicht entfernt werden, höchstens deaktiviert.

Ab Windows Server 2003 kann ein gelöschtes Objekt, sprich das Tombstone mit wenigen Attributen reanimiert werden. Wurde ein Objekt gelöscht, wird der DN vom Ursprungsort des Objekts im Attribut lastKnownParent eingetragen. Ein Objekt das autoritativ wiederhergestellt wurde, enthält ebenfalls im Attribut lastKnownParent den Ursprungsort. Oder wenn ein Objekt in den Container LostAndFound verschoben wird (bei einem Konflikt), der in den Verzeichnispartitionen Konfigurationspartition, Domänenpartition und Anwendungsverzeichnispartitionen wie die beiden DNS-Partitionen ForestDNSZones und DomainDNSZones existiert, wird im Attribut lastKnownParent ebenso der Ursprungsort des Konfliktobjekts eingetragen. Beim verschieben oder kopieren eines Objekts wird kein Wert im Attribut lastKnownParent eingetragen.

Wenn nun in der Domäne blog.dikmenoglu.de der Benutzer „Yusuf“ der sich in der OU „IT“ befindet gelöscht wird, enthält das Attribut lastKnownParent des gelöschten Benutzerobjekts im Container Deleted Objects der Domänenpartition den folgenden Wert:
OU=IT,DC=blog,DC=dikmenoglu,DC=de

Dadurch lassen sich wiederhergestellte Tombstones, autoritativ wiederhergestellte Objekte oder Konfliktobjekte die sich im Container LostAndFound befinden ausfindig machen, in dem man eine Abfrage nach dem Attribut lastKnownParent durchführt und dabei diesen LDAP-Filter verwendet:
(&(objectclass=*)(lastKnownParent=*))

Möchte man sich lediglich Benutzerkonten anzeigen lassen, so kann man z.B. bei einer benutzerdefinierten gespeicherten Abfrage diesen Filter verwenden:
(objectcategory=person)(lastKnownParent=*)

Den Container Deleted Object mit LDP anzeigen

Der versteckte Container Deleted Objects wird weder in der MMC Active Directory-Benutzer und -Computer, noch in ADSIEdit.msc angezeigt. Stattdessen kann man sich mit LDP.exe oder z.B. dem AD Explorer den Container Deleted Objects anzeigen lassen. Wobei der Container in den Anwendungsverzeichnispartitionen lediglich mit LDP angezeigt werden kann und nicht mit dem AD Explorer. Natürlich können aber auch andere LDAP-Browser verwendet werden.

Das LDP.exe befindet sich unter Windows 2000 und Windows Server 2003 in den Windows Support Tools und ist bereits ab Windows Server 2008 on Bord.
Unter Start - Ausführen startet man als Erstes das LDP
Danach muss man sich mit einem DC verbinden. Dazu gilt es unter Windows Server 2003 im Menüpunkt Connection die Option Connect… aufzurufen und im darauffolgenden Fenster einen DC einzutragen. Unter Windows Server 2008 heißt der Menüpunkt Remotedesktopverbindung und die Option Verbinden…
Nun gilt es unter Connection/Remotedesktopverbindung - Bind…/Gebunden… ein entsprechendes Benutzerkonto (z.B. den Domänen-Admin) anzugeben, um sich mit diesem Benutzer an das AD zu „binden“.
Anschließend muss der Distinguished Name (DN) des entsprechenden Deleted Objects Container unter View/Ansicht - Tree/Struktur angegeben werden.

Der DN des Container Deleted Objects in der Konfigurationspartition lautet:
CN=Deleted Objects,CN=Configuration,DC=Root-Domäne

In der Domänenpartition lautet der DN von Deleted Objects wie folgt:
CN=Deleted Objects,DC=blog,DC=dikmenoglu,DC=de

Der DN von Deleted Objects in den beiden DNS-Anwendungsverzeichnispartitionen lautet folgendermaßen:
CN=Deleted Objects,DC=ForestDNSZones,DC=Root-Domäne
CN=Deleted Objects,DC=DomainDNSZones,DC=Domäne,DC=de
Nach dem man sich mit dem Container Deleted Objects verbunden hat, sieht man den Eintrag zwar auf der linken Seite im LDP-Fenster, jedoch erscheinen unter dem Eintrag keine weiteren Einträge, sprich die gelöschten Objekte bzw. Tombstones kommen nicht zum Vorschein. Diese erscheinen erst, wenn unter dem Menüpunkt Options/Optionen der Menüeintrag Controls/Steuerelemente ausgewählt und das LDAP-Control Return deleted objects (1.2.840.113556.1.4.417) als aktives Steuerelement eingecheckt wurde.
Um nun ein Tombstone mit LDP zu reanimieren, müssen zwei Attribute im Tombstone verändert werden. Dazu klickt man mit rechts auf das zu wiederherstellende Objekt und wählt die Option Modify/Ändern. Danach muss zum einen der Wert im Attribut isDeleted gelöscht werden (den Wert aus FALSE zu setzen reicht nicht aus) und zum anderen, muss der DN des Objekts geändert werden. Dabei muss das Tombstone auch nicht zwingend an seinem Ursprungsort, der im Attribut lastKnownParent eingetragen ist, wiederhergestellt werden. Mit einem Klick auf Run/Ausführen wird das Tombstone dann wiederhergestellt.
In größeren AD-Umgebungen kann es im Container Deleted Objects das sich in der Domänenpartition befindet, durch die vielen gelöschten Objekte sehr unübersichtlich werden. Um sich lediglich die gelöschten Objekte eines bestimmten Zeitraums auf der rechten Seite im LDP anzeigen zu lassen, muss nach einem bestimmten Attribut in den gelöschten Objekten (den Tombstones) gesucht werden. Das Attribut in dem das Löschdatum enthalten ist lautet whenChanged.

Möchte man sich z.B. die Objekte die in den letzten 10 Tagen gelöscht wurden anzeigen, so klickt man auf der linken Seite im LDP mit rechts auf den Eintrag CN=Deleted Objects,DC=Domäne,DC=de und wählt die Option Search/Suchen. Als Filter könnte dieser eingesetzt werden: (&(objectclass=user)(whenchanged>=20090724023000.0Z)). Im Feld Attribute können die gewünschten Attribute des Tombstones angegeben werden, die ebenfalls angezeigt werden sollen. Oder es wird ein Wildcard (das Sternchen *) angegeben, um alle Attribute die im Tombstone enthalten sind anzuzeigen.
Dabei muss der Wert, sprich das Datum und die Uhrzeit im Attribut whenChanged in folgender Notation angegeben werden:
2009(Jahr) 07(Monat) 24(Tag) 02(Stunden) 30(Minuten) 00(Sekunden).0Z

Man beachte bei der Zeitangabe, dass das Attribut whenChanged nicht zwischen den DCs repliziert wird.
Das bedeutet, dass der Wert im Attribut whenChanged sich von DC zu DC unterscheidet.
Schaut man sich die LDAP-Controls im LDP unter Windows Server 2008 R2 genauer an, entdeckt man zwei neue Einträge. Die beiden neuen Einträge sind:

Mit dem LDAP-Control Return deactivated links (1.2.840.113556.1.4.2065) werden die verknüpften Attribute bei aktiviertem AD-Papierkorb eines Objekts angezeigt (z.B. das memberOf Attribut eines Benutzerobjekts). Denn wenn der AD-Papierkorb im Windows Server 2008 R2 aktiviert wurde, werden die verknüpften Attribute (Forward- und Backlink) beim Löschen eines Objekts nicht entfernt. Somit ist auch das Geheimnis des AD-Papierkorbs entlüftet, wie es mit den verknüpften Attributen umgeht.

Weitere Informationen:
Last-Known-Parent Attribute (Windows)
When-Changed Attribute (Windows)
Der Active Directory-Papierkorb im Windows Server 2008 R2
Verknüpfte Attribute
Viewing deleted objects in Active Directory
How to let non-administrators view the Active Directory deleted objects container in Windows Server 2003 and in Windows 2000 Server
Searching for Deleted Objects
>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Die Infrastrukturmaster der Anwendungsverzeichnispartitionen

Yusuf Dikmenoglu — Fri, 17 Jul 2009 08:29:48 GMT

Soll der erste Read-Only Domänencontroller (kurz RODC) zu einer Windows Server 2003 Gesamtstruktur hinzugefügt werden, müssen bestimmte Voraussetzungen erfüllt sein. Eine davon ist, dass das ADPREP mit dem Parameter /RODCPREP mit „Organisations-Admin“ Rechten auf irgendeinem DC auszuführen gilt. In einer Gesamtstruktur mit mehreren Domänen kontaktiert das ADPREP jeden Infrastrukturmaster um die Berechtigungen der Anwendungsverzeichnispartitionen DomainDNSZones und ForestDNSZones zu aktualisieren. Mit Ausführen von ADPREP /RODCPREP werden die Security Descriptor der Anwendungsverzeichnispartitionen "DomainDNSZones" sowie "ForestDNSZones" angepasst. Nach Ausführen des Befehls wird der Gruppe NT-AUTORITÄT\DOMÄNENCONTROLLER DER ORGANISATION auf den beiden DNS-Anwendungsverzeichnispartitionen die entsprechenden Zugriffsberechtigungen auf die Replikation erteilt. Ist die Gesamtstruktur mit Windows Server 2008 erstellt worden, ist das Ausführen von ADPREP nicht notwendig. >

Beim aktualisieren des security descriptor der einzelnen DNS-Anwendungsverzeichnispartitionen mit ADPREP /RODCPREP kann es jedoch zu dem Problem kommen, dass der Infrastrukturmaster einer DNS-Anwendungsverzeichnispartition nicht erreichbar ist.

Die Fehlermeldungen in der Kommandozeile lauten:

Adprep konnte kein Replikat für Partition DC=ForestDnsZones,DC=Root-Domäne erreichen.
ADPREP hat einen LDAP-Fehler festgestellt.
Fehlercode: 0x0. Erweiterter Server-Fehlercode: 0x0, Server-Fehlermeldung:(null).

und

Adprep konnte kein Replikat für Partition DC=DomainDnsZones,DC=Domäne,DC=de erreichen.
ADPREP hat einen LDAP-Fehler festgestellt.
Fehlercode: 0x0. Erweiterter Server-Fehlercode: 0x0, Server-Fehlermeldung:(null).

Der Grund dafür ist, dass ab Windows Server 2003 eine Besonderheit was die Rolle des Infrastrukturmasters anbetrifft existiert. Denn mit Windows Server 2003 wurden erstmals die Anwendungsverzeichnispartitionen eingeführt, wie z.B. im DNS die ForestDNSZones- und DomainDNSZones-Partitionen. Ab Windows Server 2003 existiert nämlich zusätzlich je ein Infrastrukturmaster pro Anwendungsverzeichnispartition. Als Infrastrukturmaster einer Anwendungsverzeichnispartition kann irgendein DC aus der jeweiligen Domäne ausgewählt werden und dieser muss nicht der Träger der Infrastrukturmasterrolle für die Domänenpartition sein.

Es existiert also ein Infrastrukturmaster für die Gesamtstrukturweite Anwendungsverzeichnispartition „ForestDNSZones“ und je ein Infrastrukturmaster pro „DomainDNSZones“. Das bedeutet für eine Gesamtstruktur mit zehn Domänen in der lediglich die Standard-Anwendungsverzeichnispartition im DNS genutzt werden und die DNS-Informationen pro Domäne in der DomainDNSZones gespeichert wird, folgende Aufteilung der FSMO-Rollen: >

Ein Schemamaster
Ein Domänennamenmaster
Zehn RID-Master (Relative ID)
Zehn PDC-Emulatoren
Zehn Infrastrukturmaster für die Domänen bzw. Domänenpartitionen
Ein Infrastrukturmaster für die Anwendungsverzeichnispartition "ForestDNSZones"
Zehn Infrastrukturmaster für die Anwendungsverzeichnispartition "DomainDNSZones"

Es existieren also insgesamt 21 Infrastrukturmaster in der Gesamtstruktur.

In allen Unternehmen die seit mehreren Jahren eine AD-Umgebung betreiben, müssen mit der Zeit auch die Hardware der Betriebsmasterrollen ausgetauscht werden. Wird die Hardware des FSMO-Rolleninhabers ausgetauscht, müssen alle Rollen die der DC innehat auf einen anderen DC verschoben werden. Dies kann händisch oder automatisch während dem DCPROMO-Vorgang erfolgen. Natürlich müssen auch bei einem Hardware-Crash des Rolleninhabers die gecrashten Rollen auf einem anderen DC erneut bereitgestellt werden.

Die FSMO-Rollen verschieben
Die FSMO-Rollen mit DCPROMO verschieben

Und genau bei dem Übertragen oder Übernehmen der FSMO-Rollen gehen die Infrastrukturmaster der Anwendungsverzeichnispartitionen in Vergessenheit. In den meisten Umgebungen handelt es sich dabei um den Infrastrukturmaster der beiden DNS-Anwendungsverzeichnispartitionen „ForestDNSZones“ sowie „DomainDNSZones“. Andere Anwendungsverzeichnispartitionen sind in vielen Umgebungen nicht im Einsatz.

Leider werden die Infrastrukturmasterrollen der Anwendungsverzeichnispartitionen unter Windows Server 2003 sowie Windows Server 2008 beim Übertragen (Rolleninhaber ist online) auf einen anderen DC weder über die GUI, noch in der Kommandozeile mit NTDSUTIL (NTDSUTIL - Transfer) "verschoben". Diese müssen zusätzlich noch händisch auf einen anderen DC übertragen werden. Auch beim Übernehmen (Rolleninhaber ist offline, z.B. bei einem DC-Crash) der FSMO-Rollen auf einen anderen DC, müssen zusätzlich die Infrastrukturmaster der Anwendungsverzeichnispartitionen händisch verschoben werden.

Bedauerlich das Microsoft an die Infrastrukturmaster der Anwendungsverzeichnispartitionen keine Beachtung geschenkt hat. Es erscheint weder ein Hinweis beim verschieben der FSMO-Rollen, noch wird ein Eintrag in der Ereignisanzeige protokolliert, der auf das Fehlen der Infrastrukturmaster für die Anwendungsverzeichnispartitionen hinweist. Auch überprüft das DCDIAG bei dem Test KnowsOfRoleHolders nicht die Anwendungsverzeichnispartitionen nach dem Infrastrukturmaster, sondern nur den Infrastrukturmaster der Domänenpartition. Das Fehlen eines Infrastrukturmasters für eine Anwendungsverzeichnispartition bleibt somit unbemerkt.

>>>>>

Den Infrastrukturmaster der DNS-Anwendungsverzeichnispartitionen mit ADSIEdit ändern

Die Infrastrukturmasterrollen der Anwendungsverzeichnispartitionen "ForestDNSZones und "DomainDNSZones" sollten bevorzugt auf dem aktuellen Infrastrukturmaster wie folgt mit ADSIEdit auf einen anderen DC verschoben werden:

Unter Windows Server 2003 gilt es zuerst die Windows Support Tools (auf der Server-CD im Verzeichnis Support\Tools) zu installieren.
Danach startet man das ADSIEdit, was ab Windows Server 2008 bereits "on Bord" ist.
Im ADSIEdit wählt man mit einem Rechtsklick auf den Eintrag "ADSI Edit" die Option "Connect to..." aus.
Im darauffolgenden Fenster "Connection Settings" ist im Bereich "Connection Point" die Option "Select or type a Distinguished Name or Naming Context" auszuwählen.
In dem Feld trägt man dann den Distinguished Name (DN) der entsprechenden Anwendungsverzeichnispartition ein, um sich mit dieser Verzeichnispartition zu verbinden. Im Fall der "ForestDNSZones" würde der DN so lauten:
DC=ForestDNSZones,DC=Root-Domäne,DC=TLD
Anschließend verbindet man sich noch mit den einzelnen (je nach Anzahl der Domänen) "DomainDNSZones" Partitionen. Der DN lautet wie folgt:
DC=DomainDNSZones,DC=Domäne,DC=TLD
Wenn man nun im ADSIEdit auf der linken Seite die einzelnen Verzeichnispartitionen mit denen man sich verbunden hat erweitert, findet man auf der rechten Seite das Objekt CN=Infrastructure. Mit einem Rechtsklick auf dieses Objekt ruft man die Eigenschaften des Objekts auf und ändert dort den Wert im Attribut fSMORoleOwner. An dieser Stelle muss nicht zwingend(!) der Infrastrukturmaster für die Domänenpartition angegeben werden. Es muss bloß ein verfügbarer DC der Domäne eingetragen werden.
Der Wert im Attribut sieht z.B. so aus:
CN=NTDS Settings,CN=DCON01,CN=Servers,CN=<Standort>,CN=Sites,CN=Configuration,DC=intra,DC=dikmenoglu,DC=de

Den Infrastrukturmaster der DNS-Anwendungsverzeichnispartitionen mit LDP ändern

Unter Windows Server 2003 befindet sich das LDP in den Windows Support Tools und ab Windows Server 2008 ist es bereits „on Bord“.
Zuerst gilt es das LDP unter Start - Ausführen - LDP zu starten.
Als nächstes sollte man sich mit dem aktuellen Infrastrukturmaster verbinden. Dazu ruft man unter Windows Server 2003 im Menüpunkt Connection die Option „Connect…“ auf und trägt im darauf erscheinenden Fenster den DC ein und klickt auf OK. Unter Windows Server 2008 heißt der Menüpunkt Remotedesktopverbindung und die Option Verbinden…
Jetzt gilt es unter Connection/Remotedesktopverbindung - Bind…/Gebunden… ein entsprechendes Benutzerkonto (z.B. den Domänen-Admin) anzugeben, um sich mit diesem Benutzer an das AD zu „binden“.
Nun muss der Distinguished Name (DN) der entsprechenden Anwendungsverzeichnispartition unter View/Ansicht - Tree/Struktur angegeben werden. Der DN für ForestDNSZones lautet DC=ForestDNSZones,DC=Root-Domäne,DC=TLD und für DomainDNSZones DC=DomainDNSZones,DC=Domäne,DC=TLD.
Mit einem Rechtsklick auf den Eintrag CN=Infrastructure,DC=ForestDnsZones,DC=Root-Domäne,DC=de bzw. CN=Infrastructure,DC=DomainDnsZones,DC=Domäne,DC=de gilt es die Option Modify auszuwählen.
Anschließend muss als Wert im Attribut fSMORoleOwner der DN des NTDS Settings Objekts des zukünftigen Infrastrukturmaster eingetragen werden, z.B.:
CN=NTDS Settings,CN=MZDCON02,CN=Servers,CN=Mainz,CN=Sites,CN=Configuration,DC=intra,DC=dikmenoglu,DC=de

Existieren evtl. noch selbst erstellte Anwendungsverzeichnispartitionen, so müssen die Infrastrukturmasterrollen dieser Verzeichnispartitionen ebenfalls auf einen anderen DC verschoben werden, wenn der Ursprungsrollenträger aus der Domäne entfernt werden soll oder nicht mehr zur Verfügung steht. >

Zum ändern des Infrastrukturmasters für die Anwendungsverzeichnispartition „DomainDNSZones“ kann man auch das Skript in dem folgenden Artikel verwenden:
Error message when you run the "Adprep /rodcprep" command in Windows Server 2008: "Adprep could not contact a replica for partition DC=DomainDnsZones,DC=Contoso,DC=com"

Die Verzeichnispartitionen und die Infrastrukturmasterrolle der DNS-Partitionen anzeigen

Der folgende Befehl kann dazu verwendet werden, alle Verzeichnispartitionen die in der Gesamtstruktur existieren anzeigen zu lassen:
Dsquery * CN=Partitions,CN=Configuration,DC=Domäne,DC=de -attr nCName

Möchte man sich lediglich die Anwendungsverzeichnispartitionen die in der Gesamtstruktur existieren anzeigen lassen, so ist das mit diesem Befehl möglich:
Dsquery * CN=Partitions,CN=Configuration,DC=Root-Domäne,DC=de -Filter "(&(objectcategory=crossRef)(systemFlags:1.2.840.113556.1.4.803:=5))" -Scope OneLevel -attr dnsRoot

Bei dieser Abfrage werden alle crossRef-Objekte im Container Partitions abgefragt, die im systemFlags Attribut als Wert 0101 (Dezimal 5) eingetragen haben. Der Befehl sieht in einer kürzeren Fassung mit dem gleichen Ergebnis so aus:

Dsquery * CN=Partitions,CN=Configuration,DC= Root-Domäne ,DC =de -Filter (systemFlags=5) -Scope OneLevel -attr dnsRoot

Die Abfrage nach dem Attribut dnsRoot liefert als Ergebnis immer den DNS-Namen der Anwendungsverzeichnispartitionen, wie z.B.: DomainDNSZones.blog.dikmenoglu.de. Bei der Abfrage nach dem Attribut nCName wird als Ergebnis der „Distinguished Name“ der Partitionen geliefert. Die Abfrage sieht wie folgt aus:
Dsquery * CN=Partitions,CN=Configuration,DC=Root-Domäne,DC=de -Filter (systemFlags=5) -Scope OneLevel -attr nCName

Die Infrastrukturmasterrolle der ForestDNSZones-Partition lässt sich mit diesem Befehl anzeigen:
Dsquery * CN=Infrastructure,DC=ForestDNSZones,DC=Root-Domäne -attr fSMORoleOwner

Die Infrastrukturmasterrollen der jeweiligen DomainDNSZones-Partition lassen sich wie folgt herausfinden:
Dsquery * CN=Infrastructure,DC=DomainDNSZones,DC=<die entsprechende Domäne>,DC=TLD -attr fSMORoleOwner

Warum beeinträchtigt ein fehlender Infrastrukturmaster einer DNS-Anwendungsverzeichnispartition nicht die Domäne?

Die Arbeit des Infrastrukturmaster besteht darin, domänenübergreifende Objektreferenzen (z.B. bei domänenübergreifenden Gruppenmitgliedschaften) innerhalb seiner Domäne stets aktuell zu halten. In den beiden DNS-Anwendungsverzeichnispartitionen werden jedoch ausschließlich die DNS-Zonen (Forward Lookup- und Reverse Lookup Zonen) gespeichert, die keine Verweise zu anderen Objekten in anderen Verzeichnispartitionen verwenden. Daher hat ein Infrastrukturmaster für die beiden DNS-Anwendungsverzeichnispartitionen nichts zu tun und wird deshalb nicht benötigt. Aus diesem Grund fällt an dieser Stelle ein fehlender Infrastrukturmaster für die DNS-Anwendungsverzeichnispartitionen im laufenden Betrieb nicht auf.

Siehe auch:
Phantome im Active Directory

Erst beim ausführen von ADPREP /RODCPREP wird man auf diesen Fehler aufmerksam gemacht, der sich schnell und einfach beheben lässt.

Weitere Informationen:
DCDIAG: NCSecDesc Fehler
Read-Only Domain Controller (RODC)
Die Installation eines RODC
How many Infrastructure Masters do you have? >

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Phantome im Active Directory

Yusuf Dikmenoglu — Sat, 11 Jul 2009 09:17:25 GMT

Phantome im Active Directory (AD) sind nichts anderes als Referenzen auf Objekte aus anderen Domänen innerhalb der Gesamtstruktur. Wird z.B. ein Domänen-Benutzer zu einer Gruppe in einer anderen Domäne hinzugefügt, erstellt der lokale Domänencontroller (DC) der den Domänen-Benutzer zur Gruppe hinzufügt automatisch ein spezielles Objekt in der Datentabelle. Das spezielle Objekt ist das Phantomobjekt für den Domänen-Benutzer. Mit einem Phantomobjekt können DCs Verweise auf Objekte die sich in anderen Domänen innerhalb der Gesamtstruktur befinden verwalten. Im Phantomobjekt wird der ObjektGUID, ObjektSID und der Distinguished Name (DN) des neuen Gruppenmitglieds gespeichert. Durch dieses Phantomobjekt wird ein Distinguished Name Tag (DNT) bereitgestellt, das im member Attribut einer Gruppe gespeichert werden kann. Ist jedoch auf dem DC der globale Katalog (GC) aktiviert, so wird kein Phantomobjekt erstellt. Denn im GC befindet sich bereits ein Eintrag in der Datentabelle für jedes Objekt in der Gesamtstruktur. Phantomobjekte sind eine spezielle Art von internen Datenbankobjekten die einzig und alleine zum nachverfolgen dienen und lassen sich deshalb weder über die LDAP- noch ADSI-Schnittstelle anzeigen.

Die Anzahl der Phantomobjekte kann man sich mit NTDSUTIL anzeigen lassen. Führt man mit NTDSUTIL eine Analyse der AD-Datenbank mit Semantic Database Analysis durch, wird eine Datei erzeugt deren Inhalt so aussieht:

Summary:
Active Objects 9647
Phantoms 67
Deleted 2469

Der DC der die Rolle des Infrastrukturmasters innehat vergleicht regelmäßig die Einträge in seiner Datentabelle mit dem GC. Stellt dieser fest das ein Objekt umbenannt, verschoben oder gelöscht wurde, aktualisiert der Infrastrukturmaster automatisch das Phantomobjekt in der Datentabelle und repliziert die Änderung auf seine Replikationspartner innerhalb der Domäne. Wird das Quell-Objekt in eine andere Domäne verschoben, ändert sich der DN des Objekts und der Infrastrukturmaster aktualisiert automatisch den DN vom Phantomobjekt. Der Infrastrukturmaster überprüft standardmäßig alle zwei Tage die Verknüpfungsbeziehungen und kann auch Phantomobjekte entfernen, auf die sich keine Forward-Link Attribute in der Domäne mehr beziehen. Bei Bedarf kann das Intervall auf dem DC der die Rolle des Infrastrukturmasters innehat, mit Erstellen des folgenden Registryschlüssels angepasst werden:

Registrierungseintrag: Days per database Phantom scan

Type: DWORD

Standardwert: 2 Tage (der Mindestwert wäre ein Tag)

Ein Phantomobjekt wird letztendlich vom Garbage Collection Prozess der alle 12 Stunden auf jedem DC ausgeführt wird erst dann entfernt, wenn alle Verweise zum Quell-Objekt entfernt wurden.

Es könnte aber auch durchaus sein, dass ein Forward-Link Attribut auf Objekte außerhalb der eigenen Gesamtstruktur verweist (z.B. auf Objekte einer vertrauenswürdigen Domäne). In solch einem Fall wird vom AD in der Domänenverzeichnispartition ein Objekt im Container ForeignSecurityPrincipals erstellt. Dieses Objekt wird dann als Foreign Security Principal (kurz FSP) bezeichnet. In diesem FSP werden neben dem SID zusätzliche Attribute gespeichert, damit das Objekt in der vertrauenswürdigen Domäne eindeutig identifiziert werden kann. Ein Nachteil des FSP ist, das es keinen Prozess gibt damit der FSP stets aktuell bleibt (z.B. wenn das Quell-Objekt umbenannt wird). Muss ein FSP von einer System State-Sicherung wiederhergestellt werden, so wird das FSP wie jedes andere AD-Objekt behandelt.

Weitere Informationen:
Verknüpfte Attribute
Die Active Directory-Datenbank reparieren
Was passiert in der AD-Datenbank wenn ein Objekt gelöscht wird?
Phantoms, tombstones and the infrastructure master
How the Data Store Works

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Verknüpfte Attribute

Yusuf Dikmenoglu — Tue, 07 Jul 2009 12:03:50 GMT

Alle Active Directory (AD) Daten wie z.B. Benutzer-, Gruppen- oder Computerobjekte werden in der transaktionalen Datenbankdatei NTDS.DIT gespeichert, die sich standardmäßig im Verzeichnis %windir%\NTDS auf jedem Domänencontroller (DC) befindet. Die zugrundeliegende Datenbank-Engine ist die Extensible Storage Engine (ESE), die ebenfalls im Exchange und WINS-Umfeld zum Einsatz kommt. Die AD-Datenbank NTDS.DIT besteht intern aus drei Tabellen: Datentabelle (Data-Table), Verknüpfungstabelle (Link-Table) und (security descriptor) SD-Table. Die beiden elementarsten Tabellen in der sich die Daten des AD befinden ist die Datentabelle, die alle Objekte sowie Attribute enthält und die Verknüpfungstabelle, in der die Beziehungen zwischen den Objekten gespeichert werden.

Jedes AD-Objekt (z.B. Benutzer, Gruppen, Computer und Anwendungsspezifische Daten) wird zusammen mit seinem „Distinguished Name“ (DN) und einer eindeutigen Kennung in einer einzelnen Zeile, mit einer Spalte pro Attribut in der Datentabelle gespeichert. Oder anders ausgedrückt entspricht jede Zeile in der Datentabelle einem Objekt. Bei einem DC enthält die Datentabelle die Einträge aus der Schema-, Konfigurations-, Anwendungs- und Domänenpartition. Auf einem globalen Katalog (GC) enthält die Datentabelle Einträge für jedes Objekt in der Gesamtstruktur, denn alle Objekte aus allen Domänenpartitionen innerhalb der Gesamtstruktur werden mit den Attributen die für eine Suche relevant sind, in den GC repliziert.

Das AD verwendet als eindeutige Kennung das Distinguished Name Tag (DNT), um jede Zeile in der Datentabelle eindeutig zu identifizieren. Bei dem DNT handelt es sich um einen 32Bit Integer Wert und dieser wird zum internen Verweis auf Objekte verwendet. Der Distinguished Name Tag ist eine lokale Kennung der nicht zwischen den DCs repliziert wird und lautet bei jedem DC anders.

Das Verknüpfen von Objekten

Im AD existieren zwei Arten von Beziehungen die zwischen den Objekten verwaltet werden. Zum einen ist es die Beziehung zwischen den über- und untergeordneten Objekten und zum anderen ist es die Verknüpfungsbeziehung. Für die Beziehung zwischen den über- und untergeordneten Objekten speichert das AD in einer zusätzlichen Spalte innerhalb der Datentabelle den Parent Distinguished Name Tag (PDNT). In dieser Spalte wird der DNT vom übergeordneten Objekt gespeichert. >

Die Verknüpfungsbeziehung zwischen einem Verknüpfungspaar wird in der Verknüpfungstabelle gespeichert. Die Verknüpfungstabelle verwendet nur den DNT der gespeicherten Objekte, um den DN und somit das Objekt selbst ausfindig zu machen. Diese Vorgehensweise innerhalb der AD-Datenbank stellt sicher, dass die Integrität der Objekte und den jeweiligen Links gewährleistet ist.

Im AD werden alle Attribute durch ein attributeSchema-Objekt in der Schemapartition definiert, wobei diverse Attribute im AD als Verknüpfungsattribute definiert sind. Als Verknüpfungsattribute werden Attribute bestimmt, die einen geraden Wert im LinkID Attribut des attributeSchema-Objekts enthalten.

Verknüpfte Attribute (auf Englisch: Linked Attributes) stellen eine besondere Beziehung im Active Directory zueinander dar und sind Verknüpfungspaare, die aus einem Forward-Link Attribut und einem Back-Link Attribut bestehen um eine Verknüpfung zwischen zwei AD-Objekten zu erstellen.

Der Wert des Back-Link Attributs wird basierend auf dem Wert das im Forward-Link Attribut eingetragen ist berechnet. Der Wert eines Back-Link Attributs im Zielobjekt besteht aus den Distinguished Name Einträgen aller Objekte, in denen der DN des Quellobjekts im entsprechenden Forward-Link Attribut eingetragen ist.

Z.B. stellen in den Eigenschaften eines Benutzerkontos, in der Registerkarte „Organisation“ die Attribute „manager“ (Feldname: Vorgesetzter) und das Attribut „directReports“ (Feldname: Mitarbeiter) ein Verknüpfungspaar dar. Dabei handelt es sich bei dem einwertigen (single-value) Attribut „manager“ um das Forward-Link und bei dem mehrwertigen (multivalue) Attribut „directReports“ um das Back-Link Attribut.

Ein weiteres Beispiel ist die Gruppenmitgliedschaft eines Domänen-Benutzers. Das MemberOf-Attribut im Benutzerobjekt ist das Back-Link und das Member-Attribut im Gruppenobjekt das Forward-Link Attribut. Beide Attribute sind mehrwertig und stellen eine Verknüpfung zwischen dem Gruppenobjekt und seinen Benutzerobjekten dar. Denn schließlich kann ein Domänen-Benutzer Mitglied in mehreren Gruppen sein und eine Gruppe kann mehrere Domänen-Benutzer als Gruppenmitglieder enthalten. Das member Atribut im Gruppenobjekt scheint in der MMC Active Directory-Benutzer und -Computer die DNs der Mitglieder zu enthalten, aber tatsächlich werden die DNs vom AD anders gespeichert. Wird der DN eines Benutzerobjekts dem member Attribut einer Gruppe hinzugefügt, speichert das AD den DNT des Objekts und nicht den DN. Da sich der DNT selbst beim umbenennen eines Objekts nicht ändert, kann ein Benutzerobjekt umbenannt werden ohne dass das AD alle Gruppen durchsuchen muss um den DN in jedem member Attribut zu aktualisieren.

>>
>

Wird in einem Verknüpfungspaar der Wert eines Forward-Link Attributs vom Administrator verändert, aktualisiert das Active Directory automatisch das Back-Link Attribut. Das beinhaltet selbstverständlich auch das Löschen von Werten. Dabei kann lediglich der Forward-Link vom Administrator bearbeitet werden (wie z.B. das Member-Attribut eines Gruppenobjekts), der zwischen den DCs repliziert wird.

Back-Links dagegen werden von jedem DC selbst verwaltet und können auch nicht vom Administrator bearbeitet werden. Es ist ein sogenanntes system-only Attribut und wird auch nicht auf andere DCs repliziert. Ein Back-Link und sein Wert werden zum Zeitpunkt der Abfrage generiert. Solche Attribute tragen den Namen constructed.

Das LinkID Attribut im Forward-Link enthält immer einen geraden und das LinkID Attribut im verknüpften Back-Link enthält einen ungeraden Wert, nämlich den Wert „Forward-LinkID plus 1“. Beispielsweise enthält das LinkID Attribut im attributeSchema-Objekt Manager den Wert 42 und das LinkID Attribut im attributeSchema-Objekt directReports den Wert 43. Im attributeSchema-Objekt Member enthält das LinkID Attribut den Wert 2 und im attributeSchema-Objekt MemberOf enthält das LinkID Attribut den Wert 3.

Es gibt aber auch Gruppentypen die Mitglieder enthalten können, die sich in einer anderen Domäne befinden. Das AD speichert dazu ein spezielles Objekt in der Datentabelle, damit ein DNT bereitgestellt und im member Attribut der Gruppe gespeichert werden kann. Was genau das auf sich hat, wird in diesem Artikel beschrieben:

Phantome im Active Directory >

Weitere Informationen:
Die unterschiedliche Größe der AD-Datenbank
Was passiert in der AD-Datenbank wenn ein Objekt gelöscht wird?
Link-ID Attribute (Windows)
Linked Attributes (Windows)
How the Data Store Works: Active Directory

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

DCDIAG: NCSecDesc Fehler

Yusuf Dikmenoglu — Fri, 26 Jun 2009 12:05:01 GMT

Wenn das DCDIAG auf einem Windows Server 2008 oder Windows Server 2008 R2 ausgeführt wird, kann es unter Umständen zu folgendem Fehler bei dem NCSecDesc Test kommen:

Starting test: NCSecDesc
         Fehler: NT-AUTORITÄT\DOMÄNENCONTROLLER DER ORGANISATION besitzt
         keine Replicating Directory Changes In Filtered Set
         Zugriffsrechte für den Namenskontext:
         DC=DomainDnsZones,DC=Domäne,DC=TLD
         Fehler: NT-AUTORITÄT\DOMÄNENCONTROLLER DER ORGANISATION besitzt
         keine Replicating Directory Changes In Filtered Set
         Zugriffsrechte für den Namenskontext:
         DC=ForestDnsZones,DC=Domäne,DC=TLD
         .................. DCON01 hat den Test NCSecDesc nicht bestanden.

Wird ein Windows Server 2008 oder Windows Server 2008 R2 als zusätzlicher Domänencontroller (DC) zu einer Windows 2000 oder Windows Server 2003 Domäne hinzugefügt, kann es zu diesem Fehler kommen. Das DCDIAG ab Windows Server 2008 bringt bei dem NCSecDesc Test einen Fehler, wenn der Befehl ADPREP /RODCPREP nicht ausgeführt wurde.

Denn bei diesem Test wird überprüft, ob der Security Descriptor der genannten Verzeichnispartitionen, in dem Fall die beiden Anwendungsverzeichnispartitionen "DomainDNSZones" sowie "ForestDNSZones", über die entsprechenden Berechtigungen für die Replikation verfügt. Der Fehler zeigt an, dass die Gruppe NT-AUTORITÄT\DOMÄNENCONTROLLER DER ORGANISATION keine Zugriffsberechtigung auf die Replikation der Verzeichnisänderungen für die beiden DNS-Anwendungsverzeichnispartitionen besitzt.

Falls es nicht geplant ist einen Read-Only Domänencontroller (RODC) in der Gesamtstruktur zu installieren, kann dieser Fehler getrost ignoriert werden. Aber wenn es doch geplant ist einen RODC in der Gesamtstruktur zu installieren, verschwindet dieser Fehler nach dem Ausführen von ADPREP /RODCPREP. Dabei kann das ADPREP sowohl von der Windows Server 2008 DVD als auch von der Windows Server 2008 R2 DVD auf irgendeinem DC mit „Organisations-Admin“ Rechten ausgeführt werden. Denn beide ADPREP-Versionen setzen beim Ausführen des Parameters /RODCPREP die gleichen Berechtigungen in den DNS-Anwendungsverzeichnispartitionen.

Das ADPREP kontaktiert während der Ausführung alle Infrastrukturmasterrollen der einzelnen DNS-Anwendungsverzeichnispartitionen in der Gesamtstruktur und aktualisiert die Berechtigungen. Während der Durchführung von ADPREP /RODCPREP könnte es sein, dass ein Infrastrukturmaster nicht erreichbar ist. Was genau das auf sich hat, beschreibt der folgende Artikel:

Die Infrastrukturmaster der Anwendungsverzeichnispartitionen

Weitere Informationen:
Die Installation eines RODC

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Die Active Directory-Attribute hinter den Feldnamen

Yusuf Dikmenoglu — Wed, 24 Jun 2009 07:04:25 GMT

Möchte der Administrator eine LDAP-Abfrage durchführen oder eine Objektdelegierung im Active Directory (AD) einrichten, so muss er wissen welches Attribut hinter dem Feld z.B. in der MMC Active Directory-Benutzer und –Computer (dsa.msc) dahinter steckt, damit er seine Aufgabe durchführen kann.

Die Attribute die hier aufgezeigt werden beziehen sich auf die Felder in der MMC dsa.msc.

Die Attribute hinter den Feldern eines Benutzerkontos >

Die Registerkarte: Allgemein

Die Registerkarte: Adresse

Die Registerkarte: Konto

Die Registerkarte: Profil

Die Registerkarte: Rufnummern

Die Registerkarte: Organisation

Die Registerkarte: Mitglied von

Die Übersicht in der MMC "dsa.msc"

Die Attribute hinter den Feldern eines Gruppenkontos

Die Registerkarte: Allgemein

Die Registerkarte: Mitglieder

Die Registerkarte: Mitglied von

Die Registerkarte: Verwaltet von

Die Attribute hinter den Feldern einer Organisationseinheit (OU)

Die Registerkarte: Allgemein

Die Registerkarte: Verwaltet von

Die Attribute in der Registerkarte "Objekt"

Diese Registerkarte kommt in den Eingenschaften einer OU, eines Benutzer-, Gruppen- oder Computerkontos erst dann zum Vorschein, wenn im Snap-In Active Directory-Benutzer und -Computer unter Ansicht die Option Erweiterte Funktionen aktiviert wurde.

Die Attribute hinter den Feldern eines Computerkontos

Die Registerkarte: Allgemein

Die Registerkarte: Betriebssystem

Die Registerkarte: Mitglied von

Die Registerkarte: Standort

Die Attribute hinter den Feldern eines Druckers

Die Registerkarte: Allgemein

Die Attribute hinter den Feldern eines "Kontakts"

Die Registerkarte: Allgemein

Die Registerkarte: Adresse

Die Registerkarte: Rufnummern

Die Registerkarte: Organisation

Weitere Informationen:
Gespeicherte Abfragen
Active Directory - Abfrage
All Attributes (Windows)
All Classes (Windows)
Mappings for the Active Directory Users and Computers Snap-in (Windows)

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Den Eintrag „Benutzer“ aus der MMC dsa.msc entfernen

Yusuf Dikmenoglu — Fri, 19 Jun 2009 12:07:01 GMT

In vielen Unternehmen ist ein Prozess etabliert, wie und wann ein neuer Mitarbeiter im Active Directory (AD) als Benutzer erstellt wird. Viele Firmen verwenden zum erstellen eines Benutzerkontos die Standardwerkzeuge, wie die MMC Active Directory-Benutzer und -Computer (dsa.msc) das im Windows mitgeliefert wird. Andere Firmen verwenden dagegen ihre „eigenen“ Werkzeuge in Form von Dritt-Anbieter Tools, Skripten oder selbst entwickelte Tools, weil dadurch gleich beim erstellen eines Domänen-Benutzers weitere Informationen (z.B. Büro, Rufnummer, Adressinformationen etc.) dem Benutzerkonto in einem Schritt vergeben werden.

Mit einer Unternehmensrichtlinie kann man zwar festlegen, dass ein Benutzerkonto ausschließlich über das eigene Werkzeug erstellt werden soll, doch technisch gesehen kann natürlich der Administrator weiterhin über die MMC dsa.msc Benutzerkonten erstellen.

Das kann man jedoch wie folgt unterbinden:

Dazu ruft man zuerst das ADSIEdit.msc auf, das sich unter Windows 2000 und Windows Server 2003 in den Windows Support Tools befindet und ab Windows Server 2008 bereits im Betriebssystem integriert ist und verbindet sich mit der Schemapartition.
Dann gilt es in den Eigenschaften des Objekts CN=User den Wert des Attributs defaulthidingvalue auf TRUE (Wahr) zu setzen. Ändert man stattdessen das Attribut im Objekt CN=Group, so lassen sich keine Gruppen mehr in der MMC dsa.msc erstellen.
Anschließend steht der Eintrag „Benutzer“ unter „Neu“ nicht mehr zur Verfügung.

Da diese Änderung in der Schemapartition durchgeführt und auf alle DCs in der Gesamtstruktur repliziert wird, betrifft das alle Domänen in der Gesamtstruktur.

Natürlich ist es aber über andere grafische Tools oder mit Kommandozeilentools wie z.B. DSADD weiterhin möglich Benutzer im AD zu erstellen. Diese Änderung betrifft ausschließlich die MMC Active Directory-Benutzer und -Computer.

Weitere Informationen:
Eigene Spalten in ADBuC integrieren

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008

Yusuf Dikmenoglu — Thu, 11 Jun 2009 08:41:04 GMT

Microsoft stellt das Active Directory Management Gateway Service (AD MGS) für Windows Server 2003 und Windows Server 2008 als separaten Download zur Verfügung.

Wenn das AD MGS installiert ist, stellt es die gleichen Funktionen zur Verfügung wie die Active Directory Web Services (ADWS) unter Windows Server 2008 R2.
Das AD MGS ist das AD-Web Services für Windows Server 2003 und Windows Server 2008.

Die Installationsvoraussetzungen für das AD MGS wären:

Auf dem Server muss das Active Directory bzw. Active Directory Domain Services oder eine Active Directory Lightweight Directory Service-Instanz (AD LDS) installiert sein.

>
Das AD MGS lässt sich ausschließlich auf Windows Server 2003 SP2, Windows Server 2003 R2 SP2 und auf Windows Server 2008 SP1 (oder höher) installieren.
Jedoch wird das AD MGS nicht auf der Installationsvariante Server Core unter Windows Server 2008 unterstützt.
Das .NET-Framework 3.5 Service Pack 1 muss unter Windows Server 2003 SP2/2003 R2 SP2 und Windows Server 2008 SP1/SP2 installiert sein.
Ist das .NET-Framework 3.5 Service Pack 1 auf dem DC installiert, muss anschließend unter Windows Server 2003 SP2/2003 R2 SP2 und
Windows Server 2008 SP1/SP2 noch zwingend dieser Hotfix installiert werden:

A hotfix rollup package for Active Directory Web Service is available for the .NET Framework 3.5 SP1
Auf einem Windows Server 2003 SP2/2003 R2 SP2 DC muss dann noch dieser Hotfix installiert werden:

Windows 7 clients cannot locate the Active Directory Management Gateway service that is installed on Windows Server 2003-based domain controllers
Auf einem Windows Server 2008 SP1 DC muss dieser Hotfix zusätzlich noch installiert werden:

Windows 7 clients cannot locate the Active Directory Management Gateway Service installed on Windows Server 2008-based domain controllers

Auf einem Windows Server 2008 SP2 DC wird der Hotfix nicht benötigt!

Nach der Installation des AD MGS kann ein Windows Server 2003 DC oder Windows Server 2008 DC über die AD-Powershell und
Active Directory Administrative Center (ADAC) von einem Windows 7 Client oder Windows Server 2008 R2 Mitgliedsserver bzw. DC administriert werden.

Das AD MGS steht hier zum Download zur Verfügung:

Active Directory Management Gateway Service (Active Directory Web Service for Windows Server 2003 and Windows Server 2008)

Weitere Informationen:
The Active Directory Management Gateway Service is now available
Neues in den AD DS: Active Directory-Webdienste
Die AD-Powershell im Windows Server 2008 R2
Das Active Directory-Verwaltungscenter
>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Den Domänen- und Gesamtstrukturfunktionsmodus zurückstufen

Yusuf Dikmenoglu — Sat, 06 Jun 2009 06:00:35 GMT

Wurde bis einschließlich Windows Server 2008 der Domänen- oder Gesamtstrukturfunktionsmodus z.B. von „Windows Server 2003“ auf „Windows Server 2008“ hochgestuft, ist es nicht möglich weder den Domänen- noch Gesamtstrukturfunktionsmodus zurückzustufen. Die einzige Möglichkeit wäre ein Forest-Recovery durchzuführen. Denn das Heraufstufen des Domänen- bzw. Gesamtstrukturfunktionsmodus ist ein irreversibler Vorgang.

Unter Windows Server 2008 R2 ist nun das zurückstufen in einen bestimmten Domänen- sowie Gesamtstrukturfunktionsmodus unter gewissen Voraussetzungen möglich.

Die Funktionsebenen bestimmen zum einen die zur Verfügung stehenden Active Directory-Funktionen innerhalb der Domäne sowie Gesamtstruktur und zum anderen werden die Betriebssystemversionen beschränkt, die auf Domänencontrollern (DCs) ausgeführt werden können.

Weitere Informationen über die Funktionsebenen liefert der folgende Artikel:

Domänen- und Gesamtstrukturfunktionsmodus

Den Domänenfunktionsmodus zurückstufen

Der Domänenfunktionsmodus lässt sich unter bestimmten Voraussetzungen wie folgt zurückstufen:

Der aktuelle Domänenfunktionsmodus muss sich auf „Windows Server 2008 R2“ befinden.
Der Domänenfunktionsmodus lässt sich ausschließlich auf „Windows Server 2008“ zurückstufen. Ein zurückstufen auf „Windows Server 2003“ oder früher ist unter keinen Umständen möglich.
Der Gesamtstrukturfunktionsmodus muss den Domänenfunktionsmodus auf den die entsprechende Domäne zurückgestuft werden soll (also auf „Windows Server 2008“) unterstützen. Das bedeutet, befindet sich der Gesamtstrukturfunktionsmodus auf „Windows Server 2008 R2“, so kann die Domäne nicht auf „Windows Server 2008“ zurückgestuft werden, da der Gesamtstrukturfunktionsmodus nur „Windows Server 2008 R2“ Domänen innerhalb der Gesamtstruktur unterstützt.
Der Gesamtstrukturfunktionsmodus muss sich also auf Windows 2000, Windows Server 2003 oder Windows Server 2008 befinden.
Der Domänenfunktionsmodus kann zum einen in der AD-Powershell mit dem Commandlet Set-ADDomainMode und zum anderen, mit dem Attribut-Editor in der MMC Active Directory-Benutzer und -Computer (dsa.msc) oder ADSIEdit zurückgestuft werden.
Unter Start-Verwaltung gilt es das Active Directory Module for Windows Powershell zu starten. Danach kann mit diesem AD Powershell-Befehl der Domänenfunktionsmodus zurückgestuft werden:
Set-ADDomainMode <FQDN der Domäne> -DomainMode Windows2008Domain
Anschließend muss die Aktion mit einem „J“ bestätigt werden.
Leider erscheint in der AD-Powershell keine Meldung das die Aktion durchgeführt wurde. Es wird aber im Verzeichnisdienstprotokoll des DCs die EventID 2039 protokolliert in der bestätigt wird, dass die Neue Domänenfunktionsebene:3 lautet.
Die Zahl „3“ gibt den Wert im Attribut msDS-Behavior-Version an, das sich in der Domänenpartition in den Eigenschaften des Containers <DC=Domäne,DC=TLD> befindet.

Folgende Werte können im Attribut msDS-Behavior-Version eingetragen sein:
0 = Domänenfunktionsmodus: Windows 2000 gemischt und Windows 2000 pur
1 = Domänenfunktions: Windows Server 2003 Interim
2 = Domänenfunktionsebene: Windows Server 2003
3 = Domänenfunktionsebene: Windows Server 2008
4 = Domänenfunktionsebene: Windows Server 2008 R2
Mit dem Attribut-Editor in der MMC Active Directory-Benutzer und -Computer (dsa.msc) oder ADSIEdit lässt sich der Domänenfunktionsmodus ebenfalls zurückstufen. In der MMC dsa.msc gilt es zuerst unter Ansicht die Erweiterte Features zu aktivieren. Anschließend ruft man mit einem Rechtsklick auf den Domänennamen die Eigenschaften auf und wechselt zum Reiter Attribut-Editor. Dort angelangt, ändert man den Wert im Attribut msDS-Behavior-Version von 4 auf 3. Mit ADSIEdit ist die Vorgehensweise ähnlich. Nach dem Aufruf von ADSIEdit stellt man im ersten Schritt eine Verbindung mit der Domänenpartition (Standardmäßiger Namenskontext) her und ändert im zweiten, den Wert im Attribut msDS-Behavior-Version von 4 auf 3.
Der Domänenfunktionsmodus kann natürlich auch in der MMC Active Directory-Benutzer und -Computer (dsa.msc) und Active Directory-Domänen und -Vertrauensstellungen (domain.msc) überprüft werden.
In der AD-Powershell lässt sich der DomainMode mit dem Cmdlet Get-ADDomain verifizieren.

Den Gesamtstrukturfunktionsmodus zurückstufen

Der Gesamtstrukturfunktionsmodus lässt sich unter gewissen Voraussetzungen wie folgt zurückstufen:

Der aktuelle Gesamtstrukturfunktionsmodus muss sich auf „Windows Server 2008 R2“ befinden.
Der Gesamtstrukturfunktionsmodus kann wie der Domänenfunktionsmodus nur auf „Windows Server 2008“ zurückgestuft werden.
Optionale Funktionen die nicht mehr deaktiviert werden können, wie der AD-Papierkorb, dürfen nicht aktiviert sein. Zukünftige optionale Funktionen die deaktiviert werden können, lassen sich mit dem AD-Powershell Cmdlet Disable-ADOptionalFeature deaktivieren.
Das zurückstufen erfolgt entweder in der AD-Powershell mit dem Cmdlet Set-ADForestMode oder mit ADSIEdit.
In dem Active Directory Module for Windows Powershell muss zum zurückstufen des Gesamtstrukturfunktionsmodus dieser Befehl eingegeben werden:
Set-ADForestMode <FQDN der Root-Domäne> -ForestMode Windows2008Forest
Der Vorgang ist mit einem „J“ zu bestätigen.
Danach wird im Verzeichnisdienstprotokoll des DCs die EventID 2040 protokolliert mit der Beschreibung, dass die Neue Gesamtstrukturfunktionsebene:3 lautet.
Auch hier ist mit der Zahl „3“ der Wert im Attribut msDS-Behavior-Version gemeint, das sich in den Eigenschaften des Containers
<CN=Partitions,CN=Configuration,DC=Root-Domäne,DC=TLD> befindet.

Die Werte die im Attribut msDS-Behavior-Version eingetragen werden können sind:

0 = Gesamtstrukturfunktionsebene: Windows 2000
1 = Gesamtstrukturfunktionsebene: Windows Server 2003 Interim
2 = Gesamtstrukturfunktionsebene: Windows Server 2003
3 = Gesamtstrukturfunktionsebene: Windows Server 2008
4 = Gesamtstrukturfunktionsebene: Windows Server 2008 R2
Mit ADSIEdit ist zuerst eine Verbindung mit der Konfigurationspartition herzustellen. Anschließend muss der Wert im Attribut msDS-Behavior-Version das sich in den Eigenschaften des Containers <CN=Partitions,CN=Configuration,DC=Root-Domäne,DC=TLD> befindet, von 4 auf 3 geändert werden.
>
Außerdem kann man den Gesamtstrukturfunktionsmodus in der MMC Active Directory-Domänen und -Vertrauensstellungen (domain.msc) kontrollieren.

>
In der AD-Powershell lässt sich der ForestMode mit dem Cmdlet Get-ADForest überprüfen.

Weitere Informationen:
Der Active Directory-Papierkorb im Windows Server 2008 R2
Die AD-Powershell im Windows Server 2008 R2
>>>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Offline zur Domäne beitreten

Yusuf Dikmenoglu — Sun, 24 May 2009 07:12:45 GMT

Eine weitere Neuheit die ab Windows Server 2008 R2 und Windows 7 eingeführt wird, ist die Möglichkeit einen Computer mit Windows Server 2008 R2 oder Windows 7 zur Domäne hinzuzufügen, ohne das die Maschine eine Verbindung zum Netzwerk hat (Offline Domain join). Diese neue Funktion kann ausschließlich ab Windows Server 2008 R2 und Windows 7 eingesetzt werden. Damit ist es möglich an entfernten Standorten die noch keine Anbindung ans Unternehmensnetzwerk haben Windows Server 2008 R2 Mitgliedserver und Windows 7 Clients zur Domäne hinzuzufügen.

Eine weitere Einsatzmöglichkeit für diese Funktion wäre, dass bereits die bestellten Windows 7 Clients direkt vom PC-Lieferanten vorinstalliert und zur Domäne hinzugefügt werden.

Oder bei der Massenanfertigung von virtuellen Maschinen können direkt nach der Betriebssysteminstallation die VMs zur Domäne hinzugefügt werden. Das ganze hat sogar den Vorteil, dass dadurch ein Neustart erspart bleibt der sonst nach dem Hinzufügen einer VM zur Domäne notwendig wäre.

Auch mit Deployment Tools, wie z.B. dem Windows-System-Image Manager (SIM) der Bestandteil des Windows Automated Installation Kit (WAIK) ist, können bereits während der unbeaufsichtigten (unattended) Installation eines Windows Server 2008 R2 und Windows 7 die Systeme zur Domäne hinzugefügt werden. Das ist möglich durch das Bereitstellen der relevanten Daten in der Unattend.xml-Datei, die für das offline domain join notwendig sind. Die Unattend.xml-Datei für Windows Server 2008 R2 und Windows 7 muss um einen weiteren Abschnitt erweitert werden, damit das Hinzufügen zur Domäne bereits während der Betriebssysteminstallation vonstattengehen kann.

Diese neue Funktion ist Dank einem neuen Kommandozeilentool Namens Djoin.exe möglich, dass nur ab Windows Server 2008 R2 und Windows 7 „on Bord“ ist. Mit diesem Kommandozeilentool lässt sich auch der sichere Kanal zwischen einem Windows Server 2008 R2 Mitgliedserver oder Windows 7 Client und einem Domänencontroller zurücksetzen.

Wie üblich bei den Windows-Kommandozeilentools lässt sich mit dem Befehl djoin /? die Hilfe aufrufen, worin die einzelnen Parameter beschrieben werden.

Einen Windows Server 2008 R2 oder Windows 7 offline zur Domäne hinzufügen

Im ersten Schritt muss von einem Windows Server 2008 R2 (DC oder Mitgliedserver) oder Windows 7 das Computerkonto im AD erstellt werden. Dabei wird eine Textdatei generiert, die lokal auf dem zu hinzuzufügenden Windows Server 2008 R2 oder Windows 7 benötigt wird. Diesen Vorgang bezeichnet man auch als bereitgestellte Installation oder auf englisch provision computer account.

Bei der bereitgestellten Installation wird das Computerkonto im AD standardmäßig im Container Computers erstellt. Der Befehl lautet so:
Djoin.exe /provision /domain <Domänenname> /machine <Computername> /savefile <blob.txt>

>
Soll stattdessen das Computerkonto in einer OU erstellt werden, so müsste der folgende Befehl ausgeführt werden:
Djoin.exe /provision /domain <Domänenname> /machine <Computername> /machineou <DN der OU> /savefile <blob.txt>
Standardmäßig wird mit Ausführen von Djoin.exe das Computerkonto im AD von einem Windows Server 2008 R2 DC erstellt. Durch die Angabe des Parameters /downlevel kann das Computerkonto von einem DC älter als Windows Server 2008 R2 bzw. in einer Windows 2000, Windows Server 2003 oder Windows Server 2008 Domäne erstellt werden:
Djoin.exe /provision /domain <Domänenname> /machine <Computername> /downlevel /savefile <blob.txt>
Der mit diesem Befehl erstellte Base64-codierte Metadaten-Blob (Binary Large Object, die Textdatei) enthält sehr sensible Daten. Diese Datei sollte verständlicherweise sicher aufbewahrt werden, denn in dem Blob ist z.B. das Computerkontokennwort, Informationen über die Domäne einschließlich des Domänennamens, der Name eines Domänencontroller und der Security Identifier (SID) der Domäne enthalten. Daher muss zwingend darauf geachtet werden, dass wenn diese Datei physikalisch (über den Postweg) oder über das Netzwerk transportiert wird, die Sicherheit jederzeit gewährleistet ist und diese Datei nicht in fremde Hände gelangt.

Der Blob sieht wie folgt aus:
Im zweiten Schritt muss auf dem Windows Server 2008 R2 oder Windows 7 der zur Domäne hinzugefügt werden soll, der folgende Befehl in einer Kommandozeile eingegeben werden. Dabei ist es zwingend, dass die CMD explizit als Administrator gestartet wird:
Djoin.exe /requestodj /loadfile <Pfad zur blob.txt> /windowspath %windir% /localos
Zum Schluss ist ein Neustart fällig. Anschließend kann der Rechner ans Netzwerk verkabelt werden und befindet sich automatisch in der Domäne.
Mit type blob.txt bekommt man die Datei in der Kommandozeile angezeigt.

Welche Rechte werden benötigt?

Für diese Funktion werden Domänen-Admin Rechte benötigt oder den entsprechenden Personen wurde das Recht Hinzufügen von Arbeitsstationen zur Domäne über die Gruppenrichtlinie erteilt. Besser wäre es jedoch dieses Recht per Objektdelegierung an die jeweiligen Personen zu delegieren.>>>

Clients in die Domäne hinzufügen

Wird eine Logdatei erstellt?

Wenn ein Fehler beim ausführen von Djoin.exe auftritt, erhält man in der Protokolldatei %windir%\debug\netsetup.log weitere Informationen.

Beitreten zur Domäne während einer unbeaufsichtigten Betriebssysteminstallation

Für das Beitreten zur Domäne während der Betriebssysteminstallation muss zuerst mit Djoin.exe das Computerkonto im AD und vor allem der Base64-codierte Metadaten-Blob generiert werden. Anschließend gilt es die Unattend.xml Datei zu erzeugen und einen neuen Abschnitt in der XML zu erstellen. Der Abschnitt sieht folgendermaßen aus:

<Component>
<Component name=Microsoft-Windows-UnattendedJoin>
<Identification>
<Provisioning>
<AccountData>Inhalt des Base64codierten Metadaten-Blob</AccountData>
</Provisioning>
</Identification>
</Component>

Nach dem fertigstellen der Unattended.xml Datei gilt es den Computer der zur Domäne hinzugefügt werden soll im Windows PE (Windows Preinstallation Environment) zu starten. Danach muss das Setup mit der Angabe der Antwortdatei ausgeführt werden:

Setup /unattend:<Pfad zur Unattended.xml>

Den sicheren Kanal (secure channel) mit Djoin.exe zurücksetzen

Wenn der sichere Kanal zwischen einem Windows Server 2008 R2 Mitgliedserver oder Windows 7 Client und einem Domänencontroller nicht mehr funktioniert, entsteht ein typisches Authentifizierungsproblem. Die Lösung für dieses Problem wäre entweder NLTEST auszuführen NLTEST /SC_RESET (NLTEST befindet sich in den Windows Support Tools und ist ab Windows Server 2008 bereits on Bord) oder die Maschine aus der Domäne zu entfernen und erneut hinzuzufügen.

Dieses Problem lässt sich nun auch mit Djoin.exe lösen. Dazu muss man sich entweder an dem betroffenen Windows Server 2008 R2 Mitgliedserver oder Windows 7 Client mit zwischengespeicherten Anmeldeinformationen oder an einem nicht betroffenen Windows Server 2008 R2 Mitgliedserver oder Windows 7 anmelden.>>

Als Erstes muss eine Eingabeaufforderung mit erhöhten Rechten (Start-Alle Programme-Zubehör-Eingabeaufforderung, Rechtsklick --> Als Administrator ausführen) gestartet werden. Danach gilt es diesen Befehl einzugeben:
Djoin.exe /provision /domain <Domänenname> /reuse /machine <betroffener Computername> /savefile C:\blob.txt >
Steht kein Windows Server 2008 R2 DC zur Verfügung, so muss der Parameter /downlevel mit angegeben werden:
Djoin.exe /provision /domain <Domänenname> /reuse /machine <betroffener Computername> /downlevel /savefile C:\blob.txt
Wurde der Befehl auf einem nicht betroffenen System ausgeführt, muss der Blob auf das betroffene System kopiert werden.
Auf dem betroffenen System gilt es anschließend diesen Befehl, ebenfalls in einer CMD mit erhöhten Rechten auszuführen:
Djoin.exe /requestodj /loadfile <Pfad zur blob.txt> /windowspath %windir% /localos
Zum Abschluss muss der Windows Server 2008 R2 oder Windows 7 neu gestartet werden.
Danach sollte der sichere Kanal mit dem folgenden Befehl überprüft werden:
NLTEST /sc_verify:Domäne.TLD

Hinweis zum Parameter /downlevel

Das Kommandozeilentool Djoin.exe im Windows Server 2008 R2 und Windows 7 verwendet in erster Linie das LDAP-Protokoll um das Computerkonto im AD zu erstellen, was von früheren Betriebssystemversionen so nicht unterstützt wird. Wenn der Parameter /downlevel angegeben wird, wird das SAM-Protokoll verwendet falls das Erstellen des Computerkontos mit dem LDAP-Protokoll fehlschlagen sollte. Daher ist der Parameter /downlevel nur dann erforderlich, wenn kein Windows Server 2008 R2 DC in der Domäne existiert. Denn bei dem Parameter /downlevel wird die SE_MACHINE_ACCOUNT_PRIVILEGE-Berechtigung angewendet, anstatt die direkt auf dem Container erteilten Berechtigungen.>>>>>>

Weitere Informationen:
You cannot join a Windows 7 Beta-based or a Windows Server 2008 R2 Beta-based computer to an existing domain, and you receive an error message: "The parameter is incorrect"

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Die unterschiedliche Größe der AD-Datenbank

Yusuf Dikmenoglu — Sun, 26 Apr 2009 05:55:33 GMT

Das Active Directory (AD) speichert seine Daten bekanntermaßen in einer Datenbank. Das Herzstück des AD ist die Datenbankdatei, die standardmäßig im Verzeichnis %windir%\NTDS\ gespeichert wird. Diese transaktionale Datenbank und die zugehörige Datenbank-Engine „Extensible Storage Engine (ESE)“, trägt den Namen NTDS.DIT. Dabei steht das „NTDS“ für New Technology Directory Services und das „DIT“ für Directory Information Tree.

Jeder Domänencontroller (DC) in einer Einzel- und Multidomänen-Gesamtstruktur hält seine eigene Kopie dieser AD-Datenbank (NTDS.dit), die kontinuierlich durch lokale Änderungen und durch die Replikationspartner aktualisiert wird. Die AD-Datenbank verändert sich in der Größe zum einen durch die lokalen Änderungen auf dem DC selbst und zum anderen durch die Änderungen die von den Replikationspartnern repliziert werden. Es ist zwingend notwendig, dass die AD-Daten konsistent zwischen den DCs durch die AD-Replikation gehalten werden. Aber die AD-Datenbankdatei ist ohnehin nie bis auf das letzte Bit zwischen mehreren DCs identisch.

Es gibt AD-Daten, die nicht zwischen den DCs repliziert werden. Denn z.B. werden die Indizes die eine performante LDAP-Suche ermöglichen lokal auf jedem DC erstellt. Dies kann bereits zu einem gewissen Maß an Größenunterschied in jeder AD-Datenbankdatei führen. Das einzige was repliziert wird ist die Anweisung, dass ein Attribut im AD indiziert werden soll. Wird in den Eigenschaften eines Attributs im Schema Snap-In die Option Attribut in Active Directory indizieren markiert, repliziert sich diese Änderung bei der nächsten Replikation der Schemapartition auf alle DCs in der Gesamtstruktur.

Die Gründe warum auf zwei DCs die AD-Datenbank unterschiedlich groß ist, sind:

Der Whitespace oder zu Deutsch: Der freie Speicherplatz in der AD-Datenbank. Dies trifft dann zu, wenn ein weiterer DC zur Domäne hinzugefügt wird. Wenn ein Server als zusätzlicher DC zu einer Domäne hinzugefügt wird kann es durchaus sein, das die AD-Datenbank des neuen DCs wesentlich kleiner ist als auf den bestehenden DCs. Das ist dann ein klares Indiz für den Whitespace der in der AD-Datenbank auf den bestehenden DCs existiert. Denn wird ein weiterer DC zur Domäne hinzugefügt, wird selbstverständlich nur die Nettokapazität der AD-Datenbank auf den neuen DC repliziert und nicht zusätzlich der unnötige Whitespace.
AD-Replikationsprobleme. Bestehen auf einem DC Replikationsprobleme, sei es mit einer oder mit allen Verzeichnispartitionen, bekommt dieser keine Aktualisierungen von seinen Replikationspartnern mehr mit.
In einer Multidomänen-Gesamtstruktur ist auf einem DC der globale Katalog (GC) aktiviert und auf dem anderen nicht. Oder auf einem DC wurde der GC „unbemerkt“ deaktiviert.

Die Ursachen in der Praxis sind in der Regel der Whitespace und AD-Replikationsprobleme, die den Unterschied zwischen den AD-Datenbankdateien ausmachen.

Der Whitespace in der AD-Datenbank

Der Whitespace in der AD-Datenbank entsteht folgendermaßen.

Wenn ein AD-Objekt gelöscht wird, verschwindet es nicht sofort aus der AD-Datenbank. Das AD markiert das Objekt als gelöscht, indem das Attribut Is-Deleted des Objekts auf TRUE gesetzt wird. Dabei werden von dem Objekt die meisten Attribute für immer entfernt und wandert anschließend in den Container „Deleted Objects“ (der in fast allen Verzeichnispartitionen existiert). Ab diesem Zeitpunkt wird das gelöschte Objekt als Tombstone (zu deutsch: Grabstein) bezeichnet.

Die gelöschten Objekte bleiben nun so lange im Container „Deleted Objects“ und somit in der AD-Datenbank erhalten, bis die Tombstone-Lifetime (TSL) abgelaufen ist. Erst wenn ein gelöschtes Objekt die TSL überschritten hat wird es endgültig vom Garbage Collection Prozess aus der AD-Datenbank entfernt. Der Garbage Collection Prozess läuft standardmäßig im 12-Stunden-Takt auf jedem DC in der Gesamtstruktur. Die Zeit lässt sich zwar verändern, jedoch ist das beim täglichen Betrieb nicht notwendig.

Ändern könnte man die Zeit durch das Attribut garbageCollPeriod, welches sich in den Eigenschaften des folgenden Containers befindet (die Angabe der Zeit muss in Stunden erfolgen):
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne

>

Wenn die Objekte unwiderruflich aus dem AD entfernt wurden, entsteht freier Speicherplatz (der sogenannte Whitespace) in der AD-Datenbank. Die Datenbankseiten auf denen die Objekte gespeichert waren, werden als frei markiert. Physikalisch wird aber dadurch die AD-Datenbank auf der Festplatte nicht kleiner. Stattdessen werden beim Hinzufügen neuer AD-Objekte diese auf den freien Datenbankseiten geschrieben, ohne dabei eine Speicheroptimierung bei späteren Abfragen dieser Objekte zu berücksichtigen. Durch das wiederbeschreiben der freien Datenbankseiten wird die Gesamtgröße der AD-Datenbank nicht größer. Zwar findet standardmäßig alle 12-Stunden durch den Garbage Collection Prozess auf jedem DC eine Onlinedefragmentierung der AD-Datenbank im laufenden Betrieb statt, jedoch wird dabei die AD-Datenbank ebenfalls nicht kleiner. Ob die Onlinedefragmentierung zweimal am Tag auch wirklich stattfindet, kann im Verzeichnisdienstprotokoll auf jedem DC kontrolliert werden. Denn beim Starten der Onlinedefragmentierung wird die EventID 700 und wenn sie abgeschlossen wurde, die EventID 701 protokolliert.

Bei der Onlinedefragmentierung werden lediglich die leeren Datenbankseiten neu angeordnet um einen zusammenhängenden freien Speicherplatz in der AD-Datenbank zu schaffen. Somit wird die durch die endgültige Löschung der AD-Objekte bedingte Fragmentierung der AD-Datenbank beseitigt und dadurch der Zugriff auf das AD optimiert bzw. beschleunigt. Bei den heutigen Festplattenpreisen ist es aber auch keineswegs tragisch das die AD-Datenbank physikalisch nicht kleiner wird. Dennoch ist es aus Performancegründen empfehlenswert, dass die AD-Datenbank „nur“ so groß ist, damit sie noch in den Arbeitsspeicher des DCs geladen werden kann.

Wie viel freier Speicherplatz in der AD-Datenbank tatsächlich existiert, kann durch eine Registry-Einstellung herausgefunden werden. Dazu gilt es im folgenden Registry-Schlüssel diese Einstellung vorzunehmen:

HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics
"6 Garbage Collection" = 1 (REG_DWORD)>>

Anschließend wird beim nächsten Durchlauf des Garbage Collection Prozesses, im Verzeichnisdienstprotokoll des DCs die EventID 1646 protokolliert. In dem Eintrag wird der freie Speicherplatz neben der Gesamtgröße der AD-Datenbank angegeben.

Es reicht in der Regel aus diese Registry-Einstellung nur auf einem DC in der Domäne zu konfigurieren, da sicherlich der freie Speicherplatz auf allen bestehenden DCs (bei gleicher DC Konfiguration) gleich ist.

Eine andere Variante mit der man sich einen tieferen Einblick über die Größe des freien Speicherplatzes in Form von leeren Datenbankseiten sogar der einzelnen Indizes in der AD-Datenbank verschaffen kann, wäre mit Esentutl. Dazu muss jedoch das AD offline sein. Bis einschließlich Windows Server 2003 muss hierzu der DC im Modus Verzeichnisdienstwiederherstellung gestartet werden. Unter Windows Server 2008 lässt sich dagegen der Dienst Active Directory-Domänendienste samt den abhängigen Diensten im laufenden Betrieb mit dem Kommandozeilenbefehl net stop ntds /y anhalten. Danach wird mit dem Befehl Esentutl /ms <Pfad zur Ntds.dit> oder durch das Aufrufen von Esentutl aus dem NTDS-Verzeichnis C:\Windows\NTDS>Esentutl /ms ein detaillierter Auszug der Ntds.dit erstellt. Es ist auch möglich die AD-Datenbank aus einer System State-Sicherung an einer alternativen Stelle wiederherzustellen, um diese AD-Datenbank zum überprüfen des freien Speicherplatzes zu nutzen. In der AD-Datenbank wird jede Tabelle zusammen mit der Anzahl der Datenbankseiten die es besitzt, samt der Anzahl der leeren Datenbankseiten die zur Verfügung stehen aufgelistet.

Damit die AD-Datenbank physikalisch kleiner wird, ist eine Offlinedefragmentierung notwendig. Natürlich müsste die Offlinedefragmentierung auf jedem DC erfolgen, damit die AD-Datenbank auf jedem DC auch physikalisch kleiner wird. Aber in den allermeisten AD-Umgebungen ist eine Offlinedefragmentierung nicht nötig. Wobei es jedoch in größeren AD-Gesamtstrukturen wiederum des Öfteren notwendig sein kann, eine Offlinedefragmentierung durchzuführen.

Wann ist eine Offlinedefragmentierung empfehlenswert?

Nach einer größeren Löschaktion im AD ist es empfehlenswert, wenn nach Ablauf der Tombstone-Lifetime die gelöschten Objekte endgültig aus der AD-Datenbank entfernt wurden, eine Offlinedefragmentierung der AD-Datenbankdatei durchzuführen.
In einer Multidomänen-Gesamtstruktur ist es ratsam, nach der Deaktivierung des globalen Katalogs auf einem DC eine Offlinedefragmentierung der AD-Datenbank durchzuführen.
Des Weiteren ist nach einem Inplace-Update eines Windows 2000 DCs auf Windows Server 2003/2008 eine Offlinedefragmentierung empfehlenswert. Nach einem Inplace-Update von Windows 2000 entsteht in der AD-Datenbankdatei eine erhebliche Menge an freiem Speicherplatz. Das ist aufgrund einer Verbesserung ab Windows Server 2003 möglich, worin eindeutige „security descriptors“ nur einmal (Single Instance Store) und nicht jedes Mal wenn sie verwendet werden in der AD-Datenbank gespeichert werden.
Wenn die DNS-Daten aus der Domänenpartition in die Anwendungsverzeichnispartitionen (DomainDNSZones und ForestDNSZones) umgezogen werden, wie es z.B. nach einer Domänenaktualisierung von einer Windows 2000 Domäne zu einer Windows Server 2003 bzw. Windows Server 2008 Domäne der Fall sein könnte, entsteht ebenfalls freier Speicherplatz in der AD-Datenbank (genauer in der Domänenpartition). Die Größe der AD-Datenbank lässt sich dann mit einer Offlinedefragmentierung verkleinern.

Die Größe unter anderem der AD-Datenbank kann man sich mit dem folgenden Befehl anzeigen lassen:
FOR /f %i IN ('Dsquery Server -Domain %userdnsdomain% -o Rdn') DO dir \\%i\Admin$\NTDS

Eine Offlinedefragmentierung durchführen

Die Gesamtgröße der AD-Datenbank wird ausschließlich nur durch eine Offlinedefragmentierung verringert. Diese sollte beim Entfernen einer größeren Anzahl an AD-Objekten, nach dem Entfernen eines globalen Katalogs in einer Multidomänen-Gesamtstruktur, nach einem Inplace-Update eines Windows 2000 DCs auf Windows Server 2003/2003R2/2008 und nach dem Umzug der DNS-Daten aus der Domänenpartition in die Anwendungsverzeichnispartition durchgeführt werden.

Die Offlinedefragmentierung wird folgendermaßen durchgeführt:

Zuerst sollte eine System State-Sicherung des DCs durchgeführt werden.

Damit eine Offlinedefragmentierung der AD-Datenbank auf einem DC durchgeführt werden kann, muss unter Windows 2000 und Windows Server 2003 der DC im Modus Verzeichnisdienstwiederherstellung gestartet werden. In diesen Modus gelangt man, wenn während der Bootphase des DCs die F8-Taste betätigt und die Option „Verzeichnisdienstwiederherstellung“ ausgewählt wird.

Ab Windows Server 2008 ist das Starten im Modus „Verzeichnisdienstwiederherstellung“ nicht notwendig (was aber möglich wäre). Ab einem Windows Server 2008 DC kann der Dienst Active Directory-Domänendienste im laufenden Betrieb entweder in der Dienstesteuerung (services.msc) oder in der Kommandozeile mit dem Befehl net stop ntds /y samt den abhängigen Diensten angehalten werden.

Active Directory-Domänendienste (AD-DS)

In der Eingabeaufforderung oder unter „Start-Ausführen“ gilt es das NTDSUTIL aufzurufen.

Ab Windows Server 2008 muss als erstes mit dem Befehl Activate Instance NTDS die NTDS-Instanz aktiviert werden. Unter Windows 2000 und Windows Server 2003/2003R2 muss dieser Schritt übersprungen werden.

Als nächstes gilt es den Befehl Files einzugeben.

In der „file maintenance“ Ebene werden mit dem Befehl info die aktuellen Informationen über den Pfad und der Größe der AD-Datenbank sowie der zugehörigen Protokolldateien angezeigt. Der Pfad zur AD-Datenbankdatei sollte notiert werden (zumindest sollte man ihn sich merken).

Mit dem Befehl compact to <Laufwerk>:\<Verzeichnis> wird eine neue, komprimierte AD-Datenbankdatei im angegebenen Verzeichnis erstellt. Es sollte ein Laufwerk und Verzeichnis an dem ausreichend Speicherplatz zur Verfügung steht ausgewählt werden, um die komprimierte neue AD-Datenbankdatei Ntds.dit zu speichern. Falls im Namen des Verzeichnispfads Leerzeichen enthalten sind, muss der Pfad in Anführungszeichen stehen. Z.B. compact to "C:\Neu NTDS".

Sobald die Offlinedefragmentierung abgeschlossen ist, gilt es mit der zweimaligen Eingabe von quit das NTDSUTIL zu verlassen.

Nun muss die neu erstellte defragmentierte Datenbankdatei "Ntds.dit" über die alte Datei "Ntds.dit" im aktuellen Pfad zur Active Directory-Datenbank (der in Schritt vier notiert bzw. gemerkt wurde), kopiert werden. Anschließend sind noch die alten Protokolldateien (*.log) zu löschen.

Das Kopieren der Datenbankdatei kann auch über die Kommandozeile mit folgendem Befehl erfolgen: Copy „C:\Neu NTDS\Ntds.dit“ „C:\Windows\NTDS\Ntds.dit“
Die darauffolgende Sicherheitsabfrage muss mit einem „j“ bestätigt werden.

Die alten Protokolldateien können in der Kommandozeile mit diesem Befehl gelöscht werden:
Del „C:\Windows\NTDS\*.log“

Danach gilt es den DC neu zu starten. Unter Windows Server 2008 wird mit net start ntds der Dienst Active Directory-Domänendienste samt den abhängigen Diensten gestartet.

Zum Schluss sollte noch eine System State-Sicherung mit der neuen Größe der Ntds.dit durchgeführt werden.

> >>

AD-Replikationsprobleme
>
Ein weiterer Grund warum zwischen zwei DCs die AD-Datenbank unterschiedlich groß ist, könnten AD-Replikationsprobleme sein. Hinweise ob es bei der AD-Replikation Probleme gibt, liefert bereits das Verzeichnisdienstprotokoll der DCs. Ein entscheidender Faktor bei der AD-Replikation ist die Tombstone-Lifetime (TSL). Denn DCs müssen sich mindestens einmal während der TSL mit ihren Replikationspartnern repliziert haben, da ansonsten Lingering Objects (herumlungernde Objekte) in der AD-Datenbank des DCs entstehen und die Replikationspartner den „veralteten“ DC von der AD-Replikation ausschließen.

Lingering Objects (veraltete Objekte)

Oftmals handelt es sich bei Replikationsproblemen um DNS-Probleme, denn für eine AD-Umgebung ist das DNS essentiell. Bevor ein DC die AD-Replikation startet führt dieser zuerst ein DNS-Lookup durch. Somit stellt der DC zwei Dinge sicher, zum einen das sein Replikationspartner online und funktionstüchtig ist und zum anderen, das die Namensauflösung funktioniert. Daher muss bei Replikationsproblemen die Umgebung genauestens untersucht und verifiziert werden, um welche Probleme es sich tatsächlich handelt.

Das nützlichste Werkzeug für die Überprüfung und Problembehandlung bei der AD-Replikation ist für alle Serverversionen Repadmin. Bis einschließlich „Windows Server 2003“ befindet sich Repadmin noch in den Windows Support Tools (auf der Server CD im Verzeichnis Support\Tools) und ab „Windows Server 2008“ ist es „on Bord“. Dieses Tool stellt quasi das Schweizer Messer für die AD-Replikation dar. Mit diesem Kommandozeilentool lässt sich die Replikationstopologie aus der Sicht jedes einzelnen DCs anzeigen.

Den Zustand der AD-Replikation kann man z.B. mit diesem Repadmin-Befehl überprüfen:
Repadmin /Replsum * /Bysrc /Bydest /Sort:Error

Die Replikationsinformationen auf einem DC lassen sich auch in eine CSV-Datei importieren, damit diese Datei z.B. in Excel geöffnet und leichter durchsucht werden kann. Der Befehl ist wie folgt:

Repadmin /showrepl * /csv > C:\Repadmin.csv

Eine andere Methode um Differenzen zwischen den AD-Datenbanken aufzudecken, ist neben Repadmin das DSASTAT. Details dazu liefert der folgende Artikel:>

Domänencontroller vergleichen

Es könnte aber auch sein, dass ein Problem in der AD-Datenbank auf einem DC existiert. Dieses lässt sich mit einer Überprüfung der AD-Datenbankdatei herausfinden. Dazu sollte die Integrität der Ntds.dit mit NTDSUTIL untersucht und falls bei der Überprüfung Probleme gemeldet werden, könnten diese sich evtl. mit einem Fixup beheben lassen.

Siehe:
Die Active Directory-Datenbank reparieren>

Die unterschiedliche Größe der AD-Datenbank zwischen globalen Katalogen
>
Wenn in einer Multidomänen-Gesamtstruktur auf einem DC der globale Katalog (GC) aktiviert wird, werden alle AD-Objekte aus allen Domänen in den GC repliziert. Im GC wird die vollständige Domänenpartition (alle Objekte samt allen Attributen) der eigenen Domäne gespeichert, in der sich der GC befindet. Die Domänenpartitionen der anderen Domänen werden ebenfalls in den GC repliziert, es werden jedoch nicht alle Attribute der Objekte gespeichert. Nur die Attribute die für eine Suchoperation relevant sein könnten (z.B. der DN eines Objekts) werden gespeichert.

Wird auf einem DC der GC aktiviert, gibt sich dieser nach Beendigung der Replikation im DNS als solcher bekannt. Das der DC endgültig ein GC ist, wird im Verzeichnisdienstprotokoll mit der EventID 1119 (was zwingend erscheinen muss!) protokolliert.

Ob das Heraufstufen eines DCs zum GC erfolgreich abgeschlossen wurde, lässt sich anhand des folgenden Artikels ermitteln:

Globaler Katalog – Sein oder nicht sein

Falls das Heraufstufen zum GC ordnungsgemäß abgeschlossen wurde und sich die lokale AD-Datenbankdatei dennoch von anderen GCs in der Größe wesentlich unterscheidet (z.B. 50%), so könnte ein DNS- und/oder Replikationsproblem vorliegen. Auch hierbei muss dann ein tiefergehendes Troubleshooting betrieben und die AD-Replikation mit Repadmin untersucht werden. Bei der Fehlersuche sollte die erste Anlaufstelle die Ereignisanzeige des DCs sein, DCDIAG sollte ausgeführt werden und bei Verdacht auf DNS-Probleme könnte man neben dem DCDIAG (mit den DNS-Parametern) noch das DNSLint ausführen.

>

Weitere Informationen:
Die Tombstone Lifetime
Globaler Katalog (Global Catalog - GC)
Die Protokollierung des Active Directory`s konfigurieren
Extensible Storage Engine Architecture
The Active Directory database garbage collection process
Performing offline defragmentation of the Active Directory database

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Das Active Directory-Verwaltungscenter

Yusuf Dikmenoglu — Sun, 12 Apr 2009 10:45:20 GMT

Im Windows Server 2008 R2 ist ein weiteres neues Werkzeug integriert, das sich Active Directory-Verwaltungscenter (dsac.exe) nennt. Die neue Managementkonsole mit flexiblen Filtermöglichkeiten basiert auf der Powershell Version 2 und stellt im Prinzip eine grafische Shell für die Powershell dar. Denn nach dem die auszuführende Aufgabe in der Konsole ausgewählt wurde, führt dsac.exe die entsprechenden AD-Cmdlets aus. Jede Lese- und Schreibaktion im AD-Verwaltungscenter wird über die AD-Powershell durchgeführt. Das neue Werkzeug verringert den allgemeinen administrativen Aufwand, der in einer AD-Umgebung täglich zu bewältigen ist. Mit dieser neuen aufgabenbasierten Managementkonsole, beginnt im neuen Server-Betriebssystem die MMC 4 Ära.

Die im Vergleich zu der MMC „Active Directory-Benutzer und -Computer“ abgespeckte Managementkonsole „Active Directory-Verwaltungscenter“, ist in erster Linie eher an den Systemadministrator bzw. an den First-Level Support gerichtet. Denn es stehen nicht die gleichen Funktionen wie in der MMC Active Directory-Benutzer und -Computer (dsa.msc) zur Verfügung. Daher kann der AD-Administrator nicht auf die MMC dsa.msc verzichten (auch wenn es theoretisch möglich wäre). Die Personen denen die entsprechenden Rechte im AD delegiert wurden, können mit der neuen Konsole effektiver ihren täglichen Routineaufgaben nachgehen als mit der MMC dsa.msc. Gerade in größeren AD-Umgebungen mit mehreren Domänen spielt dieses Werkzeug seine Stärken aus.

Das AD-Verwaltungscenter ist, neben der AD-Powershell, von dem Dienst Active Directory-Webdienste (ADWS) abhängig, das erst ab Windows Server 2008 R2 zur Verfügung steht. Dsac.exe ist nicht auf die RPC- oder LDAP-Schnittstelle angewiesen. Daher muss in den vertrauten Domänen oder in der vertrauten Gesamtstruktur mindestens ein Windows Server 2008 R2 DC existieren oder das AD Management Gateway Service muss auf einem Windows Server 2003 DC bzw. Windows Server 2008 DC installiert sein, damit dsac.exe remote ausgeführt werden kann. Auf dem Windows Server 2008 R2 DC auf dem dieser Dienst läuft, darf der TCP-Port 9389 von der evtl. aktivierten lokalen Windows-Firewall nicht blockiert werden. Läuft der Dienst AD-Webdienste nicht oder ist dieser wegen einer Firewall nicht erreichbar, funktioniert das dsac.exe nicht.

Damit eine Windows Server 2003 oder Windows Server 2008 Umgebung mit dem AD-Verwaltungscenter (neben der AD-Powershell) administriert werden kann, muss das AD Management Gateway Service installiert werden:

Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008

Das AD-Verwaltungscenter kann lediglich zur Verwaltung von AD DS-Domänen und nicht von AD LDS-Umgebungen eingesetzt werden!

Welche Funktionen stehen im AD-Verwaltungscenter gegenüber der MMC „AD-Benutzer und -Computer“ nicht zur Verfügung?

Ein Drag & Drop ist nicht möglich.
Es steht keine Delegierungsfunktion zur Verfügung.
Die FSMO-Rollen der Domäne können nicht angezeigt werden, wie in der MMC dsa.msc.

Was kann mit dem AD-Verwaltungscenter alles durchgeführt werden?

>>>>>>

Mit dem AD-Verwaltungscenter können neue Benutzerkonten erstellt oder bestehende verwaltet werden.
Es können neue Gruppenkonten erstellt oder bestehende verwaltet werden.
Es können mehrere Objekte gleichzeitig ausgewählt und bearbeitet werden.
Neue OUs können erstellt bzw. bestehende verwaltet werden.
Auch neue Computerkonten können erstellt oder bestehende verwaltet werden.
Es ist möglich in der gleichen dsac.exe Instanz, sich mit mehreren Domänen oder Domänencontrollern zu verbinden und sich die AD-Informationen anzuzeigen bzw. Änderungen durchzuführen.
Durch die vorgegebenen oder eigens kreierten Filter (bei der globalen Suche) können lediglich die benötigten AD-Objekte angezeigt werden.
Im Gegensatz zu dsa.msc lässt sich aus dem AD-Verwaltungscenter neben dem Domänen- nun auch der Gesamtstrukturfunktionsmodus heraufstufen.

Die Installation des AD-Verwaltungscenter

>>>>>>>>>>>>>

Das AD-Verwaltungscenter kann ausschließlich auf Windows Server 2008 R2 und Windows 7 Clients, auf folgende Varianten installiert werden:

Durch das Installieren der AD DS-Rolle auf einem Windows Server 2008 R2.
Durch das Heraufstufen eines Windows Server 2008 R2 zu einem Domänencontroller.
Durch das Installieren der RSAT auf einem Windows Server 2008 R2.
Durch das Installieren der RSAT auf einem Windows 7 Client.

Das AD-Verwaltungscenter wird zusammen mit dem „Active Directory-Modul“ für die Windows PowerShell und dem .NET Framework 3.5.1 installiert. Diese beiden Komponenten sind, neben dem Dienst AD-Webdienste, die Voraussetzung damit das AD-Verwaltungscenter eingesetzt werden kann.

Das Arbeiten mit dem AD-Verwaltungscenter

Wenn das AD-Verwaltungscenter gestartet wird, sticht das zurücksetzen der Benutzerkennwörter sowie das entsperren von Benutzerkonten ins Auge. Diese beiden Optionen sind einer der meisten Fehlerquellen mit denen sich der Administrator im täglichen Leben beschäftigen muss. Des Weiteren sieht man in der linken Hälfte der Managementkonsole den Navigationsbereich. Dort kann man sich durch die einzelnen Container durch hangeln. Die oft besuchten Container werden dabei für den schnellen Zugriff direkt angezeigt.

Das Erstellen eines neuen Benutzerkontos sieht wie folgt aus. Es lassen sich die Kontooptionen, Organisationsinformationen, Gruppenmitgliedschaften und Profileinstellungen in einem Schritt konfigurieren.

>>>>>>

In der Domäne oder in einer bestimmten OU lassen sich die Objekte anhand der vorgegebenen Filtermöglichkeiten sogar mit zusätzlichen Attributen anzeigen.

Natürlich kann man auch entsprechende Suchkriterien für Computerkonten auswählen.

>>>>>>

Bei der globalen Suche kann man sich mit den vorgegebenen oder selbst erstellten Filtermöglichkeiten die gewünschten Objekte anzeigen lassen. Dabei kann man auch nach der Auswahl der vorgegebenen Filtermöglichkeiten, den echten LDAP-Filter anzeigen lassen.

Des Weiteren ist es wie im Windows Explorer möglich, durch die Eingabe eines bestimmten LDAP-Pfads in der Adresszeile direkt in die gewünschte OU zu navigieren.

>>>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Der Active Directory Best Practice Analyzer

Yusuf Dikmenoglu — Sun, 08 Mar 2009 09:43:39 GMT

Endlich wird es in Zukunft auch einen Best Practice Analyzer (BPA) für die Active Directory Domain Services (kurz AD DS-BPA) geben. Der BPA der bereits seit längerem für verschiedene Microsoft Produkte existiert (Siehe Abschnitt „Weitere BPAs“), ist für viele Administratoren ein unverzichtbares Werkzeug. Denn mit dem BPA lassen sich Konfigurationsprobleme schnell und einfach aufspüren.

Der BPA für die AD DS-Rolle wird erstmals im Windows Server 2008 R2 eingeführt und hilft dem Administrator dabei, Best Practices bei der Konfiguration der AD DS-Umgebung zu implementieren. Ein oder mehrere DCs lassen sich gegen eine Reihe von vordefinierten Best Practices überprüfen. Der AD DS-BPA erstattet nach der Durchführung Bericht, ob der DC mit den Best Practices kompatibel oder nicht konform ist.

Wenn die AD DS-Umgebung installiert und alles Notwendige konfiguriert wurde, ist es empfehlenswert die durchgeführten Konfigurationen anschließend auf Fehler zu überprüfen. Doch dies ohne den AD DS-BPA zu verifizieren ist gar nicht so einfach und dauert unter Umständen viele Stunden. Aber mit dem neuen AD DS-BPA lassen sich schnell und einfach Konfigurationsfehler und Schwachstellen in der AD DS-Umgebung auf Knopfdruck aufspüren.

Der AD DS-BPA lässt sich zum einen über die grafische Oberfläche und zum anderen, über die Powershell-Kommandozeile ausführen. In der grafischen Oberfläche befindet sich der AD DS-BPA ausschließlich im Server Manager des Windows Server 2008 R2. Der Server Manager ist erstmals auch in den RSAT für den Windows 7 Client enthalten.

Der BPA scannt die AD DS-Rolle so wie sie auf dem Windows Server 2008 R2 DC konfiguriert ist. Nach der Durchführung werden im Server Manager in den Reitern „Nicht Kompatibel“ und „Kompatibel“ die Ergebnisse angezeigt. Ein Ergebnis kann dabei als „Schweregrad“ Fehler, Warnung oder Kompatibel enthalten.

>

Bei Fehlern die im Reiter „Nicht Kompatibel“ angezeigt werden und somit gegen die „Best Practices“ verstoßen (wenn z.B. kein DNS-Server für die Domäne erreichbar ist), werden in der Beschreibung die Punkte „Problem“, „Auswirkung“ und „Lösung“ angezeigt. Durch die genauen Angaben erfährt man, welche Auswirkung das gefundene Problem hat und vor allem, wie es sich lösen lässt.

Die Ergebnisse können gefiltert werden, indem einzelne Berichte für die zukünftigen Durchführungen des BPA vorübergehend ausgeschlossen und zu einem späteren Zeitpunkt erneut einbezogen werden.

Im AD DS-Umfeld steht der BPA unter Windows Server 2008 R2 vorerst für die folgenden Rollen zur Verfügung:>>

Active Directory Certificate Services
Active Directory Domain Services
DNS Server

Der BPA wird über die “Windows Updates” stetig verbessert und erweitert.

Was ist möglich?

Der AD DS-BPA lässt sich über den Server Manager oder über die Powershell, nur auf Windows Server 2008 R2 DCs ausführen.
Der AD DS-BPA kann über den Server Manager oder über die Powershell lokal und remote auf einem Windows Server 2008 R2 Vollinstallation, Windows Server 2008 R2 RODC und Windows Server 2008 R2 Core ausgeführt werden.
Auf einem Windows Server 2008 R2 Core kann lokal der AD DS-BPA ausschließlich über die Powershell ausgeführt werden, da der Server Manager in der grafischen Oberfläche auf einem Windows Server 2008 R2 Core nicht existiert.
Von einem Windows 7 Client worauf das RSAT (Remote Server Administration Tools) installiert ist, kann der AD DS-BPA über den Server Manager oder über die Powershell remote auf einem Windows Server 2008 R2 Vollinstallation oder Windows Server 2008 R2 Core ausgeführt werden.
Nur über die Powershell können mehrere Rollen zur gleichen Zeit überprüft werden (z.B. die AD DS- und DNS-Rolle).

Was ist nicht möglich?

Der Server Manager vom Windows Server 2008 R2, worin sich der AD DS-BPA befindet, lässt sich nicht auf Windows 2000, Windows Server 2003/2003 R2 oder Windows Server 2008 installieren.
Der AD DS-BPA lässt sich nicht über den Server Manager remote auf einen Windows 2000 DC, Windows Server 2003/2003 R2 DC und Windows Server 2008 DC ausführen.
Der AD DS-BPA lässt sich nicht über die Powershell remote auf einen Windows 2000 DC, Windows Server 2003/2003 R2 DC und Windows Server 2008 DC ausführen.

Wie wird der AD DS-BPA im Server Manager installiert?

>>>

Sobald auf einem Windows Server 2008 R2 Vollinstallation die AD DS-Rolle installiert und dieser zum Domänencontroller gestuft wird, steht der AD DS-BPA automatisch im Server Manager zur Verfügung. Es ist auch nicht notwendig weitere Komponenten zu installieren um den AD DS-BPA zu nutzen.

Auf einem Windows Server 2008 R2 Core kann der AD DS-BPA lokal ausschließlich über die Powershell ausgeführt werden.

Die Bestandteile des AD DS-BPA

Der Server-Manager im Windows Server 2008 R2 beinhaltet eine Engine mit dem der AD DS-BPA ausgeführt wird. Dabei besteht der AD DS-BPA aus den folgenden Komponenten:

AD DS-BPA PowerShell Skript: Das Skript sammelt AD DS-Konfigurationsdaten und speichert sie in ein XML-Dokument.
XML-Schema: Das Schema definiert das Format des XML-Dokuments, das vom AD DS-BPA PowerShell Skript erzeugt wurde.
AD DS-BPA Regeln: Die Regeln definieren die Best Practice-Konfiguration einer AD DS Umgebung.
AD DS-BPA Leitfaden: Diese Informationen helfen dem Administrator ihre AD DS-Umgebung entsprechend den Best Practices zu konfigurieren.

Die Funktionsweise des AD DS-BPA

Wenn der AD DS-BPA auf einem DC ausgeführt wird, werden die folgenden Schritte durchgeführt:

Die BPA Engine sammelt in der bestehenden AD DS-Umgebung mit dem „AD DS-BPA Powershell Skript“ Informationen über die AD DS-Konfiguration und speichert sie in ein XML-Dokument.
Danach wird das XML-Dokument gegen das „XML-Schema“ validiert.
Nach dem Anwenden der „AD DS-BPA Regeln“ auf das XML-Dokument wird anschließend ein Bericht anhand des „AD DS-BPA Leitfaden“ erstellt.

Den AD DS-BPA lokal in der grafischen Oberfläche ausführen

Der AD DS-BPA lässt sich mit der Maus im Server Manager eines Windows Server 2008 R2 DCs Vollinstallation ausführen. Dort findet man ihn nach Auswahl der Rolle Active Directoy-Domänendienste in der Zusammenfassung.

Das Ausführen des AD DS-BPA lokal auf einem Windows Server 2008 R2 DC Vollinstallation, in der AD-Powershell

In der Powershell-Kommandozeile lässt sich der AD DS-BPA ebenfalls ausführen.

Als erstes gilt es das Server Manager-Modul mit dem folgenden Befehl in die Powershell-Sitzung zu importieren.
Import-Module ServerManager
Im zweiten Schritt muss das BPA-Modul mit diesem Befehl importiert werden.
Import-Module BestPractices
Mit diesem Befehl werden alle verfügbaren BPAs aufgelistet.
Get-BPAModel
Nach der Durchführung des AD DS-BPA werden die Ergebnisse mit diesem Befehl angezeigt.
Get-BPAResult Microsoft/Windows/DirectoryServices
Die AD DS-Rolle wird mit diesem Befehl überprüft.
Invoke-BPAModel Microsoft/Windows/DirectoryServices
Einzelne Ergebnisse werden mit diesem Befehl ausgeschlossen bzw. erneut einbezogen.
Set-BPAResult

Den AD DS-BPA remote im Server Manager ausführen

Mit dem Server Manager lässt sich nun auch unter Windows Server 2008 R2 wie es bei MMCs üblich ist, remote eine Verbindung zu anderen Servern aufbauen. Das war vor Windows Server 2008 R2 nicht möglich. Der Server Manager steht unter Windows Server 2008 R2 sowie auf dem Windows 7 Client nach dem Installieren der RSAT zur Verfügung.

Doch bevor man sich mit dem Server Manager zu einem anderen DC verbinden kann, muss der zu verwaltende DC dies vorher zulassen. Das Zulassen für die Remoteverwaltung kann ebenfalls im Server Manager erfolgen. Die notwendigen Einstellungen werden bei aktivierter Windows-Firewall automatisch vorgenommen.

Über die Powershell muss auf dem zu verwaltenden DC zuerst der Befehl set-executionPolicy -executionPolicy remotesigned ausgeführt werden. Alle dazu benötigten Windows-Firewalleinstellungen werden durch diesen Befehl Configure-SMRemoting.ps1 -force -enable vorgenommen.

Anschließend lässt sich die AD DS-Rolle auf einem beschreibbaren Windows Server 2008 R2 DC, Windows Server 2008 R2 RODC oder Windows Server 2008 R2 Core DC von der Ferne aus überprüfen.

Den AD DS-BPA lokal auf einem Windows Server 2008 R2 Core DC ausführen

Ein lokales Ausführen des AD DS-BPA auf einem Windows Server 2008 R2 Core DC ist nur über die Powershell möglich. Die Powershell ist jedoch standardmäßig nicht installiert. Dazu müssen die folgenden Features installiert werden:

start /w ocsetup NetFx3-ServerCore
start /w ocsetup ServerCore-WOW64
start /w ocsetup MicrosoftWindowsPowerShell
start /w ocsetup MicrosoftWindowsPowerShell-WOW64
start /w ocsetup ActiveDirectory-PowerShell

Achtung: Die Featurenamen sind case sensitive!

Nach der Installation der Features, lässt sich die Powershell aus dem Verzeichnis %windir%\system32\windowspowershell\v1.0 mit dem Befehl powershell aufrufen. Anschließend gilt es die folgenden Powershell-Module zu laden:

import-module activedirectory
import-module servermanager
import-module bestpractices

Überprüfen lässt sich danach die AD DS-Rolle mit diesem Befehl:
Get-WindowsFeature AD-Domain-Services | invoke-bpamodel

Die Ergebnisse nach der Durchführung des AD DS-BPAs lassen sich mit diesem Befehl anzeigen:
Get-WindowsFeature AD-Domain-Services | get-bparesult >

Den AD DS-BPA remote auf einem Windows Server 2008 R2 Core DC ausführen

Bevor man den AD DS-BPA von der Ferne aus über den Server Manager oder über die AD-Powershell auf einem Windows Server 2008 R2 Core ausführen kann, muss zuerst auf dem Server Core die Fernadministration erlaubt werden. Mit dem folgenden Befehl werden die entsprechenden Konfigurationen in der Windows-Firewall vorgenommen: winrm quickconfig.

Anschließend kann man mit dem Server Manager oder über die Powershell von einem Windows Server 2008 R2 oder von einem Windows 7 Client (mit installierten RSAT) remote den AD DS-BPA auf einem Windows Server 2008 R2 Core DC ausführen.

Weitere BPAs für verschiedene Microsoft Produkte

Für Gruppenrichtlinien, Exchange, ISA, SQL und einige mehr gibt es den BPA schon seit längerer Zeit.

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Das Kennwort vom DSRM ab Windows Server 2008 synchronisieren

Yusuf Dikmenoglu — Sun, 22 Feb 2009 21:22:25 GMT

Immer wieder haben Administratoren Probleme mit dem Kennwort für den Verzeichnisdienstwiederherstellungsmodus. Sie gehen zu leichtfertig und unbedacht mit diesem hochsensiblen Kennwort um und wissen oftmals nicht, für was dieses Kennwort benötigt wird. Sie schreiben sich das Kennwort bei der Vergabe nicht auf und wissen es im Ernstfall nicht mehr. Das man das Kennwort seit Windows 2000 im laufenden Betrieb eines DCs ändern kann, ist ebenfalls vielen unbewusst. Um diesen Zustand bis zu einem gewissen Grad zu mildern sowie zu garantieren, dass das Kennwort konsistent bleibt, hat sich Redmond etwas einfallen lassen.

Microsoft hat ein neues Feature unter Windows Server 2008 veröffentlicht, mit dem das synchronisieren des Kennworts für den Modus „Verzeichnisdienste wiederherstellen" (im englischen „Directory Services Restore Mode“, kurz DSRM) und einem Domänen-Benutzerkonto möglich ist. Diese neue Funktion vermindert oder erhöht keineswegs die Sicherheit des Kennworts. Es dient einzig und alleine dazu, die Verwaltung des Kennworts zu vereinfachen.

Diese Funktion steht aber erst ab Windows Server 2008 und dort erst nach der Installation eines Hotfix zur Verfügung, der vorher von Microsoft von dieser Seite angefordert werden muss. Wurde der Hotfix auf einem Windows Server 2008 DC installiert, ist zwingend ein Neustart erforderlich. Der Hotfix steht ausschließlich für Windows Server 2008 zur Verfügung! Ab dem Service Pack 2 für Windows Server 2008 ist der Hotfix integriert und das installieren des Hotfix' ist nicht notwendig! Ab Windows Server 2008 R2 ist es ohnehin integriert.

Die Synchronisierung des Kennworts für den Verzeichnisdienstwiederherstellungsmodus mit dem Kennwort eines Domänen-Benutzerkontos erfolgt über das Kommandozeilentool NTDSUTIL. Dabei hat jeder DC sein „eigenes“ Kennwort für den Verzeichnisdienstwiederherstellungsmodus, das lokal gespeichert ist.

Nach der Eingabe des folgenden Befehls findet eine einseitige Synchronisation statt. Das Konto für den Verzeichnisdienstwiederherstellungsmodus erhält das Kennwort vom angegebenen Benutzerkonto. Die Vorgehensweise ist wie folgt:

Unter „Start-Ausführen“ oder in einer Kommandozeile gilt es zuerst das NTDSUTIL aufzurufen.
Danach ist dieser Befehl einzugeben: set dsrm password
Anschließend wird die Synchronisierung des Kennworts mit diesem Befehl durchgeführt: sync from domain account <sAMAccountName>
Mit der zweimaligen Eingabe von q verlässt man das NTDSUTIL.

Man kann die Synchronisation auch mit dem folgenden Einzeiler erreichen: NTDSUTIL “set dsrm password" "sync from domain account <Benutzer>" q q

Der Befehl kann im laufenden Betrieb ausgeführt werden und das Kennwort wird dann einmalig synchronisiert! Es findet keine permanente Synchronisation statt. Daher muss der Befehl erneut ausgeführt werden, wenn sich das Kennwort vom angegebenen Benutzerkonto geändert hat.

Über die "Group Policy Preferences" und einem "geplanten Task" lässt sich die Synchronisierung des Kenworts auch automatisieren:

DS Restore Mode Password Maintenance

Weitere Informationen:
How to Change the Recovery Console Administrator Password on a Domain Controller
How To Reset the Directory Services Restore Mode Administrator Account Password in Windows Server 2003
Active Directory-Domänendienste (AD-DS)

>>>>>>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Die AD-Powershell im Windows Server 2008 R2

Yusuf Dikmenoglu — Sun, 08 Feb 2009 12:31:33 GMT

Im Windows Server 2008 R2 ist erstmals die Active Directory-Powershell in der Version 2.0 Out-of-the-Box für AD DS sowie AD LDS (ehemals ADAM) im Betriebssystem integriert. Es stehen die AD-Powershell Kommandozeile sowie das Snap-In Windows PowerShell Integrated Scripting Environment (ISE) zur Verfügung. Die Powershell-Entwicklungsumgebung ISE muss im Server Manager unter den Features installiert werden, ehe diese unter Start - Alle Programme - Zubehör - Windows Powershell genutzt werden kann. Hinter der AD-Powershell verbirgt sich nichts anderes als ein Powershell-Modul Namens „ActiveDirectory“, worin bereits die AD-Cmdlets zur Verfügung stehen. Denn unter der Windows Powershell V2 sowie ISE müssen zuerst die AD-Cmdlets mit dem Befehl import-module activedirectory importiert werden. Die Bestandteile der AD-Powershell ist der AD-Powershell Provider und die insgesamt 76 AD-Powershell Commandlets (kurz Cmdlets).

Vor Windows Server 2008 R2 mussten AD-Administratoren mehrere Kommandozeilentools und AD Snap-Ins verwenden, um ihre Active Directory-Umgebung sowie die AD LDS „configuration sets“ (eine Gruppe von Replikationspartnern) zu administrieren und zu konfigurieren. Diese Vielfalt an Werkzeugen können sie zwar auch unter Windows Server 2008 R2 weiterhin nutzen, doch wer seine AD DS/AD LDS-Umgebung zentralisiert aus nur einem Werkzeug heraus administrieren bzw. konfigurieren möchte, der kann dies mit der Active Directory-Powershell realisieren.

Dadurch lassen sich viele AD-Administrations- und -Konfigurationsaufgaben nun auch über die AD-Powershell ausführen. Doch bevor die AD-Powershell genutzt werden kann, muss diese zuerst installiert werden. Die Installation der AD-Powershell kann ausschließlich auf den Betriebssystemen Windows Server 2008 R2 Vollinstallation, Server Core R2 und Windows 7 Client durchgeführt werden. >

Dabei kann die Installation der AD-Powershell auf verschiedene Weise erfolgen. Diese wären:

Die Installation der Serverrolle AD DS oder AD LDS unter Windows Server 2008 R2.
Das Heraufstufen eines Windows Server 2008 R2 zu einem Domänencontroller (DC) mit dem Dcpromo-Assistenten.
Bei der Installation der Remote Server Administration Tools (kurz RSAT) auf einem Windows Server 2008 R2 Servers.
Mit der Installation der RSAT auf Windows 7 Clients.

Mit der Installation der AD-Powershell werden standardmäßig die Komponenten „Windows Powershell“ und „.NET Framework 3.5.1“ mit installiert. Diese beiden Komponenten sind die Voraussetzung ehe die AD-Powershell installiert und genutzt werden kann.

Wenn die AD-Powershell auf einem Windows 7 Client genutzt werden soll, um eine AD DS-Domäne oder AD LDS-Umgebung zu administrieren, dann ist das erst möglich wenn sich mindestens ein Windows Server 2008 R2 DC oder mindestens eine Instanz in einem AD LDS „configuration set“ auf einem Windows Server 2008 R2 läuft. Das ist notwendig, da die AD-Powershell von dem Dienst Active Directory-Webdienste abhängig ist und nicht von der RPC- bzw. LDAP-Schnittstelle. Nur wenn dieser Dienst in der Umgebung zur Verfügung steht, kann die AD-Powershell eingesetzt werden.

Damit eine Windows Server 2003 oder Windows Server 2008 Umgebung oder AD LDS-Instanzen die auf Windows Server 2008 laufen von einem Windows 7 Client oder Windows Server 2008 R2 Mitgliedsserver bzw. DC administrert werden können, muss vorher das Active Directory Management Gateway Service installiert werden:

Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008

Nach der Installation der AD-Powershell stehen alle 76 verfügbaren AD-Cmdlets zur Verfügung und man kann sich mit dem Befehl Get-Command *-ad* die Cmdlets anzeigen lassen. Mit den folgenden Powershell-Befehlen lässt sich zu dem jeweils angegebenen AD-Cmdlet eine detailierte und ausführliche Hilfe anzeigen:

Get-Help <Cmdlet Name> -Detailed (z.B. Get-Help Disable-ADAccount -Detailed)

Get-Help <Cmdlet Name> -Examples

Get-Help <Cmdlet Name> -Full >>

Die Cmdlets lassen sich auch durch das Pipelining miteinander verbinden. Dadurch können die Daten von einem Cmdlet zum anderen weitergegeben werden. Z.B.: Search-ADAccount <Parameter/alle deaktivierten Benutzer> | Enable-ADAccount

Die AD-Cmdlets die zur Verfügung stehen sind:

ADAccount (4 Cmdlets)
- Disable-ADAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
  Deaktiviert das angegebene Benutzer-, Dienst- oder Computerkonto.
- Enable-ADAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
  Aktiviert das angegebene Benutzer-, Dienst- oder Computerkonto.
- Search-ADAccount
  Die Suche zeigt Benutzer- oder Computerkonten anhand der angegebenen Parameter an.
- Unlock-ADAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
  Entsperrt ein Domänen-Benutzerkonto.
ADAccountAuthorizationGroup (1 Cmdlet)>

Get-ADAccountAuthorizationGroup (Das Cmdlet funktioniert nicht bei einem AD-Snapshot)
Zeigt die Sicherheitsgruppen mit detailierten Informationen im AD an, in denen das angegebene Benutzer-, Dienst- oder Computerkonto Mitglied ist. Mit diesem Cmdlet wird auch die „primäre Gruppe“ eines Benutzers angezeigt!

ADAccountControl (1 Cmdlet)

Set-ADAccountControl (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Mit diesem Cmdlet lassen sich die Kontooptionen eines Benutzer- oder Computerkontos bearbeiten. Das Attribut „userAccountControl“ das sich aus einer Bitmaske zusammensetzt, lässt sich somit auch in der AD-Powershell bearbeiten.

ADAccountExpiration (2 Cmdlet)

Clear-ADAccountExpiration (Dieses Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Mit diesem Cmdlet lässt sich in den Eigenschaften eines Benutzerkontos, im Reiter Konto die Option “Konto läuft ab” auf „Nie“ einstellen.

Set-ADAccountExpiration (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Das Ablaufdatum eines Benutzerkontos lässt sich mit diesem Cmdlet konfigurieren.

ADAccountPassword (1 Cmdlet)

Set-ADAccountPassword (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Das Kennwort eines Benutzer- oder Dienstkonto kann mit diesem Cmdlet bearbeitet bzw. ein neues vergeben werden.

ADAccountResultantPasswordReplicationPolicy (1 Cmdlet)

Get-ADAccountResultantPasswordReplicationPolicy (Das Cmdlet funktioniert nicht bei den AD LDS)
Mit diesem Cmdlet kann man sich die Kennwortreplikationsrichtlinie eines Benutzer-, Dienst- oder Computerkontos, an dem angegebenen RODC anzeigen lassen.

ADComputer (4 Cmdlet)

Get-ADComputer (Das Cmdlet funktioniert nicht bei den AD LDS)
Eine Abfrage über Computerkonten anhand bestimmter Kriterien lässt sich mir diesem Cmdlet durchführen.

New-ADComputer (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Hiermit können Computerkonten im AD erstellt werden. Darunter fällt auch die neue Funktion „Offline Domain Join“ oder ein RODC-Computerkonto.

Remove-ADComputer (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Dieses Cmdlet entfernt Computerkonten aus dem AD.

Set-ADComputer (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Die Eigenschaften eines Computerkontos lassen sich mit diesem Cmdlet bearbeiten.

ADComputerServiceAccount (3 Cmdlets)

Add-ADComputerServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Ein oder mehrere Computer-Dienstkonten werden mit diesem Cmdlet auf einem Server hinzugefügt.

Get-ADComputerServiceAccount (Das Cmdlet funktioniert nicht bei den AD LDS)
Die auf einem Server verfügbaren Computer-Dienstkonten zeigt dieses Cmdlet an.

Remove-ADComputerServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Entfernen lassen sich ein oder mehrere Computer-Dienstkonten mit diesem Cmdlet.

ADDefaultDomainPasswordPolicy (2 Cmdlets)

Get-ADDefaultDomainPasswordPolicy (Das Cmdlet funktioniert nicht bei den AD LDS)
Dieses Cmdlet zeigt die Domänen-Kennwortrichtlinie an und nicht die “Password Settings Objects (PSO)”.
Set-ADDefaultDomainPasswordPolicy (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Mit diesem Cmdlet lassen sich die Kennwortvorgaben (minimales und maximales Kennwortalter usw.) in der Domänen-Kennwortrichtlinie konfigurieren.

ADDirectoryServer (1 Cmdlet)

Move-ADDirectoryServer (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Ein Domänencontroller kann mit diesem Cmdlet an einen anderen AD-Standort verschoben werden.

ADDirectoryServerOperationMasterRole (1 Cmdlet)

Move-ADDirectoryServerOperationMasterRole (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Dieses Cmdlet lässt sich zum Verschieben der FSMO-Rollen einsetzen.

ADDomain(2 Cmdlets)

Get-ADDomain (Das Cmdlet funktioniert nicht bei den AD LDS)
Mit diesem Cmdlet und den entsprechenden Parametern lassen sich Domäneninformationen ausgeben.

Set-ADDomain (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Dieses Cmdlet lässt sich zum Bearbeiten diverser Domäneninformationen verwenden.

ADDomainController (1 Cmdlet)

Get-ADDomainController (Das Cmdlet funktioniert nicht bei den AD LDS)
Ausführliche Informationen über einen Domänencontroller erhält man mit diesem Cmdlet.

ADDomainControllerPasswordReplicationPolicy (3 Cmdlets)

Add-ADDomainControllerPasswordReplicationPolicy (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Ein oder mehrere Benutzer, Gruppen oder Computer können mit diesem Cmdlet in die Sicherheitsgruppe „Abgelehnte RODC-Kennwortreplikationsgruppe” oder „Zulässige RODC-Kennwortreplikationsgruppe” hinzugefügt werden.

Get-ADDomainControllerPasswordReplicationPolicy (Das Cmdlet funktioniert nicht bei den AD LDS)
Die Mitglieder (Benutzer, Gruppen oder Computer) der Sicherheitsgruppe „Zulässige RODC-Kennwortreplikationsgruppe” oder „Abgelehnte RODC-Kennwortreplikationsgruppe” werden mit diesem Cmdlet angezeigt.

Remove-ADDomainControllerPasswordReplicationPolicy (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Dieses Cmdlet entfernt einzelne oder mehrere Benutzer, Gruppen oder Computer von der Sicherheitsgruppe „Abgelehnte RODC-Kennwortreplikationsgruppe” oder „Zulässige RODC-Kennwortreplikationsgruppe”.

ADDomainControllerPasswordReplicationPolicyUsage(1 Cmdlet)

Get-ADDomainControllerPasswordReplicationPolicyUsage (Das Cmdlet funktioniert nicht bei den AD LDS)
In welcher RODC-Kennwortreplikationsgruppe (zulässige oder abgelehnte) der angegebene Benutzer auf dem angegebenen RODC Mitglied ist, zeigt dieses Cmdlet.

ADDomainMode (1 Cmdlet)

Set-ADDomainMode (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Das Heraufstufen des Domänenfunktionsmodus lässt sich auch mit diesem Cmdlet festlegen.

ADFineGrainedPasswordPolicy (4 Cmdlets)

Get-ADFineGrainedPasswordPolicy (Das Cmdlet funktioniert nicht bei den AD LDS)
Dieses Cmdlet zeigt die konfigurierten Optionen einer oder mehrerer “Password Settings Objects (PSO)” an.

New-ADFineGrainedPasswordPolicy (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Neue PSOs können mit diesem Cmdlet erstellt werden.

Remove-ADFineGrainedPasswordPolicy (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Entfernen lässt sich ein PSO mit diesem Cmdlet.

Set-ADFineGrainedPasswordPolicy (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Die konfigurierten Optionen einer PSO können mit diesem Cmdlet überarbeitet werden.

ADFineGrainedPasswordPolicySubject (3 Cmdlets)

Add-ADFineGrainedPasswordPolicySubject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Mit diesem Cmdlet wird eine bereits bestehende PSO mit einem oder mehreren Benutzern bzw. einer Gruppe verknüpft.

Get-ADFineGrainedPasswordPolicySubject (Das Cmdlet funktioniert nicht bei den AD LDS)
Welche Benutzer oder Gruppen mit einem bestimmten PSO verknüpft sind, zeigt dieses Cmdlet.

Remove-ADFineGrainedPasswordPolicySubject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Eine oder mehre Benutzer bzw. Gruppen werden mit diesem Cmdlet von einer PSO entfernt.

ADForest (2 Cmdlets)

Get-ADForest (Das Cmdlet funktioniert nicht bei den AD LDS)
Weiterreichende Informationen über die Gesamtstruktur erhält man durch dieses Cmdlet.

Set-ADForest (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Dieses Cmdlet lässt sich zum Hochstufen des Gesamtstrukturfunktionsmodus oder zum Bearbeiten gesamtstrukturweiter Informationen (z.B. Hinzufügen oder Bearbeiten des UPNSuffix) verwenden.

ADForestMode (1 Cmdlet)

Set-ADForestMode (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Der Gesamtstrukturfunktionsmodus lässt sich mit diesem Cmdlet Hochstufen.

ADGroup (4 Cmdlets)

Get-ADGroup
Sollen die Benutzer einer speziellen Gruppe ermittelt werden, eine Gruppe mit detailierten Informationen angezeigt oder alle Gruppen anhand bestimmter Kriterien ermittelt werden, so kann man dieses Cmdlet dafür verwenden.

New-ADGroup (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Sicherheit- oder Verteilergruppen können in der AD-Powershell mit diesem Cmdlet erstellen werden.

Remove-ADGroup (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Gruppentypen der Kategorie „Sicherheit“ oder „Verteilung“ werden mit diesem Cmdlet entfernt.

Set-ADGroup (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Bestehende Gruppen lassen sich mit diesem Cmdlet bearbeiten.

ADGroupMember (3 Cmdlets)

Add-ADGroupMember (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Ein oder mehrere Benutzer-, Gruppen-, Dienst- oder Computerkonten können mit diesem Cmdlet einer bestimmten Gruppe hinzugefügt werden.

Get-ADGroupMember (Das Cmdlet funktioniert nicht bei einem AD-Snapshot)
Die Mitglieder (Benutzer, Gruppen, Clients) einer bestimmten Gruppe werden mit diesem Cmdlet angezeigt.

Remove-ADGroupMember (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Mit diesem Cmdlet ist es möglich, ein oder mehrere Benutzer, Gruppen oder Clients aus einer bestimmten Gruppe zu entfernen.

ADObject (7 Cmdlets)

Get-ADObject
Jegliche Active Directory-Abfrage kann anhand der angegebenen Parameter mit diesem Cmdlet durchgeführt werden.

Move-ADObject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Active Directory-Objekte oder OUs können entweder innerhalb oder zwischen Domänen mit diesem Cmdlet verschieben werden.

New-ADObject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Neue Active Directory-Objekte jeder Art, sei es z.B. neue Benutzer, OUs oder Subnetze werden mit diesem Cmdlet erstellt.

Remove-ADObject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Jede Art von Active Directory-Objekten, wie z.B. Benutzer oder OUs, können mit diesem Cmdlet entfernt werden.

Rename-ADObject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Das umbenennen von AD-Objekten kann mit diesem Cmdlet durchgeführt werden.

Restore-ADObject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Dieses Cmdlet stellt ein gelöschtes ADObjekt aus dem Container „Deleted Objects“ wieder her.

Set-ADObject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Jegliche Art von AD-Objekten lassen sich mit diesem Cmdlet bearbeiten.

ADOptionalFeature (3 Cmdlets)

Disable-ADOptionalFeature (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Ein Active Directory „Optional Feature“ lässt sich mit diesem Cmdlet deaktivieren.

Enable-ADOptionalFeature (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Aktivieren lässt sich ein „Optional Feature“, wie z.B. der AD-Papierkorb, mit diesem Cmdlet.

Get-ADOptionalFeature
Die optionalen Features innerhalb einer Gesamtstruktur werden mit diesem Cmdlet angezeigt.

ADOrganizationalUnit (4 Cmdlets)

Get-ADOrganizationalUnit
Eine oder mehrere Organisationseinheiten (OU) können anhand der angegebenen Parameter, mit diesem Cmdlet ermittelt werden.

New-ADOrganizationalUnit (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Erstellen lässt sich eine neue OU mit diesem Cmdlet.

Remove-ADOrganizationalUnit (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Soll eine OU (ohne oder mit Objekten) entfernt werden, so lässt sich das Löschen mit dieser Cmdlet durchführen. Ist allerdings die OU vor dem „versehentlichen“ löschen geschützt, so erscheint eine Fehlermeldung.

Set-ADOrganizationalUnit (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Die Eigenschaften einer OU (Adressinformationen oder die Einstellung „Objekt vor zufälligem Löschen schützen“ etc.) lassen sich mit diesem Cmdlet bearbeiten.

ADPrincipalGroupMembership (3 Cmdlets)

Add-ADPrincipalGroupMembership (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Dieses Cmdlet fügt einen oder mehrere Benutzer, Gruppen oder Computer zu einer oder mehreren Gruppen hinzu.

Get-ADPrincipalGroupMembership (Das Cmdlet funktioniert nicht bei einem AD-Snapshot)
Alle Gruppenmitgliedschaften eines Benutzers, einer Gruppe oder eines Clients werden mit diesem Cmdlet angezeigt.

Remove-ADPrincipalGroupMembership (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Ein oder mehrere Benutzer, Gruppen oder Clients werden mit diesem Cmdlet aus einer oder mehreren Gruppen entfernt.

ADRootDSE (1 Cmdlet)

Get-ADRootDSE
Die Informationen des Einstiegpunkts eines Active Directory (RootDSE) zeigt dieses Cmdlet an.

ADServiceAccount (6 Cmdlets)

Get-ADServiceAccount (Das Cmdlet funktioniert nicht bei den AD LDS)
Die im Windows Server 2008 R2 eingeführten AD-Dienstkonten („Managed Service Account“) lassen sich anhand der angegeben Parameter, mit diesem Cmdlet anzeigen.

Install-ADServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Ein neues AD-Dienstkonto lässt sich mit diesem Cmdlet installieren.

New-ADServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Dieses Cmdlet erstellt ein neues AD-Dienstkonto.

Remove-ADServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Entfernen kann man ein AD-Dienstkonto mit diesem Cmdlet.

Set-ADServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Mit diesem Cmdlet lässt sich ein bestehendes AD-Dienstkonto bearbeiten.

Uninstall-ADServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Deinstallieren lässt sich ein AD-Dienstkonto mit diesem Cmdlet.

ADServiceAccountPassword (1 Cmdlet)

Reset-ADServiceAccountPassword (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Das Kennwort eines AD-Dienstkontos kann mit diesem Cmdlet zurückgesetzt werden.

ADUser (4 Cmdlets)

Get-ADUser
Ist man auf der Suche nach einem bestimmten oder nach mehreren Benutzern die alle ein bestimmtes Kriterium erfüllen, so lässt sich die Abfrage mit diesem Cmdlet durchführen.

New-ADUser (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Ein Benutzerkonto (samt Kennwort) lässt sich mit diesem Cmdlet erstellen.

Remove-ADUser (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Dieses Cmdlet entfernt ein oder mehrere Benutzerkonten.

Set-ADUser (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Bearbeiten kann man ein Benutzerkonto mit diesem Cmdlet.

ADUserResultantPasswordPolicy (1 Cmdlet)

Get-ADUserResultantPasswordPolicy (Das Cmdlet funktioniert nicht bei den AD LDS)
Die mit einem Benutzer- oder Gruppenkonto verknüpften “Password Settings Objects“ (PSO) werden mit diesem Cmdlet angezeigt.

>
Weitere Informationen:
AD-PowerShell Befehle
Active Directory Powershell Overview
Active Directory Module for Windows PowerShell Cookbook
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
Der Active Directory-Papierkorb im Windows Server 2008 R2 >

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Wie viele DCs pro Domäne werden benötigt?

Yusuf Dikmenoglu — Mon, 05 Jan 2009 20:38:27 GMT

So einfach wie die Frage im ersten Moment klingt, so schwierig ist sie zu beantworten. Gleich vorweg, letztendlich lässt sich diese Frage nicht pauschal beantworten, denn es gibt keine Faustformel dazu, die Anzahl der benötigten DCs zu berechnen.

Aber eins kann man mit Gewissheit empfehlen, jede Domäne sollte (um nicht zu sagen müsste) wegen der Ausfallsicherheit und Verfügbarkeit mindestens zwei Domänencontroller enthalten.

Damit ist zumindest sichergestellt, dass bei einem DC-Crash der andere DC die Domäne noch am Leben erhält. In vielen Umgebungen wird die Anzahl der DCs an der Ausfallsicherheit, der Standortverteilung oder der Anzahl der Benutzer pro Standort bestimmt. Die Bandbreitenanbindung bei bestehen von mehreren Standorten ist für die Anzahl an DCs, ebenfalls von elementarer Bedeutung.

Es kommt bei der Ermittlung der genauen Anzahl an DCs immer auf die Umgebung an.

Wie viele DCs in der Domäne benötigt werden, hängt außerdem von den Ansprüchen des Unternehmens ab. Natürlich hat ein großes Unternehmen mit vielen Standorten andere Ansprüche bzgl. der hohen Verfügbarkeit, Fehlertoleranz sowie Redundanz, als kleinere und mittlere Unternehmen (KMU) mit vielleicht nur einem Standort.

Die folgenden Kriterien helfen bei der Definition der Anzahl an DCs pro Domäne:

Wie viele AD-Standorte existieren?
In wie vielen Ländern?
Mit welcher (stabilen?) Bandbreite?
Wie viele Benutzer existieren pro Standort?
Wie viel Last besteht auf den DCs während der Benutzerauthentifizierungen?
Existiert eine Exchange-Umgebung?
Existieren Applikationen die vom AD abhängig sind?
Gibt es Standorte, die besonders AD-lastig arbeiten?
Existieren Standorte, in denen mehr gesamtstrukturweite Abfragen, sprich der globale Katalog überwiegend beansprucht wird?
Besteht aktuelle Hardware für die Domänencontroller?

Alle diese Faktoren helfen die Anzahl der DCs innerhalb einer AD-Domäne festzulegen. Jedoch schließt das Installieren von mehreren DCs natürlich keineswegs eine regelmäßige Datensicherung des System-State aus. Diese muss ohnehin durchgeführt werden. Die Sicherung des Systemstatus ist das Mindeste, was auf einem DC gesichert werden muss!

Bei der Hardware der DCs kommt es insbesonders auf die CPU (welcher Prozessor und wie viele existieren?), Festplattenspeicher und vor allem dem Arbeitsspeicher an. Denn idealerweise sollte die Active Directory-Datenbank „NTDS.dit“ in den Arbeitsspeicher geladen werden können. Dabei läuft das Active Directory in dem LSASS Prozess.

Microsoft stellt auf der folgenden Seite seine Tests dar, die sie vor einigen Jahren mit HP-Proliant Servern durchgeführt hatten. Dort gewinnt man ebenfalls einige Anhaltspunkte zu der benötigten Anzahl an DCs.

Determining the Minimum Number of Domain Controllers Required>>>>>>>>>>>>

Weitere Ansätze über die Anzahl und Hardwareausstattung der DCs, liefern diese Seiten:

Step B2: Determine the Number of Domain Controllers
Planning Domain Controller Capacity: Active Directory

Größere Unternehmen mit mehreren Standorten sollten sich dieses Whitepaper durchlesen:

Windows Server 2003 Active Directory Branch Office Guide

>>
Oftmals ist es gerade in kleineren und mittleren Unternehmen so, das die Maschine die als einziger DC fungiert, nicht nur die Funktion eines DCs wahrnimmt. Dieser ist Datei- sowie Applikationsserver und wenn nicht sogar noch Mailserver zugleich (SBS). In diesen Umgebungen kann man sich oftmals keinen dedizierten zweiten DC leisten. Dabei reicht schon eine nicht ganz veraltete Client-Hardware aus, um auf diesem einen weiteren DC zu installieren (natürlich wird eine weitere Server-Lizenz benötigt). Falls dennoch kein zweiter DC installiert werden kann, ist umso mehr auf die regelmäßige und funktionierende System-State Sicherung zu achten.

Wenn es aber auf dem einzigen DC zu Performanceproblemen kommt, sollte eine Auslastungsanalyse über einen längeren Zeitraum durchgeführt werden (z.B. eine Woche). Dabei ist ein besonderes Augenmerk auf den Speicherverbrauch der Lsass.exe zu werfen. Erst nach der Analyse lässt sich ableiten, ob der DC überlastet bzw. die Hardware nicht ausreichend ist. Die Lösung könnte dann z.B. eine aktuelle Hardware, ein x64-DC oder ein weiterer DC sein. Wobei mit Blick auf das nächste Serverbetriebssystem, der Windows Server 2008 R2 ohnehin nur noch als x64-Bit Version ausgeliefert wird.

Weitere Informationen:
Memory usage by the Lsass.exe process on domain controllers that are running Windows Server 2003 or Windows 2000 Server

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Die FSMO-Rollen mit DCPROMO verschieben

Yusuf Dikmenoglu — Sun, 30 Nov 2008 20:12:42 GMT

Wenn ein Domänencontroller (DC) ausgetauscht wird, ist darauf zu achten, dass alle Dienste sowie Daten von einem anderen Server bzw. DC übernommen werden. Das trifft auch für die FSMO-Rollen zu. Falls der FSMO-Rolleninhaber ausgetauscht werden sollte, gilt es die FSMO-Rollen entweder durch die grafische Oberfläche oder durch das im Betriebssystem enthaltene Kommandozeilentool NTDSUTIL manuell zu verschieben.

Das händische verschieben der Rollen hat den Vorteil, dass der Administrator bestimmen kann auf welchen DC die Rollen verschoben werden. Somit weiß der Administrator genau, auf welchem DC sich die Rollen befinden. Ein weiterer Vorteil des manuellen Verschiebens wäre, falls ein Unternehmen AD-lastig arbeitet und die FSMO-Rollen somit mehr beansprucht werden, kann der Administrator die Rollen auf eine leistungsfähige Maschine verschieben oder ggf. auf mehrere DCs verteilen.

Die Rollen müssen aber nicht beim Herunterstufen des Rolleninhabers zwingend manuell verschoben werden. Denn die FSMO-Rollen werden mit Ausführen von DCPROMO seit Windows 2000 RTM, also seit der Einführung des Active Directory, während des DCPROMO-Vorgangs automatisch auf einen anderen DC übertragen. Die Rollen können aber nur dann einem anderen DC übergeben werden, wenn das DNS ordnungsgemäß funktioniert, sowie der Rolleninhaber Verbindung zur Domäne und somit zu seinen Replikationspartnern hat. Dabei geht der Rolleninhaber folgendermaßen vor:

Wurden die FSMO-Rollen vor dem herunterstufen nicht manuell verschoben, wird das „Operational Attribute“ GiveAwayAllFsmoRoles gesetzt. Das veranlasst den Rolleninhaber dazu, andere DCs ausfindig zu machen damit die Rollen die er trägt, auf einen anderen DC übertragen werden können.
Für die Wahl des zukünftigen Rolleninhabers werden die folgenden Regeln angewendet:

- Bevorzugt wird ein DC am gleichen Standort ausgewählt.
- Es wird ein DC zu dem eine RPC-Verbindung besteht gesucht.
- Es wird ein Server verwendet, zu dem eine asynchrone Verbindung (z.B. über das SMTP-Protokoll) existiert.
Natürlich können dabei die drei domänenspezifischen Rollen RID-Master, PDC-Emulator sowie Infrastrukturmaster nur innerhalb der Domäne verschoben werden.
Die beiden gesamtstrukturweiten Rollen Schemamaster sowie Domänennamenmaster können auf jeden DC in der Gesamtstruktur verschoben werden. Dabei spielt es keine Rolle, in welcher Domäne sie sich befinden.

Erreicht der Rolleninhaber während des Herunterstufens keinen weiteren DC, so schlägt zum einen das automatische Verschieben der Rollen und zum anderen das Herunterstufen fehl.

Wird der Rolleninhaber durch die erzwungene Herabstufung mit DCPROMO /Forceremoval heruntergestuft, so erhält der Administrator ab Windows Server 2003 SP1 für jede Rolle die der DC inne hat, eine Warnmeldung. Diese Rollen müssen dann im Nachhinein auf einem anderen DC offline übertragen werden.

Der Nachteil des automatischen Verschiebens der Rollen ist die nicht Vorhersagbarkeit der Ziel-DCs auf die die FSMO-Rollen verschoben werden (Ausnahme es existieren nur genau zwei DCs).

Doch auch bei dieser Variante müssen die Infrastrukturmasterrollen der Anwendungsverzeichnispartitionen ab Windows Server 2003 (wie z.B. ForestDNSZones und DomainDNSZones) manuell auf einen anderen DC verschoben werden. Diese werden nicht automatisch auf einen anderen DC übertragen. Näheres dazu erläutert der folgende Artikel:

Die Infrastrukturmaster der Anwendungsverzeichnispartitionen
>>
>

Weitere Informationen:
Die FSMO-Rollen verschieben
How Operations Masters Work: Active Directory
Flexible Single Master Operation Transfer and Seizure Process

Yusuf Dikmenoglu

Die Grenzen des Active Directory

Yusuf Dikmenoglu — Mon, 21 Apr 2008 08:23:05 GMT

An welchen Stellen stößt das Active Directory und seine Werkzeuge an die Grenzen?

Das "Active Directory-Benutzer und -Computer" Snap-In

>Falls in der MMC Active Directory-Benutzer und -Computer in einem Container bzw. OU mehr als 2000 Objekte enthalten sind,
wird die folgende Meldung angezeigt:

Screenshot vom Windows Server 2008

Anschließend kann dem Hinweis gefolgt und somit die maximale Anzahl der angezeigten Elemente erhöht werden.
Dieses Verhalten trifft auf Windows 2000, Windows Server 2003 und Windows Server 2008 zu.

Die maximal unterstützte Seitengröße für LDAP-Antworten>

Um sich z.B. vor Denial of Service (DoS) Attacken zu schützen, liefert das Active Directory bei einer LDAP-Abfrage
als Ergebnis 1.000 Datensätze. Übersteigt das Ergebnis die Grenze von 1.000 Datensätzen, wird nach den 1.000 Einträgen
der folgende Fehler angezeigt: Size Limit Exceeded Error.

Es bestehen zwei Möglichkeiten dieses Problem zu umgehen. Zum einen ist es das ändern der maximum Page Size auf dem
LDAP-Client und zum anderen, dass Erhöhen des Wertes MaxPageSize in den LDAP-Richtlinien auf den DCs.

How to view and set LDAP policy in Active Directory by using Ntdsutil.exe

Der Name einer Organisationseinheit (OU)>

Der Name einer OU kann maximal 64 Zeichen enthalten. Damit soll sichergestellt werden, dass beim aufrufen der Gruppenrichtlinien
die sich im SYSVOL-Verzeichnis befinden durch einen UNC-Pfad, nicht die Grenze von insgesamt 260 Zeichen überschritten wird.
Denn wenn der UNC-Pfad zu den GPOs 260 Zeichen überschreiten sollte, können somit die GPOs weder gelesen, noch an die DCs, Server und Clients angewendet werden.

Siehe auch:
Windows 2000 Supports Fully Qualified Domain Names up to 64 UTF-8 Bytes Long

Die Länge des Dateinamens

Der Pfad samt Dateiname der Active Directory-Datenbank (NTDS.dit), AD-Protokolldateien oder der GPOs die sich im
SYSVOL-Verzeichnis befinden, ist auf 260 Zeichen beschränkt.

Der NetBIOS-Computername

Der NetBIOS-Name eines Computerkontos ist auf 15 Zeichen beschränkt.
Eigentlich enthält dieser 16 Zeichen, wobei aber das 16. Zeichen für das System reserviert ist.
Der Computername darf auch nicht ausschließlich aus Zahlen bestehen.

Windows 2000 Does Not Permit All-Numeric Computer Names

Der NetBIOS-Name einer Domäne

Der NetBIOS-Name einer Domäne kann maximal 15 Zeichen enthalten.
Auch hier enthält der NetBIOS-Domänenname eigentlich 16 Zeichen,
wobei aber das 16. Zeichen ebenfalls für das System reserviert ist.

Die Länge des Fully Qualified Domain Name einer AD-Domäne

Der FQDN einer Active Directory-Domäne darf insgesamt 64 Zeichen (samt Punkten) enthalten.

Weitere Beschränkungen bezgl. der Namenskonventionen

Welche weiteren Beschränkungen bei den Namenskonventionen noch existieren, werden in diesem Artikel erläutert:

Naming conventions in Active Directory for computers, domains, sites, and OUs

Die maximale Anzahl an Objekten die ein Domänencontroller erstellen kann

Ein DC kann während seiner Lebensdauer etwas weniger als 2,15 Milliarden Objekte erstellen.

Die maximale Anzahl an SIDs die innerhalb einer Domäne erstellt werden kann

Innerhalb einer Domäne können ca. eine Milliarde Security Identifier (SIDs) erstellt werden.

Die maximale Anzahl an GPOs die auf ein Objekt wirken können

Es können maximal 999 Gruppenrichtlinienobjekte auf ein Benutzer- oder Computerkonto angewendet werden.
Dabei können auf einem System natürlich mehr als 999 GPOs existieren.
Diese Grenze wurde aus Performancegründen festgelegt.

Die maximale Anzahl an Benutzern pro Gruppe

Unter Windows 2000 kann eine Benutzergruppe maximal 5.000 Mitglieder enthalten.
Unter Windows Server 2003 existiert diese Grenze nicht.

Siehe auch: Die Linked Value Replikation (LVR)

Die maximale Anzahl an Änderungen innerhalb eines schreibvorgangs im AD

Werden automatisiert z.B. per Skript oder Management-Tools eine größere Menge an Änderungen im Active Directory
durchgeführt (z.B. das erstellen, löschen oder bearbeiten von Benutzern), können innerhalb einer Transaktion nicht mehr
als 5.000 Änderungen durchgeführt werden.

Die maximale Gruppenzugehörigkeiten eines Sicherheitsprinzipals

In das Access-Token eines Sicherheitsprinzipals wie es z.B. Benutzer, Gruppen oder Computer darstellen,
können maximal 1.024 Einträge existieren. Bei der Anmeldung eines Benutzers wird vom Local Security Authority (LSA)
ein Access-Token generiert. In diesem Access-Token befindet sich der Security Identifier (SID) des Benutzers,
die SIDs der direkten Gruppen in denen das Benutzerkonto Mitglied ist, die SIDs von Gruppenverschachtelungen und in einer
Windows Server 2003 Umgebung noch die SID History. Befindet sich der Benutzer in mehr als 1.024 Gruppen, so schlägt die
Authentifizierung des Benutzers fehl.

Tatsächlich sollte sich das Benutzerkonto nicht in mehr als 1.015 Gruppen befinden, denn vom LSA werden standardmäßig
bis zu 9 Well-Known SIDs dem Access-Token hinzugefügt.

Users Who Are Members of More Than 1,015 Groups May Fail Logon Authentication

In der Praxis hat sich allerdings gezeigt, dass bereits Probleme auftauchen, in denen der Benutzer sich in weitaus
weniger Guppen befindet. Unter Windows 2000 - dort je nach SP-Stand - kann es schon bei Gruppenmitgliedschaften
zwischen 70-80 bzw. 120 Gruppenmitgliedschaften zu Problemen kommen.

Group Policy may not be applied to users belonging to many groups
New resolution for problems with Kerberos authentication when users belong to many groups

Unter Windows Server 2003 kann es ebenfalls zu Problemen kommen, wenn sich der Benutzer
in weitaus mehr als 70 Gruppen befindet:

Authentication Fails Due to User PAC
Troubleshooting Kerberos Errors
When you try to log on to a Windows Server 2003-based domain by using a domain user account, the logon request fails
What's in a Token

Die empfohlene maximale Anzahl an Domänen innerhalb einer Gesamtstruktur

In einer Windows 2000 Gesamtstruktur wird empfohlen, nicht mehr als 800 Domänen zu betreiben.
Die empfohlene Anzahl an Domänen innerhalb einer Windows Server 2003 Gesamtstruktur, die sich in der
Gesamtstrukturfunktionsebene „Windows Server 2003“ befindet, ist auf 1.200 Domänen beschränkt.
Diese Grenze gilt sicherlich auch für eine Windows Server 2008 Gesamtstruktur.

Die empfohlene Anzahl an Domänencontrollern pro Domäne

Die unterstützte Anzahl an Domänencontrollern innerhalb einer Windows Server 2003-Domäne beträgt 1.200.
Diese Grenze wurde festgelegt, damit im Windows Server 2003 das SYSVOL-Verzeichnis, das durch das
File Replication Service (kurz, FRS) repliziert wird, noch ordnungsgemäß rückgesichert werden kann.
Dabei kann es bereits bei über 400 DCs pro Domäne zu problemen kommen, wenn das DNS auf den DCs betrieben
wird und der AD-integirerte DNS-Name mit dem AD-Namen der Domäne gleich lautet.

Problems with Many Domain Controllers with Active Directory Integrated DNS Zones

Weitere Informationen:
Active Directory Maximum Limits

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.