Blog Home  Home Feed your aggregator (RSS 2.0)  
LDAP://Yusufs.Directory.Blog/ - Wednesday, September 09, 2009
Wieviele Sprachen sprechen Sie? Ich spreche bloß eine: LDAP!
 
 Wednesday, September 09, 2009

In kleineren AD-Umgebungen wie sie in „kleineren und mittleren Unternehmen (kurz KMU)“ existieren, weiß der Administrator in welchen Containern im AD sich die entsprechenden AD-Objekte befinden. Doch in größeren und verteilten AD-Umgebungen mit mehreren AD-Administratoren lässt sich das nicht jederzeit sagen.
 

Um ein AD-Objekt ausfindig zu machen gibt es je nach Betriebssystem verschiedene Möglichkeiten den Distinguished Name (DN) und somit den LDAP-Pfad des gesuchten Objekts mit Bordmitteln anzuzeigen. Der DN gibt dabei den Speicherort des Objekts im AD an.

 

 

 

Die Active Directory Suche in der MMC Active Directory-Benutzer und -Computer (dsa.msc)

 

Bei der AD-Suche hat man zwei Möglichkeiten den Speicherort des Objekts herauszufinden.

 

 

Erste Möglichkeit

 

In der MMC dsa.msc ruft man mit einem Rechtsklick auf den Domänennamen das Suchfenster auf und gibt z.B. den Common Name (CN) oder sAMAccountName (falls bekannt) des Objekts ein. Es reichen bereits die Anfangsbuchstaben aus wie z.B. „Yus“, um Objekte aufzufinden die mit "Yus" anfangen, da bei der Suche die Ambiguous Name Resolution (ANR) angewendet wird. Die ANR durchforstet bei der Suche unter anderem die folgenden Felder: Vorname, Nachname, Anzeigename sowie den Benutzeranmeldename (Prä-Windows 2000). 

Ist die Suche beendet, gilt es im Suchfenster unter
Ansicht - Spalten auswählen… eine weitere Spalte hinzuzufügen. Der Name dieser Spalte unterscheidet sich jedoch zwischen den Betriebssystemen.

 

Unter Windows 2000 und Windows Server 2003 heißt die Spalte X500-definierter Name, unter Windows Server 2008 Definierter Name und unter Windows Server 2008 R2 Distinguished Name. Nach dem hinzufügen der Spalte erscheint im Suchergebnis der DN des Objekts.

 


 

Es ist auch möglich die AD-Suche direkt aufzurufen, ohne die MMC Active Directory-Benutzer und -Computer zu öffnen. Dazu gilt es mit einem Rechtsklick auf einer freien Fläche auf dem Desktop die Option Neu und anschließend Verknüpfung auszuwählen. Als "Speicherort des Elements" gilt es diesen Eintrag hinzuzufügen: %windir%\System32\rundll32.exe dsquery.dll,OpenQueryWindow (<-- ACHTUNG: Die Schreibweise von "OpenQueryWindow" ist "case sensitive"). Im nächsten Schritt gilt es lediglich noch einen Namen für die Verknüpfung zu vergeben und fertig ist die direkte Verknüpfung zur AD-Suche.


 

 

Zweite Möglichkeit

 

Im ersten Schritt ist in der MMC dsa.msc unter Ansicht die Option Erweiterte Funktionen zu aktivieren. Danach gilt es wie in der ersten Möglichkeit im Suchfenster nach dem gewünschten Objekt zu suchen. Ist die Suche beendet, ruft man im zweiten Schritt mit einem Doppelklick auf das Objekt die Eigenschaften auf und wechselt zum Reiter Objekt. Dort wird der kanonische Name des Objekts angezeigt. Liest man diesen in umgekehrter Reihenfolge (von rechts nach links), so lässt sich der DN des Objekts ableiten.

 

 

 


 


Das Kommandozeilentool: DSQUERY

 

Mit dsquery das erst ab Windows Server 2003 „on Bord“ zur Verfügung steht, lässt sich der DN eines Objekts wie folgt anzeigen:

 

dsquery computer -name <CN des Computers>

dsquery user -name <CN des Benutzers>
dsquery group -name <CN der Gruppe>

dsquery contact -name <CN des Kontaktobjekts>

 


Auch bei dsquery können Wildcards verwendet werden.

Lautet der Common Name (CN) eines Benutzerobjekts “Yusuf Dikmenoglu”, so kann der Befehl folgendermaßen aussehen:

 

dsquery user -name *us*f*

 


Standardmäßig durchsucht das dsquery die Domäne in der man den Befehl ausführt. Gibt man den folgenden Befehl an, so durchsucht das dsquery mit Hilfe eines globalen Katalogs (GC) nach dem gewünschten Objekt innerhalb der Gesamtstruktur, also über alle Domänen hinweg:

 

dsquery user Forestroot -name Yusuf*

 


Wenn der
sAMAccountName des gesuchten Benutzerobjekts bekannt ist (Benutzeranmeldename Prä-Windows 2000), lautet die Abfrage wie folgt:

dsquery user -samid Yusuf

 


Ist der userPrincipalName (UPN) eines Benutzerkontos bekannt, so gilt es diese Abfrage durchzuführen um den DN anzuzeigen:


dsquery user -upn Yusuf@blog.dikmenoglu.de

 

 

 

 

Die AD-PowerShell unter Windows Server 2008 R2

 

In der AD-PowerShell die ab Windows Server 2008 R2 on Bord ist, lässt sich der DN des gesuchten Objekts mit diesem Befehl anzeigen:

 

Get-ADComputer <Computername>
Get-ADUser <sAMAccountName>
Get-ADGroup <Gruppe>

 

 

Die AD-PowerShell steht auch auf einem Windows 7 zur Verfügung, aber erst nach der Installation der Remote Server Administration Tools (RSAT).

 

 


Das Active Directory-Verwaltungscenter unter Windows Server 2008 R2

Führt man im AD-Verwaltungscenter (ADAC) eine globale Suche nach einem Objekt durch, wird im Suchergebnis ebenfalls direkt der DN mit angezeigt. Auch im ADAC kann man eine Suche mit Hilfe eines GC durchführen und so nach einem Objekt innerhalb der Gesamtstruktur suchen.



 

 

 

 

Weitere Informationen:
Gespeicherte Abfragen
Active Directory - Abfrage
AD-PowerShell Befehle
Das Active Directory-Verwaltungscenter
Die Active Directory-Attribute hinter den Feldnamen
Ambiguous Name Resolution for LDAP in Windows 2000
Remoteserver-Verwaltungstools für Windows 7

Wednesday, September 09, 2009 5:16:47 PM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Erweiterte Abfragen  | 
 Saturday, August 22, 2009

Die FSMO-Rollen lassen sich ab Windows Server 2008 R2 neben der grafischen Oberfläche (GUI) und neben der Kommandozeile (CMD) mit NTDSUTIL, auch über die AD-Powershell auf einen anderen DC verschieben.

Das Verschieben der FSMO-Rollen mit der AD-Powershell hat folgende Vorteile:

  • Es muss nicht wie in der GUI oder in der Kommandozeile mit NTDSUTIL zuerst eine Verbindung zum zukünftigen Rolleninhaber hergestellt werden.

  • Mit dem gleichen AD-Powershell Befehl, lediglich beim „seizen“ (Rolleninhaber ist offline) der FSMO-Rollen wird ein zusätzlicher Parameter benötigt, können die FSMO-Rollen „online“ sowie „offline“ an einen anderen DC übergeben werden.

  • Das verschieben der FSMO-Rollen muss nicht zwingend vom Rolleninhaber oder dem zukünftigen Rolleninhaber durchgeführt werden. Stattdessen kann das Verschieben der Rollen von einem Windows 7 Client oder Windows Server 2008 R2 Mitgliedsserver durchgeführt werden, worauf das RSAT installiert ist.



Die FSMO-Rollen werden mit dem Cmdlet Move-ADDirectoryServerOperationMasterRole auf einen anderen DC verschoben.

Wenn der Rolleninhaber funktionstüchtig und online ist, können die FSMO-Rollen mit dem folgenden AD-Powershell Befehl an den angegebenen DC übertragen werden. Übertragen bedeutet in diesem Zusammenhang, dass der ursprüngliche Rolleninhaber funktionsfähig und online ist.

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole SchemaMaster,RIDMaster,InfrastructureMaster,DomainNamingMaster,PDCEmulator

Bei der Angabe des Ziel-DCs muss ausschließlich der Computername angegeben werden.
Anstatt die Namen der Betriebsmasterrollen einzugeben, können auch Zahlen angegeben werden. Also entweder:

PDCEmulator oder 0
RIDMaster
oder 1
InfrastructureMaster
oder 2
SchemaMaster
oder 3
DomainNamingMaster
oder 4


Demnach kann man auch mit diesem Befehl alle FSMO-Rollen auf einen anderen DC übertragen:

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 0,1,2,3,4


Falls jedoch der aktuelle Rolleninhaber ausfällt und das Übertragen der FSMO-Rollen „online“ nicht mehr durchgeführt werden kann, können mit der AD-Powershell die ausgefallenen Betriebsmasterrollen ebenfalls mit dem gleichen Powershell-Befehl, nur zusätzlich mit dem Parameter /Force (sprich „mit Gewalt“) von einem anderen DC übernommen werden. Mit einem der folgenden Befehle werden alle FSMO-Rollen von dem angegebenen DC übernommen:

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole SchemaMaster,RIDMaster,InfrastructureMaster,DomainNamingMaster,PDCEmulator -Force

Bzw.:

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 0,1,2,3,4 -Force


Die beiden Gesamtstrukturmasterrollen „Schemamaster“ sowie „Domänennamenmaster“ können auch auf einen DC einer Subdomäne übertragen oder von einem DC einer Subdomäne übernommen werden. Zum verschieben der FSMO-Rollen muss das Benutzerkonto Mitglied in den folgenden Gruppen sein:

- Schemamasterrolle: Mitglied in der Gruppe „Schema-Admins“
- Domänennamenmaster: Mitglied in der Gruppe „Organisations-Admins“.
- RID-Master: Mitglied in der Gruppe „Domänen-Admins“.
- PDC-Emulator: Mitglied in der Gruppe „Domänen-Admins“.
- Infrastrukturmaster: Mitglied in der Gruppe „Domänen-Admins“.




Den PDC-Emulator über die AD-Powershell verschieben

- Ist der Rolleninhaber online, so kann die Rolle des PDC-Emulators wie folgt verschoben werden:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole PDCEmulator

Oder mit:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 0



- Wenn jedoch der Rolleninhaber nicht mehr zur Verfügung steht (z.B. bei einem DC-Crash), so kann die PDC-Emulatorrolle folgendermaßen von dem angegebenen DC übernommen werden:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole PDCEmulator -Force

Bzw. mit:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 0 -Force




Den RID-Master über die AD-Powershell verschieben

- Die Betriebsmasterrolle „RID-Master“ wird mit einem der folgenden Befehle auf einen anderen DC übertragen, sofern der aktuelle Rolleninhaber online ist:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole RIDMaster

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 1


- Ist dagegen der aktuelle Rolleninhaber offline, so wird die Rolle des RID-Masters mit einem dieser Befehle von einem anderen DC übernommen:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole RIDMaster -Force

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 1 –Force



 

Den Infrastrukturmaster über die AD-Powershell verschieben

- Die Infrastrukturmasterrolle  kann mit einem der folgenden Befehle online auf einen anderen DC übertragen werden:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole InfrastructureMaster

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 2


- Offline kann der Infrastrukturmaster wie folgt von einem anderen DC mit einem dieser Befehle übernommen werden:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole InfrastructureMaster -Force

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 2 -Force


Der Infrastrukturmaster der Anwendungsverzeichnispartitionen muss zusätzlich noch auf einen anderen DC verschoben oder von einem anderen DC übernommen werden.

Die Infrastrukturmaster der Anwendungsverzeichnispartitionen




Den Schemamaster über die AD-Powershell verschieben

- Der Schemamaster wird mit einem dieser Befehle auf einen anderen DC übertragen:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole SchemaMaster

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 3


- Steht der Rolleninhaber nicht mehr zur Verfügung, übernimmt ein anderer DC die Schemamasterrolle mit einem dieser Befehle:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole SchemaMaster -Force

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 3 -Force

 


Den Domänennamenmaster über die AD-Powershell verschieben

Die Rolle „Domänennamenmaster“ wird online mit einem dieser Befehle auf einen anderen DC übertragen:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole DomainNamingMaster

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 4


- Der Domänennamenmaster wird mit einem dieser Befehle von einem anderen DC übernommen, wenn der aktuelle Rollenträger ausgefallen ist:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole DomainNamingMaster -Force

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 4 -Force

 

Ist auf einem Windows Server 2003 DC oder Windows Server 2008 DC das AD MGS installiert, können die FSMO-Rollen auch auf diese DCs übertragen bzw. von diesen übernommen werden.

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

 

Die FSMO-Rollenträger in der AD-Powershell lassen sich mit diesen Befehlen anzeigen:

Get-ADForest | select SchemaMaster,DomainNamingMaster

Get-ADDomain | select PDCEmulator,RIDMaster,Infrastructuremaster


 

Weitere Informationen:
Die FSMO-Rollen verschieben
Die FSMO-Rollen mit DCPROMO verschieben
Die Metadaten des Active Directory unter Windows Server 2008 bereinigen
Active Directory Administration with Windows PowerShell

Saturday, August 22, 2009 10:44:12 AM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | AD-Powershell  | 
 Sunday, August 09, 2009

Neben den grafischen Werkzeugen wie z.B. Active Directory-Benutzer und -Computer (dsa.msc), Active Directory-Standorte und -Dienste (dssite.msc) etc. oder den ds*-Kommandozeilentools (dsadd, dsget, dsquery…) steht im Windows Server 2008 R2 erstmals die AD-PowerShell zur Verfügung. In der AD-PowerShell werden dem Administrator 76 AD-Cmdlets mit geliefert.

Die AD-PowerShell ist nicht von der RPC- oder LDAP-Schnittstelle abhängig, sondern von dem Dienst Active Directory-Webdienste (ADWS) (wie auch das AD-Verwaltungscenter), das erst ab Windows Server 2008 R2 zur Verfügung steht.

Mit der AD-PowerShell lässt sich eine Active Directory-Umgebung unter Windows Server 2003, Windows Server 2008 und Windows Server 2008 R2 administrieren. Des Weiteren kann man AD LDS-Instanzen oder „configuration sets“ und AD-Snapshots mit der AD-PowerShell verwalten.

Doch bevor eine Windows Server 2003 oder Windows Server 2008 Domäne mit der AD-PowerShell von einem Windows 7 Client oder Windows Server 2008 R2 worauf jeweils das RSAT installiert ist, administriert werden kann, muss vorher das Active Directory Management Gateway Service (AD MGS) auf einem Windows Server 2003 DC oder Windows Server 2008 DC installiert werden. Das AD MGS ist das ADWS für Windows Server 2003 und Windows Server 2008.

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


Zu finden ist die AD-PowerShell unter Start – Verwaltung – Active Directory Module for Windows PowerShell.
Für die Freunde der grafischen Oberfläche hat Redmond ebenfalls vorgesorgt. Im Server Manager existiert das Feature Windows PowerShell Integrated Scripting Environment (ISE), mit dem dem Administrator eine PowerShell-Entwicklungsumgebung zur Verfügung steht. Nach der Installation steht die Powershell-Entwicklungsumgebung unter Start - Alle Programme - Zubehör - Windows Powershell zur Verfügung. Doch bevor mit dem ISE auf das AD zugegriffen werden kann, müssen vorher mit dem Befehl import-module activedirectory die AD-Cmdlets geladen werden. Anschließend kann der Administrator im ISE seine AD-PowerShell-Skripte erstellen, die mit der Endung „.ps1“ zu speichern sind.

Dadurch das die AD-PowerShell pipeline-fähig ist und sich so verschiedene Cmdlets miteinander verbinden lassen, stellt die AD-PowerShell ein mächtiges Werkzeug dar. Sei es zur täglichen Administration oder bei immer wiederkehrenden Automatisierungsaufgaben, die AD-PowerShell eignet sich in jedem Fall. Mit der AD-PowerShell können in einer einzigen Konsole viele Aufgaben durchgeführt werden, wozu in früheren Betriebssystemversionen mehrere Werkzeuge bzw. MMCs notwendig waren.

Mit der AD-PowerShell ist es auch möglich, wie in einer Kommandozeile (CMD) in der man durch die Verzeichnisse navigiert, durch das AD zu navigieren. In der AD-PowerShell wechselt man mit cd AD: in die AD-Ebene. Dort kann man dann mit dem Befehl cd „DC=blog,DC=dikmenoglu,DC=de“ auf die Domänenpartitionsebene wechseln und mit dir sich die Container die sich darunter befinden anzeigen lassen. Natürlich kann man auch auf jede andere Verzeichnispartition wie z.B. die Konfigurations- oder Schemapartition durch die Angabe des Distinguished Names (DN) der entsprechenden Verzeichnispartition wechseln.




Auch kann man auf diesem Weg z.B. eine neue OU erstellen. Mit dem Befehl md „OU=Neue OU“ kann man auf der Ebene auf der man sich befindet eine neue OU erstellen.





Wenn man in der AD-PowerShell Skripte einsetzen möchte, wird das unter Umständen fehlschlagen. Denn das Ausführen von Skripten wird von der Ausführungsrichtlinie, der sogenannten Execution Policy bestimmt. Damit Skripte ausgeführt werden dürfen, muss mit dem PowerShell-Befehl
Set-ExecutionPolicy Remotesigned die Ausführungsrichtlinie angepasst werden. Mit dem Parameter Remotesigned wird definiert, dass Skripte die aus dem Internet oder von anderen öffentlichen Orten stammen, signiert sein müssen. Jedoch dürfen lokal gespeicherte Skripte ohne Signatur ausgeführt werden.

Weitere Informationen zum digitalen signieren von Skripten werden im folgenden Artikel beschrieben:

http://technet.microsoft.com/en-us/magazine/2008.04.powershell.aspx?pr=blog


Weitere Informationen zur AD-PowerShell:

Die AD-Powershell im Windows Server 2008 R2




Die AD-Commandlets (kurz Cmdlets) die zur Verfügung stehen

Die Cmdlets sind durch ihre Namen weitestgehend selbsterklärend. Die unten aufgeführten Cmdlets kann man sich mit dem Befehl get-command anzeigen lassen, wie z.B. get-command get-ad*, get-command new-ad* oder get-command remove-ad* usw. Alle AD-Cmdlets werden mit diesem Befehl angezeigt: Get-Command *-ad*

Eine ausführliche und detaillierte Hilfe zu den folgenden Cmdlets lässt sich wie folgt anzeigen:

- Get-Help <Cmdlet Name> -Detailed (z.B. Get-Help Search-ADAccount -Detailed)
-
Get-Help <Cmdlet Name> -Examples
-
Get-Help <Cmdlet Name> -Full


Die Hilfe zu den Filtermöglichkeiten lässt sich mit diesem Befehl aufrufen:
get-help about_ActiveDirectory_Filter



AD-Objekte abrufen (22 Cmdlets)

- Get-ADAccountAuthorizationGroup
- Get-ADAccountResultantPasswordReplicationPolicy
- Get-ADComputer
- Get-ADComputerServiceAccount
- Get-ADDefaultDomainPasswordPolicy
- Get-ADDomain
- Get-ADDomainController
- Get-ADDomainControllerPasswordReplicationPolicy
- Get-ADDomainControllerPasswordReplicationPolicyUsage
- Get-ADFineGrainedPasswordPolicy
- Get-ADFineGrainedPasswordPolicySubject
- Get-ADForest
- Get-ADGroup
- Get-ADGroupMember
- Get-ADObject
- Get-ADOptionalFeature
- Get-ADOrganizationalUnit
- Get-ADPrincipalGroupMembership
- Get-ADRootDSE
- Get-ADServiceAccount
- Get-ADUser
- Get-ADUserResultantPasswordPolicy

 

AD-Objekte erstellen (7 Cmdlets)

- New-ADComputer
- New-ADFineGrainedPasswordPolicy
- New-ADGroup
- New-ADObject
- New-ADOrganizationalUnit
- New-ADServiceAccount
- New-ADUser

 

AD-Objekte entfernen (12 Cmdlets)

- Remove-ADComputer
- Remove-ADComputerServiceAccount
- Remove-ADDomainControllerPasswordReplicationPolicy
- Remove-ADFineGrainedPasswordPolicy
- Remove-ADFineGrainedPasswordPolicySubject
- Remove-ADGroup
- Remove-ADGroupMember
- Remove-ADObject
- Remove-ADOrganizationalUnit
- Remove-ADPrincipalGroupMembership
- Remove-ADServiceAccount
- Remove-ADUser

 

AD-Schreibvorgänge durchführen (15 Cmdlets)

- Set-ADAccountControl
- Set-ADAccountExpiration
- Set-ADAccountPassword
- Set-ADComputer
- Set-ADDefaultDomainPasswordPolicy
- Set-ADDomain
- Set-ADDomainMode
- Set-ADFineGrainedPasswordPolicy
- Set-ADForest
- Set-ADForestMode
- Set-ADGroup
- Set-ADObject
- Set-ADOrganizationalUnit
- Set-ADServiceAccount
- Set-ADUser

 

AD-Objekte hinzufügen (5 Cmdlets)

- Add-ADComputerServiceAccount
- Add-ADDomainControllerPasswordReplicationPolicy
- Add-ADFineGrainedPasswordPolicySubject
- Add-ADGroupMember
- Add-ADPrincipalGroupMembership


AD-Objekte und optionale AD-Funktionen deaktivieren (2 Cmdlets)

- Disable-ADAccount
- Disable-ADOptionalFeature

 

AD-Objekte und optionale AD-Funktionen aktivieren (2 Cmdlets)

- Enable-ADAccount
- Enable-ADOptionalFeature



AD-Objekte verschieben (3 Cmdlets)

- Move-ADDirectoryServer
- Move-ADDirectoryServerOperationMasterRole
- Move-ADObject

 

AD-Objekte umbenennen (1 Cmdlet)

- Rename-ADObject

 

AD-Dienstkontenkennwörter zurücksetzen (1 Cmdlet)

- Reset-ADServiceAccountPassword


 

AD-Objekte wiederherstellen (1 Cmdlet)

- Restore-ADObject

 

AD-Objekte suchen (1 Cmdlet)

- Search-ADAccount

 

AD-Dienstkonto deinstallieren (1 Cmdlet)

- Uninstall-ADServiceAccount

 

AD-Objekt entsperren (1 Cmdlet)

- Unlock-ADAccount

 

AD-Kontoablaufdatum zurücksetzen (1 Cmdlet)

- Clear-ADAccountExpiration

 

AD-Dienstkonto installieren (1 Cmdlet)

- Install-ADServiceAccount

 

 

AD-PowerShell „Benutzerobjekt“ Befehle

Mit dem Cmdlet Get-ADUser lassen sich Benutzerinformationen abfragen. Je nach Angabe der Suchkriterien werden bei der Abfrage ein oder mehrere Benutzerobjekte mit den gewünschten Attributen angezeigt. Mit dem Befehl Get-ADUser Yusuf werden standardmäßig die folgenden Werte angezeigt: DistinguishedName, Enabled, givenName, Name, ObjectClass, ObjectGUID, SamAccountName, ObjectSID, Surname, userPrincipalName

Bei allen PowerShell-Befehlen kann bei der Angabe von <Benutzer> zwischen den folgenden Angaben gewählt werden:

- sAMAccountName
- Distinguished Name (DN)
- ObjectSID
- ObjectGUID

Die Abfrage
Get-ADUser „CN=Yusuf,OU=IT,DC=blog,DC=dikmenoglu,DC=de“, Get-ADUser S-1-5-21-2225156702-1871195563-4034089934-1101 oder Get-ADUser 6e90b6c6-0fc6-4aab-af7f-73b74f937980 liefern alle das gleiche Ergebnis.


Hinweis: Um die Funktion der Befehle sicherzustellen, ist es empfehlenswert die Befehle händisch einzutippen anstatt sie zu kopieren!


# Soll sich die Abfrage auf eine bestimmte OU (samt Unter-OUs) beschränken, so kann das mit dem Parameter
–Searchbase und der Angabe des DN der OU durchgeführt werden.
Get-ADUser –LDAPFilter „(givenName=Yusuf)“ –SearchBase „OU=IT,DC=Domäne,DC=de“


# Zum Erhöhen der Suchleistung sollte man den Suchbereich auf ein einziges Objekt oder auf eine Objektteilmenge beschränken. Für diese Aufgabe stellt die DirectorySearcher-Klasse die SearchScope-Eigenschaft bereit. Der Suchbereich lässt sich auf eine der folgenden drei Einstellungen festlegen:

- Base: Hier wird das Objekt durchsucht, mit dem man verbunden ist. Wenn man sich z.B. mit einer OU verbunden hat, wird nur diese eine OU durchsucht und nicht noch zusätzlich die evtl. bestehenden Unter-OUs.

- OneLevel: Mit dieser Option werden alle Objekte die sich direkt, also eine Ebene tiefer, unter der Suchbasis befinden durchsucht.

- Subtree: Durchsucht alle Objekte, die in der Teilstruktur des verbundenen Objekts enthalten sind. Dabei werden alle Container im aktuellen Pfad und unterhalb der Suchbasis durchsucht.


Mit der Angabe des Parameters –SearchScope, lässt sich die Abfrage im vorherigen Beispiel ausschließlich auf die angegebene OU beschränken:
Get-ADUser –LDAPFilter „(givenName=Yusuf)“ –SearchBase „OU=IT,DC=Domäne,DC=de“ –SearchScope OneLevel

# Welche Benutzerkontoeigenschaften angezeigt werden, lässt sich mit dem Parameter –Properties beeinflussen. Wird beim Parameter –Properties als Wert ein Wildcard „*“ verwendet, so lassen sich alle Benutzerkontoeigenschaften anzeigen die im Benutzerobjekt enthalten sind:
Get-ADuser <Benutzer> -Properties *


# Möchte man sich bei einem bestimmten Benutzer neben den standardmäßig angezeigten Werten lediglich als weitere Benutzereigenschaft die Personalnummer, die Attribute
employeeID und employeeNumber anzeigen lassen, so lautet der Befehl
Get-ADUser <Benutzer> –Properties employeeID,employeeNumber


# Alle Benutzerkonten in der Domäne anzeigen
Get-ADUser –Filter *


# Alle AD-Objekte anzeigen
Get-ADObject –Filter { ObjectClass –Like „*“ }


# Alle Benutzerkonten einer bestimmten OU im Spaltenformat anzeigen
Get-ADUser –Filter * -Searchbase „OU=<OU>,DC=Domäne,DC=de“ | FT


# Alle Benutzer in der Domäne mit dem Vornamen „Yusuf“ anzeigen
Get-ADUser –LDAPFilter „(givenName=Yusuf)“


# Alle Benutzerkonten in der Domäne mit der Personalnummer im Spaltenformat anzeigen
Get-ADUser -Filter * -Properties employeeID,employeeNumber | FT


# Mit einer Ambiguous Name Resolution (kurz ANR) die Benutzer anzeigen, die im Vornamen, Nachnamen oder sAMAccountName den Eintrag „Yus“ enthalten
Get-ADUser –Filter { ANR –eq „Yus“ }


# Alle Benutzerkonten aus „Mainz“ anzeigen
Get-ADUser –Filter {City –Like „Mainz“}


# Alle Benutzerkonten mit dem Vornamen „Yusuf“ anzeigen
Get-ADUser –Filter {givenName –Like „Yusuf“} | FT


# Alle Benutzerkonten mit dem Nachnamen „Dikmenoglu“ anzeigen
Get-ADUser –Filter {Surname –Like „Dikmenoglu“}


# Alle Benutzerkonten aus der Abteilung „EDV“ anzeigen
Get-ADUser –Filter {Department –Like „EDV“}


# Alle Benutzerkonten anzeigen die in ihrem „Common Name“ irgendwo den Eintrag „Yus“ haben
Get-ADUser –Filter { CN –Like „*Yus*“ }


# Alle Benutzer die einen Wert im Attribut
mail eingetragen haben anzeigen
Get-ADUser –Filter { mail –Like „*“ }

oder

Get-ADObject –Filter { mail –Like „*“ –and ObjectClass –eq “user” }


# Alle Benutzer die einen Wert im Attribut
mail eingetragen haben und mit Nachname „Dikmenoglu“ lauten anzeigen
Get-ADUser –Filter { mail –Like „*“ –and Surname –eq „dikmenoglu“ }

oder

Get-ADUser –Filter { mail –Like „*“ –and sn –eq „dikmenoglu“ }


# Alle Benutzerkonten die keinen Wert im Attribut
mail eingetragen haben anzeigen
Get-ADUser –Filter { mail –notlike „*“ }

Oder
Get-ADUser –LDAPFilter „(!(email=*))“


# Alle Benutzerkonten die im Common Name mit „Yusuf“ oder „Kaan“ beginnen anzeigen
Get-ADUser -Filter { CN -like "Yusuf*" -or CN -eq "Kaan"

oder

Get-ADObject -Filter { objectClass -eq "user" -and (CN -like "Yusuf*" -or CN -eq "Kaan") }


# Die Gruppenmitgliedschaften eines Benutzers anzeigen
Get-ADPrincipalGroupMembership Yusuf


# Alle Benutzerkonten anzeigen, die als Vorgesetzten „Yusuf“ eingetragen haben
Get-ADUser -Filter { Manager -eq "Yusuf" }


# Die direkten Gruppenmitgliedschaften samt der „primären Gruppe“ eines Benutzers anzeigen
Get-ADUser Yusuf –Properties primarygroupID,memberof


# Den Benutzer aus einer Gruppe entfernen
Remove-ADPrincipalGroupMembership Yusuf –MemberOf „Gruppe“


# Den Benutzer bis auf die primäre Gruppe, aus allen Gruppen entfernen
Get-ADPrincipalGroupMembership Yusuf | % {Remove-ADPrincipalGroupMembership Yusuf -MemberOf $_}


# Den Benutzer Kaan zu den gleichen Gruppen hinzufügen, in denen Yusuf Mitglied ist
Get-ADPrincipalGroupMembership Yusuf | % {Add-ADPrincipalGroupMembership Kaan -MemberOf $_}


# Alle Benutzerkonten anzeigen, die sich in den letzten 10 Tagen angemeldet haben
$date = (get-date) – (new-timespan –days 10)
Get-ADUser –Filter { lastlogon –gt $date }

Ein anderer Befehl mit dem die Benutzer angezeigt werden, die sich in den letzten 5 Tagen an der Domäne angemeldet haben ist dieser:
Get-ADUser –LDAPFilter „(&(LastLogon>=128812906535515110)(objectCategory=user))“


# Alle Benutzer anzeigen die sich in den letzten 50 Tagen nicht angemeldet haben
$Vorvielentagen = (Get-Date).AddDays(-50)
Get-ADUser -Filter { lastLogonTimeStamp -notlike "*" -or  lastLogonTimeStamp -le $Vorvielentagen }


# Alle Benutzerkonten die mehr als vier Mal ihr Kennwort falsch eingegeben haben anzeigen
Get-ADUser –LDAPFilter „(badPwdCount>=4)“

Oder
Get-ADUser –Filter {badPwdCount –ge 4}


# Einen Benutzer deaktivieren
Disable-ADAccount Yusuf


# Einen Benutzer aktivieren
Enable-ADAccount Yusuf


# Einen deaktivierten Benutzer im Container USERS erstellen

New-ADUser Yusuf


# Einen aktivierten Benutzer in der angegebenen OU mit mehreren Werten erstellen
New-ADUser –sAMAccountName „Yusuf“ –UserPrincipalName Yusuf@ad.dikmenoglu.de –givenname “Yusuf” –Surname “Dikmenoglu” –displayName “Yusuf Dikmenoglu” –Name “Yusuf Dikmenoglu” –scriptpath “login.bat” –Enabled $true –Path “OU=<OU>,DC=Domäne,DC=DE” –AccountPassword (ConvertTo-Securestring “Pa$$w0rd!” –asplaintext –Force)


# Ein Benutzerkonto mit allen Eigenschaften kopieren und im Container USERS erstellen
PS C:\> $Groups = Get-ADPrincipalGroupMembership "Yusuf"
PS C:\>
Get-ADUser "Yusuf" -Properties * | New-ADUser -Name "Benutzer2" -Displayname "Benutzer2" -samaccountname "Benutzer2" -accountpassword (ConvertTo-SecureString "Pa$$w0rd!" -AsPlainText –Force)
PS C:\>Add-ADPrincipalGroupMembership "Benutzer2" -memberOf $Groups


# Ein Benutzerkonto nur mit bestimmten Attributen kopieren und im Container USERS erstellen
PS C:\> $Groups = Get-ADPrincipalGroupMembership "Yusuf"
PS C:\>
Get-ADUser "Yusuf" -Properties profilPath, scriptPath, accountExpires | New-ADUser -Name "Benutzer2" -Displayname "Benutzer2" -samaccountname "Benutzer2" -accountpassword (ConvertTo-SecureString "Pa$$w0rd!" -AsPlainText –Force)
PS C:\>Add-ADPrincipalGroupMembership "Benutzer2" -memberOf $Groups


# 50 aktivierte Benutzerkonten in einer bestimmten OU erstellen
(1..50) | Foreach-Object {New-ADUser –sAMAccountname "Benutzer$_" -Name "Benutzer$_" -AccountPassword (ConvertTo-SecureString -AsPlainText "Pa$$w0rd!" -Force) –Enabled $true –Path „OU=<OU>,DC=Domäne,DC=de“}


# Allen Benutzern einer bestimmten OU einen Wert im Feld „Beschreibung“ setzen
Get-ADUser –Filter * -Searchbase „OU=<OU>,DC=Domäne,DC=DE“ | Set-ADUser –description „Wert“



# Die Option „Konto läuft ab am:“ auf den 31. Oktober 2009 setzen
Set-ADUser Yusuf –AccountExpirationDate 01/11/2009

 

 

#  Die Option „Konto läuft ab“ auf „Nie“ setzen
Clear-ADAccountExpiration Yusuf

 


# Den Profilpfad, das Anmeldeskript und ein Homelaufwerk für einen bestimmten Benutzer eintragen
Set-ADUser „Yusuf“ –ProfilePath \\Server01\Profiles\%username% -Scriptpath „Login.bat“ –Homedrive „X“ –HomeDirectory „\\Server01\home\Yusuf“



# Einen Benutzer in eine andere OU verschieben
Get-ADUser Yusuf | Move-ADObject –TargetPath „OU=NeueOU,DC=Domäne,DC=de“

 


# Den relative distinguished name (RDN) eines Benutzers ändern
Rename-ADObject „CN=Yusuf Dikmenoglu,OU=IT,DC=Domäne,DC=de“ –NewName „Yusuf Cool“



# Einen Benutzer löschen
Remove-ADUser Yusuf


# Einen Benutzer ohne Sicherheitsabfrage löschen
Remove-ADUser Yusuf -Confirm:$False



# Mehrere Benutzer anhand eines gemeinsamen Kriteriums löschen
Get-ADUser –Filter {Name –Like „*Dikmenoglu*“} | Remove-ADUser


# Mit dem folgenden Befehl wird die Voreinstellung für neue Benutzer auf einem deutschen DC (auf einem englischen System lautet der LDAP-Pfad ...,CN=409,...) auf „Nachname, Vorname“ geändert (die Ansicht im Attribut
name). Bestehende Objekte sind davon nicht betroffen.
Set-ADObject "CN=user-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=Domäne,DC=de" -Partition „CN=Configuration,DC=Domäne,DC=de“ -Replace @{CreateDialog="%<sn>, %<givenName>"}


Die Voreinstellung für Kontakte wird wie folgt geändert:
Set-ADObject "CN=contact-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=Domäne,DC=de" -Partition „CN=Configuration,DC=Domäne,DC=de“ -Replace @{CreateDialog="%<sn>, %<givenName>"}


# Benutzer muss Kennwort bei der nächsten Anmeldung ändern
Set-ADUser –identity Yusuf –ChangePasswordAtLogon $true


# Die Kontooption „Benutzer kann Kennwort nicht ändern“ setzen
Set-ADAccountControl Yusuf -CannotChangePassword $true

Achtung: Ist die Kontooption „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“ aktiviert, kann über dsa.msc nicht zusätzlich die Kontooption „Benutzer kann Kennwort nicht ändern“ aktiviert werden. Was auch verständlich ist, denn diese beiden Optionen widersprechen sich. Ist jedoch die Kontooption „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“ aktiviert und die Kontooption „Benutzer kann Kennwort nicht ändern“ wird über die AD-PowerShell aktiviert, sind anschließend beide Optionen aktiviert!


# Einem Benutzer ein neues Kennwort vergeben
Set-ADAccountPassword –Identity Yusuf -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "Pa$$w0rd!" –Force)


# Die Kontooption „Kennwort läuft nie ab“ bei einem Benutzer- oder Dienstkonto aktivieren
Set-ADAccountControl Yusuf -PasswordNeverExpires $true


# Bei allen Benutzern die Kontooption "Kennwort läuft nie ab" deaktivieren und dafür die Option "Benutzer muss Kennwort bei der nächsten Anmeldung ändern" aktivieren
Get-ADUser -filter * | Set-ADUser -PasswordNeverExpires $false -ChangePasswordAtLogon $true

# Alle Benutzerkonten innerhalb einer bestimmten OU anzeigen, die die Kontooption „Kennwort läuft nie ab“ aktiviert haben
Search-ADAccount -PasswordNeverExpires -SearchBase “OU=EDV,DC=blog,DC=dikmenoglu,DC=de”


Hinweis: Bei Nutzung des Cmdlets Search-ADAccount kann durch die Angabe des Parameters –UsersOnly oder –ComputersOnly die Abfrage entweder nur auf Benutzer- oder Computerkonten beschränkt werden.


# Liefert alle Konten die ein abgelaufenes Kennwort besitzen
Search-ADAccount -PasswordExpired | FT Name,ObjectClass


# Alle Benutzer-, Computer- und Dienstkonten anzeigen, die deaktiviert sind
Search-ADAccount -AccountDisabled | FT Name


# Nur deaktivierte Benutzerkonten einer Domäne anzeigen
Search-ADAccount –AccountDisabled –Usersonly | FT Name


# Lediglich deaktivierte Computerkonten anzeigen. Wenn Clients aus der Domäne entfernt und in eine Arbeitsgruppe hinzugefügt werden, wird das Computerkonto im AD deaktiviert und nicht gelöscht.
Search-ADAccount -AccountDisabled -ComputersOnly | FT Name


# Alle deaktivierten Benutzer einer bestimmten Organisationseinheit (OU) anzeigen
Search-ADAccount -AccountDisabled –Searchbase „OU=<OU>,DC=Domäne,DC=DE | where {$_.ObjectClass -eq 'user'} | FT Name


# Abgelaufene Benutzerkonten anzeigen
Search-ADAccount –AccountExpired | FT Name


# Alle Benutzerkonten anzeigen, die in den nächsten 60 Tagen ablaufen
Search-ADAccount –AccountExpiring -TimeSpan 60.00:00:00 | FT Name


# Alle Konten anzeigen (auch Computer) die sich in den letzten 60 Tagen nicht angemeldet haben. Bei dieser Abfrage muss sich der Domänenfunktionsmodus mindestens auf der Ebene „Windows Server 2003“ befinden
Search-ADAccount -AccountInactive -TimeSpan 60.00:00:00 | FT Name


# Alle gesperrten Benutzer anzeigen
Search-ADAccount -LockedOut –Usersonly | FT Name


# Einen bestimmten Benutzer entsperren
Unlock-ADAccount –identity <DN des Benutzers>


# Alle Benutzerkonten anzeigen die am 30.08.2009 ablaufen
Search-ADAccount -AccountExpiring -Usersonly -DateTime "8/30/2009" | FT Name

 


AD-PowerShell „Gruppenobjekt“ Befehle

Bei der Angabe des <Gruppennamen> können folgende Werte verwendet werden:

- sAMAccountName
- Distinguished Name (DN)
- ObjectSID
- ObjectGUID

Mit dem Cmdlet Get-ADGroup werden standardmäßig folgende Werte angezeigt: DistinguishedName, GroupCategory, GroupScope, Name, ObjectClass, ObjectGUID, sAMAccountName, ObjectSID. Sollen neben diesen Werten noch weitere angezeigt werden, müssen diese mit dem Parameter –Properties angegeben werden. Z.B.: Get-ADGroup <Gruppe> -Properties groupType,member,memberOf,whenCreated,whenchanged


# Alle Eigenschaften einer Gruppe werden mit der Angabe von dem Stern (Wildcard) angezeigt
Get-ADGroup <Gruppe> -Properties *


# Eine globale Sicherheitsgruppe im Container Users erstellen
New-ADGroup -Name "Neue Gruppe" -sAMAccountName NeueGruppe -GroupCategory Security -GroupScope Global -DisplayName "Neue Gruppe" -Path "CN=Users,DC=Domäne,DC=de"


# Eine domänenlokale Sicherheitsgruppe in einer OU erstellen
New-ADGroup -Name "Gruppe" -sAMAccountName Gruppe -GroupCategory Security -GroupScope DomainLocal -DisplayName "Gruppe" -Path "OU=<OU>,DC=Domäne,DC=de"


# Eine universelle Sicherheitsgruppe in einer OU erstellen
New-ADGroup -Name "Gruppe" -sAMAccountName Gruppe -GroupCategory Security -GroupScope Universal -DisplayName "Gruppe" -Path "OU=<OU>,DC=Domäne,DC=de"


# Eine globale Verteilergruppe in der angegebenen OU erstellen

New-ADGroup -Name <Gruppe> -sAMAccountName <Gruppe> -GroupScope Global -GroupCategory Distribution –DisplayName <Gruppe> –Path “OU=<OU>,DC=Domäne,DC=de”


# Alle Gruppen mit dem Gruppentyp “Sicherheit” anzeigen
Get-ADGroup –LDAPFilter „(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648))“

Oder
Get-ADGroup –Filter „groupType –band 0x80000000“


# Alle Gruppen mit dem Gruppentyp “Verteiler” anzeigen
Get-ADGroup –LDAPFilter „(&(objectCategory=group)(!groupType:1.2.840.113556.1.4.803:=2147483648))“


# Nur universelle Sicherheitsgruppen anzeigen
Get-ADGroup –LDAPFilter „(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=-2147483640))“


# Nur domänenlokale Sicherheitsgruppen anzeigen
Get-ADGroup –LDAPFilter „(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=-2147483644))“


# Nur globale Sicherheitsgruppen anzeigen
Get-ADGroup –LDAPFilter „(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=-2147483646))“


# Globale Sicherheits- und Verteilergruppen werden mit diesem Befehl angezeigt
Get-ADGroup –LDAPFilter „(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2))“


# Domänenlokale Sicherheits- und Verteilergruppen zeigt dieser Befehl an
Get-ADGroup –LDAPFilter „(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=4))“


# Universelle Sicherheits- und Verteilergruppen anzeigen
Get-ADGroup –LDAPFilter „(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=8))“


# Alle Benutzer anzeigen die als primäre Gruppe „Domänen-Benutzer“ eingetragen haben
Get-ADUser –LDAPFilter „(&(objectCategory=person)(objectClass=user)(primaryGroupID=513))“


# Alle Benutzer anzeigen die als primäre Gruppe NICHT „Domänen-Benutzer“ eingetragen haben
Get-ADUser –LDAPFilter „(&(objectCategory=person)(objectClass=user)(!primaryGroupID=513))“


# Alle direkten und verschachtelten Gruppenmitgliedschaften eines Benutzers anzeigen
Get-ADAccountAuthorizationGroup Yusuf


# Alle direkten Mitglieder einer Gruppe anzeigen
Get-ADGroupMember <Gruppe> | FT Name


# Alle direkten und verschachtelten Mitglieder einer Gruppe anzeigen
Get-ADGroupMember <Gruppe> -Recursive | FT Name -A


# Alle direkten, verschachtelten und aktive (keine deaktivierten) Mitglieder einer Gruppe anzeigen
Get-ADGroupMember <Gruppe> -Recursive | Get-ADUser | Where-Object { $_.Enabled -eq 'True' } | FT Name


# Alle für das System wichtigen Gruppen anzeigen
Get-ADGroup -Filter { isCriticalSystemObject -eq $true }


# Eine Gruppe verschieben
Move-ADObject "CN=Gruppe,OU=Techniker,DC=Domäne,DC=de" -TargetPath "OU=NeueOU,DC=Domäne,DC=de"


# Eine Beschreibung für eine Gruppe setzen
Set-ADGroup <Gruppe> -Description "Diese Gruppe darf Benutzer im AD erstellen"


# Eine Verteilergruppe in eine Sicherheitsgruppe ändern
Set-ADGroup <Gruppe> -groupCategory Security


# Den Gruppenbereich einer Gruppe auf Global ändern
Set-ADGroup <Gruppe> –groupScope Global


# Den Gruppenbereich und den Gruppentyp einer Gruppe ändern
Set-ADGroup <Gruppe> –groupScope Universal -groupCategory Security

Anstatt Universal kann Global oder DomainLocal angegeben werden.


# Mitglieder zu einer Gruppe hinzufügen
Add-ADGroupmember <Gruppe> -Member Yusuf,Kaan


# Eine Gruppe löschen
Remove-ADGroup <Gruppe>


# Einen Benutzer aus einer Gruppe entfernen
Remove-ADGroupMember <Gruppe> -Member Yusuf


# Alle direkten Gruppenmitgliedschaften eines Sicherheitsprinzipals (Benutzer, Gruppe, Computer) anzeigen
Get-ADPrincipalGroupMembership <Objekt>



 

AD-PowerShell „Organisationseinheit“ Befehle

# Mit dem Cmdlet Get-ADOrganizationalUnit werden folgende Werte angezeigt: City, Country, DistinguishedName, LinkedGroupPolicyObjects, ManagedBy, Name, ObjectClass, ObjectGUID, PostalCode, State, StreetAddress. Alle Eigenschaften einer OU lassen sich mit dem Parameter –Properties * anzeigen.


# Alle OUs in einer Domäne anzeigen
Get-ADOrganizationalUnit -Filter {Name -like „*“} | FT Name, DistinguishedName -A


# Den Inhalt einer bestimmten OU anzeigen
Get-ADObject -Filter {Name -Like "*"} -Searchbase „OU=<OU>,DC=Domäne,DC=de“


# Eine OU erstellen. Dabei ist die Option Objekt vor zufälligem Löschen schützen automatisch aktiviert.
New-ADOrganizationalUnit -Name Techniker -Path "OU=IT,DC=Domäne,DC=de"


# Die Option Objekt vor zufälligem Löschen schützen von einer OU entfernen
Set-ADOrganizationalUnit „<DN der OU>“ –ProtectedFromAccidentalDeletion $false


# Die Option Objekt vor zufälligem Löschen schützen auf einer OU aktivieren
Set-ADOrganizationalUnit „<DN der OU>“ –ProtectedFromAccidentalDeletion $true


# Die Option Objekt vor zufälligem Löschen schützen auf allen OUs einer Domäne aktivieren
Get-ADOrganizationalUnit -Filter 'Name -like "*"' | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true


# Eine OU verschieben
Move-ADObject "aktuelle DN der OU" -TargetPath "Ziel-DN"

Ist die Option Objekt vor zufälligem Löschen schützen aktiviert, erhält man eine Fehlermeldung.


# Eine OU samt dem kompletten Inhalt löschen
Remove-ADOrganizationalUnit Test -Recursive

Ist die Option Objekt vor zufälligem Löschen schützen aktiviert, erhält man eine Fehlermeldung.


# Einen Benutzer aus einer OU löschen
Remove-ADObject „CN=Yusuf Dikmenoglu,OU=IT,DC=Domäne,DC=de“


# Alle Objekte innerhalb einer OU in eine andere OU verschieben
Get-ADObject -Filter {Name -Like "*"} -Searchbase „OU=AlteOU,DC=Domäne,DC=de“ -SearchScope OneLevel | Move-ADObject -TargetPath "OU=NeueOU,DC=Domäne,DC=de"


# Eine OU umbenennen
Rename-ADObject "OU=AlterName,DC=Domäne,DC=de" -NewName <Neuername>


# Eine Beschreibung für eine OU vergeben
Set-ADOrganizationalUnit <DN zur OU> -description <Beschreibung>



 

AD-PowerShell „Computerobjekt“ Befehle

# Mit dem Cmdlet Get-ADComputer werden diese Werte angezeigt: DistinguishedName, DNSHostName, Enabled, Name, ObjectClass, ObjectGUID, sAMAccountName, ObjectSID, userPrincipalName.


# Alle Computerkonten innerhalb einer Domäne auflisten
Get-ADComputer –Filter {Name –Like “*”}


# Ein Computerobjekt in eine andere OU verschieben
Get-ADComputer <Computername> | Move-ADObject -TargetPath „DN von Ziel-OU“


# Alle Computer anzeigen, die sich seit 180 Tagen nicht am AD angemeldet haben:
Search-ADaccount -AccountInactive -Timespan 180 -ComputersOnly


# Mit dem folgenden Befehl wird die maximale Anzahl an Clients die ein Domänen-Benutzer zur Domäne hinzufügen kann erhöht
Set-ADDomain blog.dikmenoglu.de -Replace @{"ms-ds-MachineAccountQuota"="333"}

Siehe auch:

Clients in die Domäne hinzufügen


 

Weitere Informationen:
Active Directory Administration with Windows PowerShell
Die Active Directory-Attribute hinter den Feldnamen

Sunday, August 09, 2009 8:14:18 PM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | AD-Powershell | Erweiterte Abfragen  | 
 Saturday, August 01, 2009

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

Saturday, August 01, 2009 10:05:05 PM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Administration | Wiederherstellung  | 
 Friday, July 17, 2009

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:

  1. Ein Schemamaster 
  2. Ein Domänennamenmaster
  3. Zehn RID-Master (Relative ID)
  4. Zehn PDC-Emulatoren
  5. Zehn Infrastrukturmaster für die Domänen bzw. Domänenpartitionen
  6. Ein Infrastrukturmaster für die Anwendungsverzeichnispartition "ForestDNSZones"
  7. 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:

  1. Unter Windows Server 2003 gilt es zuerst die Windows Support Tools (auf der Server-CD im Verzeichnis Support\Tools) zu installieren. 
  2. Danach startet man das ADSIEdit, was ab Windows Server 2008 bereits "on Bord" ist. 
  3. Im ADSIEdit wählt man mit einem Rechtsklick auf den Eintrag "ADSI Edit" die Option "Connect to..." aus. 
  4. Im darauffolgenden Fenster "Connection Settings" ist im Bereich "Connection Point" die Option "Select or type a Distinguished Name or Naming Context" auszuwählen. 
  5. 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
     
  6. 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
     
  7. 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. 
  8. 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

 

  1. Unter Windows Server 2003 befindet sich das LDP in den Windows Support Tools und ab Windows Server 2008 ist es bereits „on Bord“.

  2. Zuerst gilt es das LDP unter Start - Ausführen - LDP zu starten.

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

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

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

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

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

 

Friday, July 17, 2009 9:29:48 AM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Administration  | 
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme: