Die Tombstone Lifetime (TSL) definiert drei Verhaltensregeln innerhalb einer Active Directory Umgebung. Diese wären:
1. Wie lange ein System State-/Full Server - Backup verwendet werden darf.
2. In welcher Zeit sich die DCs mindestens einmal erfolgreich repliziert haben müssen.
3. Wann ein gelöschtes Objekt endgültig vom Garbage Collection Prozess endgültig aus der AD-Datenbank (NTDS.DIT) entfernt wird.
Welchen Wert die TSL hat, wann und wo die TSL gesetzt wird oder wie man diese ändern kann, ist hier beschrieben:
Die Tombstone Lifetime
Folgende Besonderheiten gibt es bzgl. der TSL:
1. Der Minimalwert der bis einschließlich „Windows Server 2008“ Gültigkeit hat ist „2“. Konfiguriert man bis Windows Server 2008 einen niedrigeren Wert (also 1), wird als Wert 60 festgelegt.
2. Wird ab „Windows Server 2008 R2“ ein Wert kleiner 2 konfiguriert, wird als Wert immer 2 festgelegt. Der Minimalwert den ab Windows Server 2008 R2 die TSL haben kann ist also immer 2.
Was passiert eigentlich wenn man ein AD-Backup versucht rückzusichern, das älter als die TSL ist?
Versucht man nun ein z.B. System State Backup das älter als die TSL ist rückzusichern, erhält man gleich zu Beginn des Restoreversuchs diese Fehlermeldung:
Eine Rücksicherung wird direkt schon vom Backup-Programm geblockt.
Weitere Informationen:
Was passiert in der AD-Datenbank wenn ein Objekt gelöscht wird?
Der Container Deleted Objects
3.1.1.1.5.1 Tombstone Lifetime and Deleted-Object Lifetime
Seit gestern 29.02.2012 – ca. 15:45 Uhr MEZ hat Microsoft die Clientversion mit dem Namen „Windows 8 Consumer Preview“ Build 8250 und die Serverversion „Windows Server 8 Beta“ veröffentlicht. Erreicht ein Release das Beta Stadium, ist es feature completed. Ab der Veröffentlichung einer Beta Version werden keine neuen Funktionen mehr eingebaut, sondern nur noch Fehlerbeseitigung betrieben.
Hier kann man sich die entsprechende Version herunterladen:
Windows 8 Consumer Preview
Windows Server "8" Beta
Mit diesen beiden Major Releases erscheinen sowohl für den Client als auch für den Server die Weiterentwicklung von Windows 7 und Windows Server 2008 R2!
Die AD – PowerShell CMDLets wurden von 76 auf 134 und somit um 58 neue CMDLets erweitert!
Im Vergleich hier die AD - PowerShell CMDLets unter Windows Server 2008 R2:
AD-PowerShell Befehle
Erfreulich ist, dass es nun (endlich) 23 AD-Replikations CMDLets gibt. Viele Konfigurationen die bisher ausschließlich in der MMC „Active Directory-Sites and –Services“ (dssite.msc) vorgenommen werden konnten, können jetzt auch in der AD-PowerShell mit den neuen CMDLets durchgeführt werden.
Die Hilfe zu den einzelnen CMDLets lässt sich in gewohnter Weise mit dem Befehl Get-Help <Cmdlet Name> -Full aufrufen.
AD-Objekte abrufen (41 Cmdlets)
- Get-ADAccountAuthorizationGroup
- Get-ADAccountResultantPasswordReplicationPolicy
- Get-ADCentralAccessPolicy
- Get-ADCentralAccessRule
- Get-ADClaimTransformPolicy
- Get-ADClaimType
- Get-ADComputer
- Get-ADComputerServiceAccount
- Get-ADDCCloningExcludedApplicationList
- 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-ADReplicationAttributeMetadata
- Get-ADReplicationConnection
- Get-ADReplicationFailure
- Get-ADReplicationPartnerMetadata
- Get-ADReplicationQueueOperation
- Get-ADReplicationSite
- Get-ADReplicationSiteLink
- Get-ADReplicationSiteLinkBridge
- Get-ADReplicationSubnet
- Get-ADReplicationUpToDatenessVectorTable
- Get-ADResourceProperty
- Get-ADResourcePropertyList
- Get-ADResourcePropertyValueType
- Get-ADRootDSE
- Get-ADServiceAccount
- Get-ADTrust
- Get-ADUser
- Get-ADUserResultantPasswordPolicy
AD-Objekte erstellen (17 Cmdlets)
- New-ADCentralAccessPolicy
- New-ADCentralAccessRule
- New-ADClaimTransformPolicy
- New-ADClaimType
- New-ADComputer
- New-ADFineGrainedPasswordPolicy
- New-ADGroup
- New-ADObject
- New-ADOrganizationalUnit
- New-ADReplicationSite
- New-ADReplicationSiteLink
- New-ADReplicationSiteLinkBridge
- New-ADReplicationSubnet
- New-ADResourceProperty
- New-ADResourcePropertyList
- New-ADServiceAccount
- New-ADUser
AD-Objekte entfernen (24 Cmdlets)
- Remove-ADCentralAccessPolicy
- Remove-ADCentralAccessPolicyMember
- Remove-ADCentralAccessRule
- Remove-ADClaimTransformPolicy
- Remove-ADClaimType
- Remove-ADComputer
- Remove-ADComputerServiceAccount
- Remove-ADDomainControllerPasswordReplicationPolicy
- Remove-ADFineGrainedPasswordPolicy
- Remove-ADFineGrainedPasswordPolicySubject
- Remove-ADGroup
- Remove-ADGroupMember
- Remove-ADObject
- Remove-ADOrganizationalUnit
- Remove-ADPrincipalGroupMembership
- Remove-ADReplicationSite
- Remove-ADReplicationSiteLink
- Remove-ADReplicationSiteLinkBridge
- Remove-ADReplicationSubnet
- Remove-ADResourceProperty
- Remove-ADResourcePropertyList
- Remove-ADResourcePropertyListMember
- Remove-ADServiceAccount
- Remove-ADUser
AD-Schreibvorgänge durchführen (27 Cmdlets)
- Set-ADAccountControl
- Set-ADAccountExpiration
- Set-ADAccountPassword
- Set-ADCentralAccessPolicy
- Set-ADCentralAccessRule
- Set-ADClaimTransformLink
- Set-ADClaimTransformPolicy
- Set-ADClaimType
- Set-ADComputer
- Set-ADDefaultDomainPasswordPolicy
- Set-ADDomain
- Set-ADDomainMode
- Set-ADFineGrainedPasswordPolicy
- Set-ADForest
- Set-ADForestMode
- Set-ADGroup
- Set-ADObject
- Set-ADOrganizationalUnit
- Set-ADReplicationConnection
- Set-ADReplicationSite
- Set-ADReplicationSiteLink
- Set-ADReplicationSiteLinkBridge
- Set-ADReplicationSubnet
- Set-ADResourceProperty
- Set-ADResourcePropertyList
- Set-ADServiceAccount
- Set-ADUser
AD-Objekte hinzufügen (7 Cmdlets)
- Add-ADCentralAccessPolicyMember
- Add-ADComputerServiceAccount
- Add-ADDomainControllerPasswordReplicationPolicy
- Add-ADFineGrainedPasswordPolicySubject
- Add-ADGroupMember
- Add-ADPrincipalGroupMembership
- Add-ADResourcePropertyListMember
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 und ADClaimTransformLink zurücksetzen (1 Cmdlet)
- Clear-ADAccountExpiration
- Clear-ADClaimTransformLink
AD-Dienstkonto installieren (1 Cmdlet)
- Install-ADServiceAccount
AD-Konto synchronisieren (1 Cmdlet)
- Sync-ADObject
AD-Dienstkonto testen (1 Cmdlet)
- Test-ADServiceAccount
Auch wurden erstmals mit Windows Server 8 zehn "ADDS Deployment" CMDlets ins Serverbetriebssystem implementiert, um die Installation der DCs nun auch in der AD-PowerShell zu automatisieren. Wobei bis zur RTM die fünf "Test-ADDS*" CMDLets nicht mehr mit dem Befehl Get-Command -Module ADDSDeployment sichtbar sein werden!
Das manuelle Aufrufen von DCPROMO.exe unter "Start - Ausführen" ist ab Windows Server 8 nicht mehr möglich! Das manuelle Heraufstufen eines DCs erfolgt ab sofort im Server-Manager. Jedoch wird DCPROMO in einer Antwortdatei weiterhin unterstützt, damit die Unternehmen die bisher die Installation ihrer DCs weitestgehend automatisiert hatten, keinen Nachteil erhalten.
Ein Read-Only Domänencontroller Computerkonto erstellen (1 CMDLet)
- Add-ADDSReadOnlyDomainControllerAccount
Eine ADDS Domäne in der Gesamtstruktur installieren
- Install-ADDSDomain
Einen Domänencontroller installieren
- Install-ADDSDomainController
Eine Gesamtstruktur bzw. die Root-Domäne installieren
- Install-ADDSForest
Die "Test-ADDS*" CMDLets werden bis zur Fertigstellung des Windows Server 8 RTM (Release to Manufacturing) nicht mehr mit "Get-Command -Module ADDSDeployment" sichtbar sein!
Einen Domänencontroller oder eine Domäne deinstallieren
- Uninstall-ADDSDomainController
Des Weiteren wurden die Gruppenrichtlinien CMDLets von 25 auf 28 und somit um drei CMDLets erweitert.
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 / Get-GPPermission
Die Berechtigungen für einen oder mehrere Sicherheitsprinzipale kann man mit diesen Cmdlets 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.
Invoke-GPUpdate
Ein GPUpdate durchführen.
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 / Set-GPPermission
Die Berechtigungen einer GPO oder für alle GPOs innerhalb einer Domäne lassen sich mit diesen Cmdlets 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 PowerShell Cmdlets für Gruppenrichtlinien
Eines der Schutzmechanismen der AD-Replikation ist die strict replication consistency (strikte Replikationskonsistenz), die standardmäßig bei einer Migration von NT 4.0 auf Windows Server 2003 oder wenn ein Forest ab Windows Server 2003 erstellt wurde, aktiviert ist. Die Funktion der „strict replication consistency“ steht ab Windows 2000 Server SP3 (sogar schon mit Post-SP2 Hotfix) zur Verfügung, diese ist aber unter Windows 2000 standardmäßig deaktiviert!
Was es mit der strict replication consistency auf sich hat und wann diese vor allem zum Einsatz kommt, wird in dem folgenden Artikel detailliert erläutert:
LDAP://Yusufs.Directory.Blog/ - Lingering Objects (veraltete Objekte)
Kurz gesagt verhindert die „strict replication consistency“, dass Lingering Objects (herumlungernde/veraltete Objekte) von einem (veralteten) Domänencontroller (DC) der sich länger als die Tombstone-Lifetime nicht mehr mit seinen Replikationspartnern repliziert hat, zurück zu den (aktuellen!) Replikationspartnern repliziert werden.
Ein Forest der unter Windows Server 2003 oder höher installiert wurde, verfügt über einen speziellen operativen GUID, der standardmäßig aber nicht in einem Forest mit Windows 2000 Wurzeln existiert!
Wird ein Server zum DC hochgestuft, überprüft dieser ob das folgende Objekt existiert:
CN=94fdebc6-8eeb-4640-80de-ec52b9ca17fa,CN=Operations,CN=ForestUpdates,CN=Configuration,DC=<Root-Domain>
Erst wenn dieser Container zum Zeitpunkt des heraufstufen existiert, aktiviert der künftige DC die „strict replication consistency“ automatisch.
Ab Windows Server 2003 SP1 kann man die „strict replication consistency“ auf einem einzelnen DC mit dem folgenden REPADMIN-Befehl aktivieren: Repadmin /regkey <DC> +strict.
Auf allen DCs im Forest lässt sich die „strict replication consistency“ wie folgt aktivieren: Repadmin /regkey * +strict
Das bedeutet jedoch, jedes Mal wenn weitere DCs (in einen Forest mit Windows 2000 Wurzeln) hinzukommen, muss jedes Mal auf dem DC die „strict replication consistency“ mit dem Befehl „Repadmin /regkey <DC> +strict“ aktiviert werden.
Eine elegantere Variante ist, damit ab sofort auf allen künftigen DCs automatisch die „strict replication consistency“ aktiviert ist, man erstellt den operativen Container in der Konfigurationspartition manuell.
Mit ADSIEdit kann man das folgendermaßen erledigen:
- Nachdem ADSIEdit gestartet und der Eintrag ADSI Edit auf der linken Seite markiert wurde, gilt es zuerst auf Action und anschließend auf Connect to… zu klicken.
- Im darauf erscheinenden “Connection Settings” Dialogfenster kann man dann im Bereich Connection Point im Feld Select or type a Distinguished Name or Naming Context den folgenden LDAP-Pfad, sprich den Distinguished Name des folgenden Containers angeben und anschließend mit OK bestätigen: CN=Operations,CN=ForestUpdates,CN=Configuration,DC=<Root-Domain>
- Als nächstes gilt es mit einem Rechtsklick auf CN=Operations,CN=ForestUpdates,CN=Configuration,DC=<Root-Domain> die Option New -> Object... auszuwählen.
- Als class muss der Eintrag container ausgewählt werden.
- Im nächsten Schritt muss als Value dieser Wert eingegeben warden: 94fdebc6-8eeb-4640-80de-ec52b9ca17fa.
- Danach sollte man auf auf More Attributes klicken und unter Select a property to view die Option showInAdvancedViewOnly auswählen.
- Zusätzlich sollte im Bereich Attribute Values im Feld Edit Attribute als Wert TRUE eingetragen und mit SET bestätigt werden.
- Mit einem abschließenden Klick auf OK und Finish hat man dann das Objekt 94fdebc6-8eeb-4640-80de-ec52b9ca17fa erstellt. Ab sofort wird nun bei einem neuen DC der in einer Gesamtstruktur mit Windows 2000 Wurzeln hochgestuft (promotet) wurde, die „strict replication consistency“ automatisch aktiviert.
Wem jedoch dieser Vorgang zu heikel ist, der kann auch regelmäßig (evtl. in einem geplanten Task) den REPADMIN – Befehl ausführen, damit auf allen neuen DCs auch die „strict replication consistency“ aktiviert wird: Repadmin /regkey * +strict
Mit der folgenden GPO-ADM Datei lässt sich das ebenfalls lösen:
CLASS MACHINE
CATEGORY "Strict Replication Consistency"
KEYNAME "System\CurrentControlSet\Services\NTDS\Parameters"
POLICY "Enable Strict Replication Consistency"
EXPLAIN "This enables Strict Replication Consistency”.
VALUENAME "Strict Replication Consistency"
VALUEON NUMERIC 1
VALUEOFF DELETE
END POLICY
END CATEGORY
Wird anschließend diese GPO auf die OU “Domain Controllers” verlinkt, wird ebenfalls auf jedem neuen DC die „strict replication consistency“ automatisch aktiviert.
Weitere Informationen:
Event ID 1388 or 1988: A lingering object is detected: Active Directory
Active Directory (AD) basierte Gruppenrichtlinienobjekte (auf Englisch: Group Policy Object, kurz GPO) bestehen hauptsächlich aus zwei Komponenten, bestehend aus der logischen und physikalischen Struktur. Der logische Teil einer GPO wird in der AD-Datenbank (NTDS.dit) gespeichert und wird als Gruppenrichtliniencontainer (auf Englisch: Group Policy Container, kurz GPC) bezeichnet. Die physikalische Komponente einer GPO wird im Dateisystem, im replizierten Verzeichnis SYSVOL gespeichert und lautet Gruppenrichtlinienvorlage (auf Englisch: Group Policy Template, kurz GPT).
In den Eigenschaften eines GPC werden alle AD relevanten Konfigurationsdaten einer GPO gespeichert, wie beispielsweise der Pfad zur Gruppenrichtlinienvorlage (das Attribut gPCFileSysPath im entsprechenden GPC, also der Pfad zum GPT), der Status von Gruppenrichtlinienobjekten (das Attribut flags) oder die Zugriffsteuerungsliste (Access Control List, kurz ACL) die bestimmt, welcher Benutzer bzw. Gruppe die Einstellungen eines GPOs verwalten darf. Den GPC selbst findet man in der Domänenpartition im Container CN=Policies,CN=System,DC=<Domäne>. Diesen Container kann man in der MMC Active Directory-Benutzer und –Computer (dsa.msc) zum Vorschein bringen. Dazu muss man jedoch zuerst in der MMC dsa.msc unter Ansicht die „Erweiterte Features“ aktivieren. Die GPC werden im AD-Container Policies mit ihrer {GUID} dargestellt und ist derselbe, wie er auch im GPT angezeigt wird.
Im GPT befinden sich die meisten Einstellungen eines GPOs sowie verschiedene Verzeichnisse und Konfigurationsdateien. Im GPT werden also alle aktuellen GPO-Einstellungen eines GPOs gespeichert. Die GPTs werden im Dateisystem tatsächlich unter %windir%\SYSVOL\domain\Policies, jeweils dargestellt mit ihrer {GUID}, gespeichert. Nicht zu verwechseln mit den Junction Points unter %windir%\SYSVOL\sysvol\<Domäne>\Policies. Tools für die Verwaltung von GPOs (z.B. die GPMC) verwenden die Junction Points und nicht den echten Speicherort der GPTs.
Wichtig für das Troubleshooting ist zu wissen, dass die hauptsächlichen Komponenten einer GPO, nämlich der GPC und das GPT, auf unterschiedliche Weise repliziert werden. Der GPC wird im Rahmen der AD-Replikation repliziert. Das GPT wird je nach Domänenfunktionsmodus entweder vom FRS (File Replication Service) oder vom DFS-R (Distributed File System Replication) repliziert. Liegen die Wurzeln einer Domäne im Domänenfunktionsmodus „Windows Server 2003“ oder niedriger, wird das GPT durch den FRS repliziert. Wurde die Domäne mindestens im Domänenfunktionsmodus „Windows Server 2008“ installiert, kommt DFS-R für die Replikation des GPT und somit des SYSVOLs zum Einsatz.
Die Performance bei der Abarbeitung von GPOs erhöhen
Für die Performance des Clients bei der Abarbeitung von GPOs (die auf ihn wirken) ist es empfehlenswert, den nicht konfigurierten Teil einer GPO stets zu deaktivieren. Das bedeutet, wenn in einer GPO lediglich Einstellungen im Benutzerkonfigurationsteil vorgenommen wurden, sollte der Computerkonfigurationsteil deaktiviert werden und vice versa.
Deaktivieren lässt sich ein Teil oder die gesamte GPO in der GPMC (Group Policy Management Console, zu Deutsch: Gruppenrichtlinienverwaltungskonsole). Mit einem Rechtsklick auf der entsprechenden GPO wählt man die Option Objektstatus aus und kann dann den gewünschten Teil oder die gesamte GPO deaktivieren. Das funktioniert auch wenn man die entsprechende GPO in der GPMC ausgewählt hat und danach zum Reiter Details wechselt.
Den Status der GPOs abfragen
Den Status einer GPO veranschaulicht das Attribut flags, das sich in den Eigenschaften jedes GPCs befindet.
Dabei kann das Attribut flags folgende Werte enthalten:
- Der Wert 0 im Attribut flags bedeutet, das gesamte Gruppenrichtlinienobjekt, also der Benutzerkonfigurations- und Computerkonfigurationsteil ist aktiviert.
- Der Wert 1 bedeutet, der Benutzerkonfigurationsteil einer GPO ist deaktiviert.
- Ist der Wert 2, wurde der Computerkonfigurationsteil einer GPO deaktiviert.
- Beim Wert 3 ist das gesamte GPO deaktiviert.
State of the Art kann man den Status der GPOs in der AD-PowerShell mit folgenden Einzeilern abfragen:
# Alle GPOs mit ihrem Status anzeigen lassen:
Get-ADObject -Server <DC> -LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | Select displayName,flags | FT -A
# Alle GPOs anzeigen, die beide Teile (Benutzer- und Computerkonfiguration) aktiviert haben:
Get-ADObject -Server <DC> -LDAPFilter "(flags=0)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | Select displayName,flags | FT -A
# Alle GPOs die den Teil der Benutzerkonfiguration deaktiviert haben, werden folgendermaßen angezeigt:
Get-ADObject -Server <DC> -LDAPFilter "(flags=1)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | Select displayName,flags | FT -A
# Alle GPOs die den Computerkonfigurationsteil deaktiviert haben, werden wie folgt angezeigt:
Get-ADObject -Server <DC> -LDAPFilter "(flags=2)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | Select displayName,flags | FT -A
# Alle komplett deaktivierten GPOs (beide Teile Benutzer- und Computerkonfigurationsteil sind deaktiviert) werden so angezeigt:
Get-ADObject -Server <DC> -LDAPFilter "(flags=3)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | Select displayName,flags | FT -A
Das Attribut flags automatisiert mit einem AD-PowerShellskript abfragen
Man kann die Abfrage auch automatisiert mit folgendem AD-PowerShellskript durchführen.
######################################################
#
# AD-PowerShellskript zur Statusabfrage von GPOs
#
# Von: Yusuf Dikmenoglu 05/2011
#
# http://blog.dikmenoglu.de
#
######################################################
$auswahl = Read-Host "Welcher GPO-Status soll angezeigt werden (0... Alle komplett aktiven GPOs anzeigen 1...Benutzerkonfiguration ist deaktiviert 2...Computerkonfiguration ist deaktiviert 3...GPOs die komplett deaktiviert sind):"
switch ($auswahl){
0 {
Get-ADObject -Server <DC> -LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | ForEach-Object {
if ($_.flags -eq 0){
write-host "Gesamte GPO aktiviert: " $_.displayName
}
}
}
1 {
Get-ADObject -Server <DC> -LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | ForEach-Object {
if ($_.flags -eq 1){
write-host "Benutzerkonfiguration des GPO ist deaktiviert: " $_.displayName
}
}
}
2 {
Get-ADObject -Server <DC> -LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | ForEach-Object {
if ($_.flags -eq 2){
write-host "Computerkonfiguration des GPO ist deaktiviert: " $_.displayName
}
}
}
3 {
Get-ADObject -Server <DC> -LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | ForEach-Object {
if ($_.flags -eq 3){
write-host "Gesamte GPO deaktiviert: " $_.displayName
}
}
}
default{
Write-Host "Ungültige Eingabe"
}
}
Der Unterschied zwischen einer beschreibbaren und nur lesbaren Verzeichnispartition (auf Englisch Naming Context, kurz NC) liegt im Attribut instanceType. Dieses Attribut besteht aus einer Bitmaske und existiert in den Eigenschaften jeder Verzeichnispartition. Ist das dritte Bit (Hex = 0x4; Dezimal = 4) im Attribut instanceType, in den Eigenschaften einer Verzeichnispartition auf einem DC gesetzt, so ist die Verzeichnispartition auf diesem DC beschreibbar. Falls das dritte Bit nicht gesetzt ist, ist die Verzeichnispartition auf diesem DC nur lesbar.
Da ein Read-Only Domänencontroller (RODC) nur einen lesenden Zugriff auf die Active Directory-Datenbank (NTDS.DIT) und somit auf alle Verzeichnispartitionen hat, ist logischerweise in allen Verzeichnispartitionen die sich auf einem RODC befinden das dritte Bit in instanceType nicht gesetzt!
Auch in den fremden Domänenpartitionen die sich im globalen Katalog befinden, ist das dritte Bit in instanceType nicht gesetzt!
Überprüfen kann man das mit dem Schweizer Messer Werkzeug für die AD-Replikation Repadmin. Führt man den Befehl Repadmin /showrepl /verbose in der Kommandozeile aus, erhält man solch eine Ausgabe:
In der Ausgabe werden alle Verzeichnispartitionen aufgelistet, die der DC repliziert. Die Verzeichnispartitionen in denen der DC das Schreibrecht besitzt, sind mit WRITEABLE gekennzeichnet. Die Verzeichnispartitionen in der der DC lediglich das Leserecht besitzt, sind nicht mit WRITEABLE gekennzeichnet.
Ob eine Verzeichnispartition auf einem bestimmten DC nur lesbar oder beschreibbar ist, kann man mit dem folgenden AD-PowerShellskript überprüfen:
######################################################
#
# AD-PowerShellskript zum überprüfen ob eine Verzeichnispartition
# nur lesbar oder beschreibbar ist.
#
# Von: Yusuf Dikmenoglu 05/2011
#
# http://blog.dikmenoglu.de
#
######################################################
# Hier den distinguishedName der entsprechenden Verzeichnispartition (= NC = Naming Context) angegeben
$searchbase = "DC=ad2008R2,DC=dikmenoglu,DC=de"
# Wenn man einen NC von einem globalen Katalog (GC) abfragen möchte, muss man bei "-Server" den FQDN
# des DCs und den GC-Port angeben. Also: "R2DCON01.ad2008R2.dikmenoglu.de:3268"
Get-ADObject -Server R2DCON01 -LDAPFilter "(instanceType=*)" -SearchBase $Searchbase -SearchScope base -Properties instanceType | ForEach-Object {
if ($_.instanceType -band 4){
write-host $_.ncName "Beschreibbare Verzeichnispartition: $Searchbase"
}
else{
write-host $_.ncName "Lesbare Verzeichnispartition: $Searchbase"
}
}
Weitere Informationen:
Welche Verzeichnispartitionen befinden sich auf einem DC?
Instance-Type Attribute
Read-Only Domain Controller (RODC)
Hin und wieder kommt es vor, dass man den Benutzeranmeldenamen mehrerer Domänen-Benutzer ändern muss. Da sich die Domänen-Benutzer mit dem „Benutzeranmeldenamen“ oder mit dem „Benutzeranmeldenamen (Prä-Windows 2000)“ anmelden können, müssen beim ändern des Benutzeranmeldenamen die Werte in den beiden Attributen userPrincipalName (kurz, UPN) und sAMAccountName geändert werden. Bei wenigen Benutzern lassen diese sich recht einfach händisch ändern. Doch wie sieht es mit hunderten oder >1.000 Benutzern aus?!
Diese Aufgabe lässt sich einfach und State of the Art mit Excel und der AD-PowerShell lösen! Die Basisdaten kann man sich recht simpel in eine CSV-Datei, die sich wiederum in Excel importieren lässt, aus dem AD exportieren. Dazu eignen sich CSVDE und die AD-PowerShell. Wie man einen Export (und Import) mit CSVDE oder der AD-PowerShell durchführen kann, zeigt dieser Artikel:
Massenimporte- und -exporte mit CSVDE und der AD-PowerShell durchführen
Die Excel-Datei könnte beispielsweise folgendermaßen aussehen:
Danach lässt sich der userPrincipalName sowie sAMAccountName mit dem folgenden AD-PowerShellskript ändern.
######################################################
#
# AD-PowerShell Skript zum umbenennen von AD-Benutzer.
# Mit diesem Skript wird der sAMAccountName, userPrincipalName
# und das Attribut name umbenannt
#
# Von: Yusuf Dikmenoglu 04/2011
#
# http://blog.dikmenoglu.de
#
######################################################
clear
# Excel Einstellungen
$excel = New-Object -ComObject Excel.Application # create base object
$excel.visible = $false
$wb = $excel.workbooks.open("C:\Tools\Benutzernamen.xls")
$ws1 = $wb.Worksheets.item(1)
# Programmbeginn
$count = 5
for ($index = 2; $index -lt $count; $index++) {
Write-Host $index
$loginAlt = $ws1.Cells.Item($index,6).text.trim()
$loginNeu = $ws1.Cells.Item($index,10).text.trim()
$aduser = Get-ADUser $loginAlt | ForEach-Object {
$ws1.Cells.Item($index,4) = $_.givenname
$ws1.Cells.Item($index,3) = $_.surname
$pricipalname = $loginNeu + "@Domäne.de"
Set-ADUser -Identity $loginAlt -SamAccountName $loginNeu -UserPrincipalName $pricipalname
Rename-ADObject -Identity $loginAlt -NewName $loginNeu # Funktioniert nur, wenn das Attribut "name" gleich "sAMAccountName" ist
}
}
$wb.save()
$wb.Close()
$excel.Quit()
Weitere Informationen:
Die Active Directory-Attribute hinter den Feldnamen
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
LDIFDE - LDAP Data Interchange Format Data Exchange
Hin und wieder kommen Administratoren auf die scheinbar glorreiche Idee, Domänencontroller (DC) zwecks der Ausfallsicherheit Clustern zu wollen. Zuerst einmal ist es lobenswert, dass sich Administratoren Gedanken über die Ausfallsicherheit von DCs machen. Schließlich sind DCs das Herz einer jeden AD Domäne und diese soll auch bei einem DC-Ausfall weiter funktionieren, möglichst ohne das Backup bemühen zu müssen.
Jedoch lässt sich technisch die DC-Funktionalität gar nicht Clustern. Die DC-Funktion ist nicht clusterfähig (cluster-aware)! Das muss sie aber auch nicht, da DCs die das „Active Directory“ (AD) bereitstellen über einen anderen Mechanismus redundant gehalten werden. Dieser Mechanismus ist die „AD-Replikation“.
Die hohe Verfügbarkeit sowie Ausfallsicherheit der DC-Funktionalität wird alleine durch den Einsatz von mehr als einem DC gewährleistet! Denn existieren in einer Domäne mehr als ein DC, replizieren sich die DCs die AD-Datenbank untereinander. Da DCs stets online sind, wird die Ausfallsicherheit und hohe Verfügbarkeit bereits durch die AD-Replikation und ohne einen Cluster zu bilden erreicht.
Wie viele DCs pro Domäne werden benötigt?
Aber selbstverständlich lässt sich ein Cluster auf zwei DCs installieren, ohne die DC-Funktionalität selber zu Clustern. Das könnte der Administrator in Erwägung ziehen, um beispielsweise eine Applikation geclustert zu betreiben. Warum allerdings das Betreiben von zusätzlichen Diensten bzw. Applikationen auf einem DC alles andere als eine gute Idee ist, stellt dieser Artikel dar:
Warum es ein dedizierter DC sein sollte!
Weitere Informationen:
Windows 2000, Windows Server 2003, and Windows Server 2008 cluster nodes as domain controllers
Cluster Service May Not Start if Domain Controller Is Unavailable
When a Windows Server 2003 cluster node is a domain controller, you may receive an error message when you add domain users to the cluster file share
Die NO-GOs und Empfehlungen zu virtuellen DCs
Setzt man Password Setting Objects (kurz PSOs) auch bekannt als fein abgestimmte Kennwortrichtlinien ein, kann es zu Verwirrungen bei der Meldung die Windows liefert kommen, wenn ein Benutzer ein Kennwort vergeben möchte das nicht den Vorgaben des ihm zugewiesenen PSO entspricht.
Welche Voraussetzungen existieren müssen damit PSOs eingesetzt werden können oder wie PSOs konfiguriert werden, steht neben weiteren Details im folgenden Artikel:
Password Setting Objects erstellen und verwalten
Damit man nicht aufs Glatteis durch die von Windows erzeugte Meldung geführt wird und um PSOs erfolgreich zu implementieren, hier ein paar wichtige Hinweise:
- Versucht ein Benutzer auf den ein PSO verlinkt wurde, auf einem Windows XP Client oder Windows Server 2003 sein Kennwort zu ändern, erhält er diese Meldung:
In diesem Fall hat der Benutzer erfolglos versucht sein Kennwort zu ändern. Das neue Kennwort entsprach nicht den Vorgaben aus dem PSO. Daher ist es folgerichtig, dass eine Meldung erscheint. Allerdings stammen die Kennwort-Anforderungen in dem Dialogfenster aus der Domänenrichtlinie Default Domain Policy, die auf Domänenebene verlinkt ist! Die Meldung hat sich leider mit Einführung von PSOs nicht verändert. Es erscheint kein eigenes Dialogfenster, in dem die Kennwortvorgaben des PSO enthalten sind!
- Versucht der Benutzer auf einem Windows 7 Client oder Windows Server 2008/R2 sein Kennwort zu ändern, erhält er bei nicht Einhaltung der Kennwortvorgaben aus dem PSO diese Meldung:
Auch diese Meldung ist irreführend, denn es wird auf die Kennwortrichtlinie der Domäne, also auf die Default Domain Policy verwiesen, in der standardmäßig die Kennwortvorgaben auf Domänenebene definiert sind. Eine andere Meldung mit den Kennwortvorgaben der PSO erscheint weiterhin nicht!
- Versucht der Administrator, das Kennwort eines Benutzers auf den ein PSO verlinkt wurde zu ändern, erscheint diese Meldung:
Diese Meldung ist ebenfalls trügerisch, denn angeblich entspricht das neue Kennwort nicht den Anforderungen der Kennwortrichtlinien. Abgesehen davon das es sich bei dem PSO nicht um eine Kennwortrichtlinie sondern um ein AD-Objekt handelt, erscheint einmal mehr kein Hinweis auf das PSO!
-
Führt man auf dem Client unter Start – Ausführen das Resultant Set of Policy (RSoP) aus, werden dort die Kennwortvorgaben wieder aus der Default Domain Policy angezeigt! Daher bringt ein RSOP.msc für die Überprüfung eines PSO nichts! Denn da es sich bei den PSOs nicht um Gruppenrichtlinien (GPOs) handelt, werden diese auch nicht im RSOP angezeigt. Und abgesehen davon ist RSOP.msc zum Überprüfen von GPOs nicht mehr State oft the Art und sollte ab Windows 7 und Windows Server 2008 R2 auch nicht mehr verwendet werden. Besser ist es in der Kommandozeile diesen Befehl zu verwenden: GPResult /h GPO-Report.html.
- PSOs dürfen erst erstellt werden, wenn sich der Domänenfunktionsmodus bereits im Modus Windows Server 2008 oder höher befindet. Wenn PSOs erstellt werden bevor sich der Domänenfunktionsmodus mindestens in der Ebene Windows Server 2008 befindet, werden diese auch nach dem Hochstufen nicht angewendet!
- Ob und welches PSO auf einen Benutzer verlinkt ist, sollte mit dem Kommandozeilenbefehl dsget user <DN des Benutzers> -effectivepso kontrolliert werden. Beispielsweise: dsget user " CN=Yusuf Dikmenoglu,OU=IT,DC=ad2008R2,DC=Dikmenoglu,DC=de" -effectivepso
In Active Directory-Umgebungen mit komplexen Gruppenstrukturen kann es zu Problemen bei der Benutzeranmeldung, genauer mit dem Access Token kommen.
Der KDC (Key Distribution Center) der standardmäßig auf jedem DC läuft, sendet nach der erfolgreichen Benutzerauthentisierung (erfolgreiche Eingabe von Benutzername und Kennwort) ein PAC (Privilege Attribute Certificate) im Ticket Granting Ticket (TGT) mit. Wenn der Client ein TGT erhält, wird das PAC vom Local Security Authority (LSA) Prozess auf dem Client dazu verwendet, um das Access Token zu erstellen. Im Access Token ist die SID des Benutzerobjekts, die SIDs der SIDHistory sowie die direkten und verschachtelten Sicherheits-Gruppenmitgliedschaften des Benutzers enthalten. Im Access Token werden ausschließlich die Mitgliedschaften in Sicherheitsgruppen und nicht in Verteilergruppen berücksichtigt! Das Access Token hat aber ein Limit von maximal 1024 Einträgen und dieser Wert lässt sich nicht verändern!
In bestimmten Szenarien kann die Kerberos-Authentifizierung fehlschlagen, wenn ein Benutzer bereits Mitglied in 70 bzw. 120 Gruppen ist.
Authentication Fails Due to User PAC: Logon and Authentication; Security Services
New resolution for problems with Kerberos authentication when users belong to many groups
Um dem Problem einer fehlgeschlagenen Benutzerauthentisierung auf die Schliche zu kommen, kann man das Kommandozeilenbefehl Whoami mit dem Parameter /all oder das Cmdlet Get-ADAccountAuthorizationGroup in der AD-PowerShell dazu verwenden. Durch beide Varianten wird das Access Token ausgewertet.
Alle Gruppenmitgliedschaften eines Benutzers exportieren
Der Nachteil von Whoami /all ist jedoch, dass man den Inhalt des Access Token nur dann auswerten kann, wenn man als der entsprechende Benutzer schon angemeldet ist. Wenn man sich allerdings erst gar nicht anmelden kann, bringt einem das Whoami /all herzlichst wenig. Die Alternative ist die AD-PowerShell. Denn damit kann man von einem x-beliebigen Rechner die Gruppenmitgliedschaften eines Benutzers auswerten, sofern die AD-PowerShell installiert ist.
Es gibt aber noch eine weitere Alternative, nämlich NTDSUTIL! Auch mit NTDSUTIL ist es so wie mit der AD-PowerShell möglich, die Gruppenmitgliedschaften eines Benutzers auszuwerten.
Unter Windows Server 2003 RTM und Windows Server 2003 SP1 steht die „Evaluierung der Gruppenmitgliedschaften“ in NTDSUTIL erst nach der Installation des Hotfix 906208 zur Verfügung.
When you try to log on to a Windows Server 2003-based domain by using a domain user account, the logon request fails
Erstmalig wurde das Problem in NTDSUTIL unter Windows Server 2003 SP2 behoben!
Die Gruppenmitgliedschaften eines Benutzers lassen sich mit NTDSUTIL wie folgt Anzeigen:
-
Im ersten Schritt gilt es in einer Kommandozeile oder unter „Ausführen“ (Windows-Taste + R) das NTDSUTIL aufzurufen.
-
Danach muss man mit group membership evaluation auf die Ebene Evaluierung der Gruppenmitgliedschaft wechseln.
-
Anschließend wird mit dem Befehl run <Domäne.Tld> <Benutzer> unter Windows Server 2003 im Verzeichnis C:\Dokumente und Einstellungen\<Benutzername> und ab Windows Server 2008 unter C:\Users\<Benutzername> eine Datei Namens <Benutzername>-<Datum/Uhrzeit>.tsv erstellt, in der alle Gruppenmitgliedschaften des angegebenen Benutzers aufgelistet sind. Die Datei lässt sich mit Notepad oder dem Editor öffnen.
-
Die Datei mit den Gruppenmitgliedschaften vom angegebenen Benutzer, sieht wie folgt aus:
Weitere Informationen:
Output is incomplete when you use the Group Membership Evaluation feature of the Ntdsutil.exe tool in Windows Server 2003
Alle Mitglieder einer Gruppe in eine neue Gruppe kopieren
AD-PowerShell Befehle
Gespeicherte Abfragen
Active Directory – Abfrage
Die Virtualisierung hat längst Einzug in vielen Unternehmen genommen. Sei es Dateiserver, Druckserver oder Applikationsserver, Dank der Virtualisierung lassen sich alle Serverrollen virtualisieren. Nicht nur das dadurch in Bezug auf Green IT Rechnung getragen wird, durch die Virtualisierung lassen sich auch die Hardwarekosten deutlich senken.
Welche Dienste unter welchem Hypervisor supportet werden, kann man hier in Erfahrung bringen:
Windows Server Catalog
Grundsätzlich lassen sich auch die Infrastrukturserver wie Domänencontroller (DC), Exchange Server und SQL Server virtualisieren. Doch gerade bei diesen Serverrollen und insbesondere bei virtuellen DCs (vDCs), gibt es einiges mehr im Betrieb zu beachten als bei physikalischen Servern. Sonst kann es unter Umständen und je nach Größe der Umgebung im Extremfall, in einem Desaster enden! Bei vDCs muss man die Stolperfallen kennen, alleine schon aus dem Grund, da bei physikalischen Servern viele Möglichkeiten erst gar nicht zur Verfügung stehen. Dabei spielt es keine Rolle, welcher Hypervisor (Hyper-V, ESX…) sich im Einsatz befindet.
Die Virtualisierung von DCs hat aber auch, neben Green IT und der Hardwareersparnis, weitere Vorteile. Sichert man einen vDC auf einer anderen Hardware zurück, kann man sich die Hardware-Abstraktion zunutze machen, da man weniger Treiberprobleme hat, als wenn man einen physikalischen DC auf einer anderen Hardware rücksichert. Auch bei der Rollentrennung hilft die Virtualisierung.
Die GOs und NO-GOs bei virtuellen DCs
-
Die Zeit: Die Zeitsynchronisation innerhalb einer AD Umgebung ist von großer Bedeutung! Denn Microsoft setzt in einer AD Umgebung seit Windows 2000 das Authentifizierungsprotokoll Kerberos in der Version 5 ein und dieses toleriert standardmäßig eine Zeitdifferenz von gerade einmal fünf Minuten. Weicht die Zeit mehr als fünf Minuten ab, verliert das Kerberos Ticket Granting Ticket (kurz TGT) seine Gültigkeit.
Der für die Zeit verantwortliche DC einer Gesamtstruktur ist der DC, der die FSMO-Rolle des PDC-Emulators in der Root-Domäne innehat! Man sollte den PDC-Emulator der Root-Domäne gegen eine externe Quelle (entweder aus dem Internet oder Hardware-Uhr) abgleichen lassen. Auf der Firewall muss dazu der Port 123 offen sein, wenn mit einer Quelle aus dem Internet abgeglichen werden soll. Der PDC-Emulator muss aber nicht seine Zeit mit einer externen Quelle abgleichen. Die tatsächliche Zeit ist nicht zwingend notwendig. Sie muss nur innerhalb einer Gesamtstruktur synchron sein!
Alle DCs holen sich ihre Zeit dann vom PDC-Emulator. Die Clients sowie Mitgliedsserver synchronisieren sich ihre Zeit mit ihrem Anmeldeserver, also von dem DC, bei dem sich der Client bzw. Mitgliedsserver authentisiert. Dieser muss nicht zwingend der PDC-Emulator sein.
Die PDC-Emulatoren der Subdomänen holen sich wiederum ihre Zeit, vom PDC-Emulator der Root-Domäne. Der PDC-Emulator der Root-Domäne ist die maßgebliche Zeitquelle für die Gesamtstruktur.
Die Zeitsynchronisation mit einer Quelle aus dem Internet, wird auf dem PDC-Emulator der Root-Domäne mit dem folgenden Befehl eingerichtet:
w32tm /config /update /manualpeerlist:de.pool.ntp.org /syncfromflags:MANUAL /reliable:YES
Wenn an W32time nichts verstellt wurde (per GPO), hat man anschließend eine funktionierende Zeitsynchronisation! Es sollte darauf geachtet werden, dass virtuelle Maschinen und gerade vDCs ihre Zeit nicht vom Hostsystem (was zum Beispiel unter Hyper-V in den Integrationsdiensten der VM standardmäßig der Fall ist), sondern von der Domäne übernehmen. Oder wenn es gewünscht ist das die vDCs ihre Zeit vom Hostsystem übernehmen, so sollte darauf geachtet werden das auf dem Hostsystem derselbe Zeitserver konfiguriert ist, der auch auf dem PDC-Emulator konfiguriert wurde.
-
Kein AD in der Hyper-V Parent Partition: Das Ausführen von DCPROMO auf einem Hyper-V Host ist ein NO-GO, erst recht nicht wenn bereits VMs auf dem Host in Betrieb sind! Auch wenn es technisch möglich ist in der Parent Partition zusätzliche Dienste auszuführen, ist es mitnichten empfohlen dies zu tun. Da unter Hyper-V sich die Treiber für die Hardware in der Parent Partition befinden und der gesamte I/O für den Speicher- sowie Netzwerkzugriff von und zu den VMs durch die Parent Partition verläuft, sollte man den Hyper-V Host nicht unnötig noch mit weiteren Diensten an seine Leistungsgrenzen bringen. Deshalb sollte der Hyper-V Host ausschließlich zur Verwaltung der VMs dienen und keineswegs zum DC gestuft werden!
Befinden sich alle in der Domäne verfügbaren vDCs auf demselben Host, wäre da noch bei einem Neustart des Hosts das Henne-Ei Problem. Ist der Host ein vDC und würden alle in der Domäne verfügbaren vDCs auf demselben Host betrieben werden, würde der Neustart des Hosts länger dauern. Denn nach einem Neustart des Hosts muss zuerst das AD-integrierte DNS auf den vDCs zur Verfügung stehen. Da bei einem Neustart aber kein DC der die DNS-Zone zur Verfügung stellt bereitsteht, kommt es zu erheblichen Verzögerungen während eines Neustarts. Wenn es sich um einen Hyper-V Cluster handelt und alle in der Domäne verfügbaren vDCs befinden sich auf dem Cluster, so hat man bei einem Neustart größere Probleme, da der Cluster ohne einen DC nicht startet!
-
Die Ausfallsicherheit: Die Ausfallsicherheit beim AD ist bereits dann gewährleistet, wenn mindestens zwei DCs innerhalb einer Domäne existieren. Natürlich sollten in einer virtualisierten Umgebung nicht alle in der Domäne verfügbaren vDCs auf demselben Host betrieben werden, sonst hat man einen Single Point of Failure (SPoF). Die Erklärung dürfte selbsterklärend sein, denn wenn der einzig verfügbare Host beispielsweise wegen einem Hardwaredefekt ausfallen sollte, würde kein vDC mehr zur Verfügung stehen und die Domäne wäre erst mal verloren. Daher ist es ratsam vDCs mindestens auf mehrere Hosts zu verteilen, wenn nicht noch zusätzlich ein physikalischer DC existiert (was zu empfehlen ist!).
Wie immer gilt, in jeder Domäne sollten sich mindestens zwei DCs befinden! Wie viele DCs pro Domäne werden benötigt?
-
Mindestens ein physikalischer DC: Es ist empfehlenswert mindestens einen physikalischen DC in der Domäne zu betreiben. Denn wenn alle DCs einer Domäne virtuell wären, ist man gegen einen Ausfall des Hypervisors (beispielsweise durch ein Windows Update) nicht geschützt. Fällt der Hypervisor aus und existieren ausschließlich vDCs, wäre die Domäne verloren. Des Weiteren ist es empfehlenswert, dass der physikalische DC die Rolle des PDC-Emulators wegen der Zeitsynchronisation innehat. Empfehlenswert ist es auch, neben dem PDC-Emulator noch die beiden gesamtstrukturweiten FSMO-Rollen Schemamaster sowie Domänennamenmaster auf den physikalischen DC zu verschieben. Die FSMO-Rollen verschieben
-
Kein Snapshot von vDCs erstellen: Allgemein ist das Erstellen eines Snapshots eine nützliche Funktion. Ein Snapshot ist eine Momentaufnahme einer VM. Vor einer Konfigurationsänderung einer VM, kann man einen Snapshot erstellen und nach einer fehlgeschlagenen Konfigurationsänderung, zum vorherigen Zustand Dank des Snapshots zurückkehren. Diese Funktion sollte aber mit Bedacht und nur auf supporteten VMs eingesetzt werden!
Da es sich beim AD um ein verteiltes Datenbanksystem handelt, darf das Snapshotfeature zum Sichern und Wiederherstellen eines vDCs keineswegs verwendet werden (nicht zu verwechseln mit dem NTDSUTIL-Snapshot)! Erst recht nicht in einer AD Umgebung mit mehr als einem DC! Ein Snapshot ist auf einem vDC, egal welcher Hypervisor eingesetzt wird, stets zu 100% nicht supportet(!) und ist ein striktes NO-GO! Denn damit verursacht man in einer AD Umgebung mit mehr als einem DC ein USN Rollback und gefährdet somit die Datenkonsistenz. Sichert man einen Snapshot zurück, wird das Betriebssystem und die AD Datenbank in einen früheren Zustand versetzt und genau durch diese Vorgehensweise, erzeugt man ein USN Rollback. Wurde ein vDC mit einem Shapshot zu einem vorherigen Stand rückgesichert, stellen ab sofort die Replikationspartner die AD-Replikation zu und von diesem vDC ein. Des Weiteren richtet das Rücksichern eines Snapshots auf einem vDC unter Umständen (RID-Master) einen erheblichen Schaden an.
Auch wenn man vorher alle DCs einer Domäne herunterfährt und danach von einem vDC ein Snapshot erstellt, bleibt die Problematik dieselbe. Sobald man einen Snapshot auf einem vDC in einer AD Umgebung mit mehr als einem DC zurücksichert, entsteht ein USN Rollback. Dabei ist es irrelevant, ob die vDCs online oder offline sind. Wenn ein Snapshot auf einem vDC zurückgesichert wird, ist mindestens der rückgesicherte vDC zerstört. Snapshots dienen auch keineswegs als Datensicherung! Auf virtuellen DCs sollte so wie auf physikalischen DCs, regelmäßig auf mindestens zwei vDCs eine System State Sicherung durchgeführt werden.
-
Kein Klon erstellen: Das Klonen eines vDCs, im Form von Duplizieren der virtuellen Festplatte (z.B. VHD), ist weder supportet und genauso wie ein SnapShot, ein striktes NO-GO! Denn wenn ein Klon in derselben Gesamtstruktur wie das Original online geht, sind die Folgen Katastrophal! Lediglich den Computernamen und die IP-Adresse zu ändern, bringt überhaupt nichts. Denn entscheidend ist der Directory Service Agent-GUID (kurz DSA-GUID), auch bekannt als objectGUID. Dieser lässt sich nicht ändern und ist in der Gesamtstruktur eindeutig.
Ferner existieren doppelte RIDs (Relative Identifiers) und doppelte SIDs. Handelt es sich bei dem geklonten vDC auch noch um den FSMO-Rolleninhaber und speziell um den RID-Master bzw. PDC-Emulator, sind die Probleme viel schlimmer! Der Anruf beim Microsoft Produkt Support Service (MSPSS) ist jedenfalls sicher.
Der RID-Master und sein RID-Pool
Zu Sicherungszwecken ist ein Klon so wie ein Snapshot, ebenfalls ganz und gar nicht geeignet und ist auch nicht supportet! Denn die Problematik ist dieselbe wie beim Rücksichern eines Snapshots. Wird ein Klon wiederhergestellt, versetzt man den vDC zu einem früheren Zustand. Auch hierbei entsteht ein USN Rollback und in einer Umgebung mit mehr als einem DC, stellen die Replikationspartner umgehend die AD-Replikation ein.
Es sollte auch vermieden werden, einen Klon in einer angeblich abgeschotteten Testumgebung zu starten, um verschiedene Tests durchzuführen. Denn das Risiko ist zu groß, das irgendwann einmal die Testumgebung aus welchen Gründen auch immer, doch Verbindung zur Produktivumgebung erhält. Möchte man sich eine Template-VM erstellen, sollte unbedingt nach der Betriebssysteminstallation SYSPREP (und nicht NEWSID!) ausgeführt werden. Denn erst wenn Sysprep (unter Windows Server 2008 R2 im Verzeichnis %windir%\System32\sysprep) ausgeführt wurde, wird die VM anonymisiert. Erst danach darf das Template geklont werden.
-
Keine Image-basierte Sicherung durchführen: Eine Image-basierte Sicherung kann beispielsweise sein, wenn ein vDC automatisiert heruntergefahren, danach kopiert und anschließend automatisiert hochgefahren wird. Oder wenn mit einem Drittanbieter Werkzeug ein Image eines vDCs erstellt wird. Die Wiederherstellung durch solch eine Sicherungsart ist ebenfalls nicht supportet und ist zugleich ein striktes NO-GO! Denn bei einer Wiederherstellung würde man so wie bei einem Snapshot oder Klon, dass Betriebssystem und die AD Datenbank in einen früheren Zustand versetzen. Die USN Rollback Problematik und vor allem der Schaden, mindestens an dem zurück geimageten vDC, ist sicher!
Deshalb gilt hier das gleiche wie bei einem Snapshot und bei einem Klon: Finger weg von dieser nicht supporteten Sicherungsart! Images als Sicherung?
-
Die vDC-Sicherung: Wie bei physikalischen DCs, sollte auf mindestens zwei vDCs das System State regelmäßig gesichert werden.
Es gibt aber noch zwei weitere Methoden, die zum Sichern und Wiederherstellen eines vDCs unterstützt werden:
1. Das Ausführen der Windows Server-Sicherung im Gastbetriebssystem ist supportet.
2. Das Ausführen der Windows Server-Sicherung auf dem Hyper-V Host ist supportet. Denn dadurch wird der VSS Writer (Volume Shadow Copy Service, Volumeschattenkopie-Dienst) des Gastbetriebssystems aufgerufen, um sicherzustellen, dass die Sicherung ordnungsgemäß durchgeführt wird.
Durch diese beiden Methoden, genauso wie beim Wiederherstellen einer System State-Sicherung, wird die invocationId der AD-Datenbank im Gast-vDC zurückgesetzt. Das ist zwingend notwendig, damit in einer AD Umgebung mit mehreren DCs die Replikationspartner bei einer Wiederherstellung eines DCs erkennen, dass ein DC ordnungsgemäß (supportet!) wiederhergestellt wurde. Die AD-Replikation wird dann ab dem Zeitpunkt des Sicherungsdatums, mit dem wiederhergestellten vDC neu aufgebaut.
Das elementare für die erfolgreiche Wiederherstellung eines DCs ist, dass die invocationId der AD-Datenbank zurückgesetzt werden muss! Denn nur so ist sichergestellt, dass der Neuaufbau der AD-Replikation in einer AD Umgebung mit mehreren DCs erfolgreich verläuft. Das ist auch der Grund, warum ein Snapshot, Klon oder Image eines DCs nicht supportet ist, da bei diesen Methoden die invocationId nicht zurückgesetzt wird! Zwei wichtige IDs eines DCs: DC GUID und InvocationId
-
Virenscanner auf dem Host: Ist auf dem Hostsystem (Hyper-V, KVM…) ein Virenscanner installiert, sollten die Verzeichnisse in denen sich zum einen die Virtuellen Festplatten (VHD…) und zum anderen die Konfigurationsdateien befinden, vom Echtzeitscanner (On-Access) des Virenscanners ausgeschlossen werden. Unter Hyper-V sind das standardmäßig die beiden Verzeichnisse C\Users\Public\Documents\Hyper-V\Virtual Hard Disks und C:\ProgramData\Microsoft\Windows\Hyper-V. Wurden andere Verzeichnisse festgelegt, sollten diese vom Echtzeitscanner ausgeschlossen werden.
Natürlich sollten auch in den VMs bestimmte Verzeichnisse vom Echtzeitscanner ausgeschlossen werden. Welche das sind, steht hier: Antivirenprogramm
-
DCs offline konvertieren (P2V): Das online Konvertieren (Physical-to-Virtual, kurz P2V) eines DCs ist nicht supportet! Wenn man einen physikalischen DC konvertieren möchte, muss der DC ausgeschaltet (heruntergefahren, nicht angehalten oder ausgesetzt) und offline konvertiert werden! Denn ausschließlich die offline Konvertierung eines DCs (unter Hyper-V z.B. mit dem System Center Virtual Machine Manager, kurz VMM) ist der einzige Weg, welcher auch von Microsoft supportet wird. Nach der offline Konvertierung darf der physikalische DC nie mehr in der Domäne gestartet werden! Aber ein P2V ist bei einem DC ohnehin nicht empfehlenswert. Empfohlen ist es auf dem Host einen zusätzlichen DC zu installieren und den physikalischen DC herunterzustufen.
- Die VM-Sicherheit: Bei dem Thema „Sicherheit“ gelten für einen vDC mindestens die gleichen Sicherheitsregeln, wie für physikalische DCs. Weiterhin muss klar definiert sein, wer beispielsweise unter Hyper-V den Host administrieren darf. Denn wer Zugriff auf die virtuellen Festplatten (und somit auf die vDCs) hat, könnte diese kopieren und hätte prinzipiell Zugriff auf alle Kennwörter! Deshalb muss der Zugriff auf die virtuellen Festplatten von vDCs genauso eingeschränkt sein, wie der Zugriff auf physikalische DCs!
-
Einen virtuellen DC niemals anhalten und niemals den Status speichern: Ein virtueller DC sollte niemals angehalten (pausiert) und es sollte niemals der Status gespeichert werden! Denn wenn ein vDC angehalten oder der Status gespeichert wird, friert man de facto die Uhrzeit und das Datum des vDCs ein. Genau das kann aber beim Wiedereinschalten des vDCs zum Problem werden, so dass die Replikationspartner die AD-Replikation mit diesem vDC einstellen und dadurch Lingering Objects (zu Deutsch, herumlungernde Objekte) entstehen. Ein vDC sollte stets heruntergefahren werden. Lingering Objects (veraltete Objekte)
- Virtuelle Festplatten mit fixer Größe konfigurieren: Es ist empfehlenswert, eine virtuelle Festplatte mit einer festen Größe zu konfigurieren. Konfiguriert man eine dynamische virtuelle Festplatte, muss man beim sizing des Hosts ohnehin die maximale Größe, die man bei einer dynamischen virtuellen Festplatte angegeben hat kalkulieren.
- Keine differenzierende virtuelle Festplatte konfigurieren: Man sollte es tunlichst vermeiden, eine differenzierende virtuelle Festplatte für einen vDC zu implementieren! Dadurch ist es zu einfach, den vDC in einen früheren Zustand zu versetzen.
Nicht einen vDC unter Hyper-V exportieren: Das Exportieren eines vDCs unter Hyper-V sollte nicht durchgeführt werden.
Weitere Informationen:
Warum es ein dedizierter DC sein sollte!
Ein AD-Schnappschuss erstellen
Das Active Directory gewaltsam vom DC entfernen
Die Tombstone Lifetime
Running Domain Controllers in Hyper-V
Things to consider when you host Active Directory domain controllers in virtual hosting environments
DC’s and VM’s – Avoiding the Do-Over
Using Domain Controller Virtual Machines
Die Active Directory (AD) Schemaversionen sind (in Dezimal) unter:
- Windows 2000 mit allen Service Packs = 13
- Windows Server 2003 mit allen Service Packs = 30
- Windows Server 2003 R2 mit allen Service Packs = 31
- Windows Server 2008 mit allen Service Packs = 44
- Windows Server 2008 R2 mit allen Service Packs = 47
- Windows Server 2012 mit allen Service Packs = 56
Das Installieren eines Service Packs ändert niemals die AD Schemaversion! Die AD Schemaversion ändert sich auch dann nicht, wenn andere Technologien (beispielsweise Exchange) installiert werden und eine Schemaaktualisierung durchführen. Oder wenn eine eigene Schemaänderung durchgeführt wird, ändert sich ebenfalls die AD Schemaversion nicht. Die AD Schemaversion ändert sich nur dann, wenn das ADPREP einer neueren Windows Server Version ausgeführt wird.
Die Information in der die AD Schemaversion enthalten ist, verbirgt sich im Attribut objectVersion, das sich in den Eigenschaften der Schemapartition befindet. Dadurch, dass die Schemapartition auf alle DCs in der Gesamtstruktur repliziert wird, kann man zur Abfrage einen lokalen DC verwenden. Deshalb besteht keine Notwendig in einer Gesamtstruktur mit mehreren Domänen, einen DC aus der Root-Domäne oder gar den globalen Katalog zu verwenden. Diese Information hat jeder DC, egal in welcher Domäne er sich befindet.
Die AD Schemaversion mit der AD-PowerShell abfragen
Mit der AD PowerShell lässt sich die AD Schemaversion folgendermaßen herausfinden:
([ADSI]"LDAP://<Domäne.TLD>/CN=Schema,CN=Configuration,DC=Root-Domäne").objectVersion
Oder mit diesem AD PowerShellbefehl:
Get-ADObject "CN=Schema,CN=Configuration,DC=Root-Domäne" -Properties objectVersion | Select objectVersion | FT -A
Die AD Schemaversion mit ADSIEdit anzeigen
Nach dem man sich in ADSIEdit (oder mit anderen LDAP-Browsern) mit der Schemapartition verbunden hat, gilt es den Eintrag zu erweitern und mit einem Rechtsklick auf den Container CN=Schema,CN=Configuration,DC=Root-Domäne im Kontextmenü die Eigenschaften des Containers aufzurufen. Dort findet man das Attribut objectVersion mit der aktuellen AD Schemaversion.
Die AD Schemaversion mit LDP anzeigen
Ist das LDP gestartet, muss man sich als erstes unter Remotedesktopverbindung – Verbinden… mit einem DC verbinden. Danach muss man sich mit dem AD unter Remotedesktopverbindung – Gebunden… binden. Ist das erfolgt, ruft man unter Durchsuchen – Suchen das Suchfenster auf und gibt folgende Daten in die Felder ein:
Basis-DN: CN=Schema,CN=Configuration,DC=Root-Domäne
Filter: (objectClass=top)
Bereich: Basis
Attribute: objectVersion
Klickt man anschließend auf Ausführen, erscheint in der rechten Hälfte von LDP das Attribut objectVersion mit der aktuellen Schemaversion.
Die AD Schemaversion mit dsquery abfragen
Auch mit dsquery lässt sich die AD Schemaversion in einer Kommandozeile abfragen. Der Befehl lautet wie folgt:
dsquery * "CN=Schema,CN=Configuration,DC=Root-Domäne" -Scope Base -attr objectVersion
Die AD Schemaversion in der Registry überprüfen
Die AD Schemaversion kann man sich auf jedem DC in der Gesamtstruktur, sogar in der Registry in dem folgenden Registrykey ansehen:
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\<Schema Version>
Im selben Registrykey existiert auch der Schlüssel System Schema Version. Dieser Schlüssel wird lediglich von der Install from Media (IFM) Funktion verwendet. Damit wird sichergestellt, dass beim heraufstufen eines DCs mit der IFM Funktion, keine ältere oder neuere Schemaversion auf dem DC wiederhergestellt wird. Dieser Wert dient zur Kontrolle.
Domänencontroller-Installation von einer Sicherung
Die Exchange Schemaversion abfragen
Exchange hat seine eigene Schemaversion. Die Schemaversion von Exchange steckt im Attribut rangeUpper, das sich in der Schemapartition im Objekt ms-Exch-Schema-Version-Pt befindet. So wie bei der AD Schemaversion, kann man für die Abfrage der Exchange Schemaversion jeden DC in der Gesamtstruktur verwenden, da sich die gewünschte Information ebenfalls in der Schemapartition befindet, die wie bereits erwähnt auf jeden DC in der Gesamtstruktur repliziert wird.
Anders als bei der AD Schemaversion, kann sich unter Exchange die Schemaversion schon beim Installieren eines Service Packs für Exchange ändern.
Die Exchange Schemaversionen sind unter:
- Exchange 2000 = 4397
- Exchange 2000 SP3 = 4406
- Exchange Server 2003 RTM = 6870
- Exchange Server 2003 SP2 = 6936
- Exchange Server 2007 RTM = 10637
- Exchange Server 2007 SP1 = 11116
- Exchange Server 2007 SP2 = 14622
- Exchange Server 2007 SP3 = 14625
- Exchange Server 2010 RTM = 14622
- Exchange Server 2010 SP1 = 14726
Die Exchange Schemaversion mit der AD-PowerShell abfragen
In der AD PowerShell findet man die Exchange Schemaversion wie folgt heraus:
([ADSI]"LDAP://Domäne.de/CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC=Root-Domäne").rangeUpper
Auch dieser AD PowerShellbefehl liefert die Schemaversion von Exchange:
Get-ADObject "CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC= Root-Domäne " -Properties rangeUpper | Select rangeUpper | FT –A
Die Exchange Schemaversion mit ADSIEdit anzeigen
Ist ADSIEdit gestartet, muss man sich zuerst mit der Schemapartition verbinden, sofern noch keine Verbindung existiert. Danach ruft man mit einem Rechtsklick auf den Container CN=Schema,CN=Configuration,DC=Root-Domäne die Eigenschaften auf und navigiert zum Attribut rangeUpper. Der Wert in diesem Attribut, ist die Exchange Schemaversion.
Die Exchange Schemaversion mit LDP anzeigen
Möchte man sich die Exchange Schemaversion in LDP anzeigen lassen, gilt es sich zuerst unter Remotedesktopverbindung – Verbinden… mit einem DC zu verbinden. Im zweiten Schritt bindet man sich unter Remotedesktopverbindung – Gebunden… mit dem AD. Als nächstes ruft man unter Durchsuchen – Suchen das Suchfenster auf und gibt folgende Daten in die Felder ein:
Basis-DN: CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC=Root-Domäne
Filter: (objectClass=*)
Bereich: Basis
Attribute: rangeUpper
Klickt man anschließend auf Ausführen, erscheint das Attribut rangeUpper mit der aktuellen Exchange Schemaversion.
Die Exchange Schemaversion mit dsquery abfragen
In der Kommandozeile lässt sich die Schemaversion von Exchange mit dsquery wie folgt abfragen:
dsquery * CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC=Root-Domäne -Scope Base -attr rangeUpper
Wenn Unternehmen fusionieren, folgt des Öfteren eine Migration. Vor einer Migration ist es gut zu wissen, welche Active Directory (AD) Schemaerweiterungen in der zu migrierenden Gesamtstruktur existieren, damit diese falls notwendig, in der Ziel-Gesamtstruktur ebenfalls zur Verfügung gestellt werden können. Mit Schemaerweiterungen sind Erweiterungen im AD Schema gemeint, die von einer Standardinstallation des AD in der entsprechenden Version (Windows 2000, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2) abweichen. Aber auch aus Dokumentationsgründen ist es empfehlenswert, die AD Schemaerweiterungen einer Gesamtstruktur stets zu kennen.
Die Schemaerweiterungen lassen sich recht einfach mit dem Tool ADSchemaAnalyzer aufspüren, dass Bestandteil des früheren ADAM (Active Directory Application Mode) und heutigen AD LDS (Active Directory Lightweight Directory Services) ist und ab Windows XP und Windows Server 2003 zur Verfügung steht. Hat man ADAM bzw. AD LDS installiert, findet man den ADSchemaAnalyzer unter allen unterstützten Betriebssystemen im Verzeichnis %windir%\ADAM.
Während man unter Windows Server 2003 ADAM noch extra herunterladen musste, befindet es sich ab Windows Server 2003 R2 unter den Windows-Komponenten bereits on Bord. Ab Windows Server 2008 findet man die AD LDS unter den Rollen. Aber auch auf den Clients Windows XP, Windows Vista und Windows 7 lässt sich ADAM bzw. AD LDS installieren und das AD Schema vergleichen. Doch vorher muss für das eingesetzte Betriebssystem, die entsprechende Version heruntergeladen werden.
Active Directory Application Mode (ADAM)
AD LDS für Windows Vista
AD LDS für Windows 7
Es ist irrelevant, auf welchem System das AD Schema verglichen wird. Ob auf einem Client, der sich in einer Arbeitsgruppe oder Domäne befindet, Standaloneserver, Mitgliedserver oder DC. Das AD Schema lässt sich stets vergleichen.
Die Vorgehensweise
- Nach der Installation des ADAM bzw. der AD LDS, startet man zuerst aus dem Verzeichnis %windir%\ADAM den ADSchemaAnalyzer. Ist das Tool gestartet, klickt man auf Datei – Zielschema laden… um das Ziel AD Schema zu laden. Möchte man das AD Schema eine aktuelle AD Umgebung dahingehend überprüfen ob es von einer Standardinstallation abweicht, so sollte als Ziel, das AD Schema der bestehenden AD Umgebung als Erstes geladen werden.
Soll jedoch das AD Schema von zwei aktuellen AD-Umgebungen verglichen werden (beispielsweise vor einer Inter-Forest Migration), ist es empfehlenswert, im ersten Durchlauf das AD Schema der einen Gesamtstruktur und in einem empfohlenen zweiten Durchlauf, das AD Schema der anderen Gesamtstruktur als Ziel AD Schema zu laden!
-
Im darauffolgenden Fenster Zielschema laden kann entweder das AD Schema von einer aktuellen AD Umgebung oder von einer LDF-Datei, eines zuvor exportierten AD Schemas geladen werden. Somit hat man die folgenden drei Möglichkeiten, um das AD Schema zu vergleichen:
- Man kann das AD Schema einer aktuellen AD Umgebung mit einer LDF-Datei vergleichen.
- Es können zwei aktuelle AD Umgebungen verglichen werden.
- Es können zwei LDF-Dateien verglichen werden. Soll das AD Schema von zwei aktuellen AD Umgebungen verglichen werden, muss vorher natürlich sichergestellt werden, dass das System auf dem der ADSchemaAnalyzer gestartet wurde, Verbindung zu beiden Gesamtstrukturen hat und die entsprechenden Rechte bestehen.
-
Das AD Schema einer AD Umgebung kann man in einer Kommandozeile mit LDIFDE wie folgt exportieren: Ldifde -F C:\ADSchema.ldf -d "CN=Schema,CN=Configuration,DC=Root-Domäne"
- Wurde das Zielschema von einer aktuellen AD Umgebung oder von einer LDF-Datei geladen, muss als nächstes unter Datei – Basisschema laden… diesmal das Basisschema geladen werden. Wenn das AD Schema einer aktuellen AD Umgebung mit einer Standardinstallation verglichen werden soll, muss als Basisschema das AD Schema der Standardinstallation, beispielsweise in Form einer LDF-Datei geladen werden.
Ein LDF-Export einer Standardinstallation eines Windows Server 2003, Windows Server 2003 R2, Windows Server 2008 und Windows Server 2008 R2 AD Schemas, wird hier zur Verfügung gestellt.
ADSchema.zip (673,58 KB)
- Ist das Basisschema geladen, muss zum Schluss noch im Menü Schema die Option Vorhandene Elemente ausblenden ausgewählt werden. Denn schließlich sollen lediglich die Unterschiede zwischen zwei AD Schemas angezeigt werden.
- Nun sieht man in der Ausgabe unter dem Container Klassen und Attribute die evtl. bestehenden Unterschiede zwischen beiden AD Schemas. Danach können die Einträge einzeln, durch das Markieren der gewünschten Klassen bzw. Attribute oder alle Unterschiede durch Auswahl von Schema – Alle nicht vorhandenen Elemente als eingeschlossen markieren exportiert werden. Zum Exportieren wählt man Datei – LDIF-Datei erstellen… .
Weitere Informationen:
ADSchemaAnalyzer
LDIFDE - LDAP Data Interchange Format Data Exchange
Der Generator für die standortübergreifende Replikationstopologie (Inter-Site Topology Generator, kurz ISTG), der, unabhängig von der Anzahl an Domänen und Verzeichnispartitionen, nur einmal pro AD-Standort existiert, ist eine Komponente des Knowledge Consistency Checker, kurz KCC. Der ISTG ist für die Berechnung der standortübergreifenden Replikationstopologie und für das Erstellen von eingehenden Replikationsverbindungen auf Bridgeheadserver (BHS) zuständig. Der ISTG ist in jedem AD-Standort auch dafür verantwortlich, automatisch einen BHS für jede Verzeichnispartition sowie für jedes Replikationstransportprotokoll an einem AD-Standort zu ermitteln. Der DC, der die Rolle des ISTG innehat, muss nicht unbedingt auch ein BHS sein!
Der BHS dient im Hinblick auf die AD-Replikation mit BHS aus anderen AD-Standorten als Brückenkopf und somit als Anlaufstelle, über den Replizierungsinformationen mit anderen AD-Standorten ausgetauscht werden. Der BHS ist der Einzige, der für die AD-Standort zu -Standort Replikation zuständig ist. Das bedeutet, über den BHS und nur über ihn, läuft die AD-Replikation zwischen den AD-Standorten (Inter-Site) ab! Dazu sammeln die BHS alle getätigten AD-Änderungen die auf allen DCs eines AD-Standorts stattgefunden haben, um diese dann zu anderen BHS aus anderen AD-Standorten zu replizieren. Deshalb erhält ein BHS an einem AD-Standort bevorzugt als erster die Replikationsdaten.
Der BHS ist dabei ausschließlich für die Verzeichnispartitionen autorisierend und repliziert auch nur die, die der BHS selbst in seiner Verzeichnisdatenbank (NTDS.dit) hält (einschließlich der Verzeichnispartitionen für den globalen Katalog). Jede Verzeichnispartition, die ein BHS eines AD-Standorts nicht innehat, benötigt einen weiteren BHS, der die entsprechende Verzeichnispartition in seiner Verzeichnisdatenbank gespeichert hat. Unter anderem können deshalb an einem AD-Standort mehrere BHS existieren. Ein BHS kann mehrere Verzeichnispartitionen über dasselbe Replikationstransportprotokoll oder auch über beide Replikationstransportprotokolle verwalten. Die AD-Replikation findet aber standortintern und standortübergreifend standardmäßig über das RPC über IP Protokoll statt. Die AD-Replikation könnte jedoch auch mit dem SMTP-Protokoll durchgeführt werden, allerdings ist das nur eingeschränkt möglich. Denn die Domänenpartition kann by Design nicht über das SMTP-Protokoll repliziert werden und es ist ein höherer Aufwand notwendig, um das entsprechend zu konfigurieren (eine Zertifizierungsstelle muss vorhanden sein).
Des Weiteren ist der ISTG für das Erstellen von eingehenden Verbindungsobjekten zwischen den BHS zuständig. Da die standortübergreifende AD-Replikation ausschließlich zwischen den BHS konfiguriert wird, werden im Gegensatz zu der standortinternen (Intra-Site) AD-Replikation, keine redundanten Verbindungsobjekte erstellt. Es werden lediglich weitere Verbindungsobjekte mit BHS in mehreren AD-Standorten erstellt, wenn es in der Standortverknüpfung (Site-Link) so konfiguriert wurde.
Einen Bridgeheadserver konfigurieren
Es gibt seit Windows 2000 mehrere Möglichkeiten einen DC als BHS für das IP- und SMTP-Protokoll zu bestimmen. Diese wären:
- Die automatische Auswahl des BHS wird dem ISTG überlassen. Standardmäßig bestimmt der ISTG eigenständig den DC, der als BHS in einem AD-Standort tätig sein soll. Es ist kein manuelles Eingreifen erforderlich. Fällt der aktuelle BHS eines AD-Standorts aus, wählt beim nächsten KCC-Lauf (standardmäßig nach maximal 15 Minuten) der ISTG automatisch und eigenständig, ohne das Zutun des Administrators, einen anderen DC am gleichen AD-Standort als BHS aus. Dabei wird der DC, der die niedrigste objectGUID am AD-Standort hat, zum BHS ausgewählt.
- Der Administrator kann aber auch manuell einen DC als bevorzugten BHS festlegen. Das kann beispielsweise dann von Interesse sein, wenn zwischen den AD-Standorten eine Firewall steht und nur gezielt einem bestimmten DC die standortübergreifende AD-Replikation erlaubt werden soll. Ein weiterer Anwendungsfall wäre zum Beispiel, wenn die meisten DCs an einem AD-Standort auf veralteter Hardware laufen und nur ein bestimmter DC, der auf aktueller Hardware läuft, soll als BHS bestimmt werden. Denn der BHS muss mehr Replikationsverkehr verarbeiten (insbesondere in größeren AD Umgebungen), als alle anderen DCs am selben AD-Standort.
Wird manuell ein DC an einem AD-Standort explizit als BHS für ein oder beide Replikationstransportprotokolle konfiguriert, bedeutet das bei einem Ausfall dieses BHS, dass der Administrator manuell einen anderen DC zum BHS deklarieren muss, damit die AD-Replikation weiterhin durchgeführt werden kann. Denn nur wenn ein vom ISTG bestimmter BHS ausfällt, wird automatisch ein anderer DC als BHS bestimmt. Deshalb sollte man wenn möglich, entweder keinen BHS manuell bestimmen und dem ISTG die automatische Auswahl des BHS überlassen oder wenn man schon manuell die BHS bestimmen möchte, sollten idealerweise mehrere (mindestens immer zwei) DCs als BHS bestimmt werden. In einer Gesamtstruktur mit mehreren Domänen sollte stets der globale Katalog (GC) an einem AD-Standort der bevorzugte BHS sein. Andernfalls wird das mit der FehlerID 1567 im Eventlog protokolliert. Wenn in einem Multi-Domain Forest an einem AD-Standort ein GC existiert, und sich nicht zusätzlich an demselben AD-Standort mindestens ein DC aus allen anderen AD-Domänen existiert, muss der GC zwingend ein BHS sein.
-
Es können vom Administrator mehrere DCs am gleichen AD-Standort als bevorzugte BHS bestimmt werden. Jedoch wählt der ISTG je nach Umgebung, nur aus den manuell bestimmten BHS einen oder mehrere BHS pro AD Standort aus. Fällt ein BHS aus, wählt der ISTG wieder automatisch von den anderen manuell bestimmten DCs einen BHS aus.
-
Wenn zwischen zwei DCs, die sich an verschiedenen AD-Standorten befinden, manuell ein Verbindungsobjekt erstellt wird, werden diese beiden DCs ebenfalls zu BHS.
Möchte man einen DC oder mehrere DCs als bevorzugten BHS konfigurieren, so kann man das in der MMC Active Directory-Standorte und -Dienste durchführen. Dazu wählt man aus einem AD-Standort den entsprechenden DC aus und wählt im Kontextmenü zuerst die Eigenschaften aus. Danach wählt man im Reiter Allgemein aus dem Feld Transporte für die standortübergreifende Datenübermittlung das entsprechende Replikationstransportprotokoll, entweder IP oder SMTP aus und fügt es in das Feld Server ist ein bevorzugter Bridgeheadserver für folgende Transporte hinzu. Damit wird der DC zum manuell bestimmten bevorzugten BHS.
Ist ein vom ISTG bestimmter BHS ausgefallen und möchte man bis zum nächsten KCC-Lauf nicht warten (max. 15 Minuten), kann man in der Kommandozeile mit Repadmin /KCC die Replikationstopologie manuell neu berechnen lassen und somit den ISTG dazu zwingen, einen neuen BHS zu bestimmen. Die Replikationstopologie kann man auch in der grafischen Oberfläche, in der MMC Active Directory-Standorte und –Dienste neu berechnen und somit einen neuen BHS vom ISTG bestimmen lassen. Dazu muss man mit einem Rechtsklick auf das NTDS Settings Objekt eines bestehenden DCs, im Kontextmenü unter Alle Aufgaben die Option Replikationstopologie überprüfen auswählen. Beide Vorgehensweisen fordern den KCC dazu auf, die Replikationstopologie zu überprüfen und bei etwaigen Veränderungen, diese anzupassen. Fällt dem ISTG bei einem KCC-Lauf auf, dass der BHS eines AD-Standorts nicht mehr existiert, bestimmt er einen anderen DC (falls ein weiterer DC an diesem AD-Standort existiert) an diesem AD-Standort zu einem BHS.
In der AD-PowerShell lässt sich manuell ein DC ebenfalls als einen bevorzugten BHS konfigurieren.
Der Befehl für das Bestimmen eines BHS für das IP-Protokoll lautet:
Set-ADObject -Identity „CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne“ -Add @{ bridgeheadTransportList=”CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=Root-Domäne“ }
Wird ein DC manuell, für ein oder beide Replikationstransportprotokolle zu einem bevorzugten BHS bestimmt, passiert im Hintergrund folgendes:
- Im mehrwertigen Forward-Link Attribut bridgeheadTransportList, das sich in den Eigenschaften des DC-Objekts befindet, wird der Distinguished Name (DN) des entsprechenden Replikationstransportprotokolls eingetragen. Also z.B. CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuation,DC=Root-Domäne.
- Auf der gegenüberliegenden Seite wird im mehrwertigen Back-Link Attribut bridgeheadServerListBL, das sich in den Eigenschaften des Replikationstransportprotokoll-Containers (in der MMC dssite.msc unter Sites – Inter-Site Transports - IP/SMTP) befindet, der DN des bestimmten BHS eingetragen. Beispielsweise: CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne.
Wird ein BHS vom ISTG bestimmt, enthalten die Attribute keinen Wert!
Bei jedem Durchlauf des ISTG überprüft dieser das Attribut bridgeheadTransportList. Ist in dem Attribut der DN eines Replikationstransportprotokolls eingetragen, wird dieser DC vom KCC als der bevorzugte BHS für das eingetragene Replikationstransportprotokoll verwendet.
Im Übrigen kann man sich alle aktuellen BHS in der Kommandozeile, mit dem Schweizer Messer Werkzeug für die AD-Replikation REPADMIN folgendermaßen anzeigen lassen: Repadmin /bridgeheads
Die Auswahl und die Lastverteilung des BHS
Windows 2000
Unter Windows 2000 kann es nur einen einzigen BHS pro AD-Standort geben! Die Auswahl des BHS ändert sich unter Windows 2000 nur, wenn der bisher ausgewählte BHS nicht mehr verfügbar ist. Das Problem mit dem BHS unter Windows 2000 ist, dass der BHS in der Zentrale (Hub) schnell zu einem Engpass werden kann, wenn die AD Standorttopologie nach der Hub-and-Spoke Topologie aufgebaut wurde und viele Außenstellen (Spokes) existieren. Denn alle BHS aus allen Außenstellen führen die standortübergreifende AD-Replikation stets nur mit dem einen BHS in der Zentrale durch. Kommen weitere DCs in der Zentrale hinzu, werden diese von den BHS in den Außenstellen nicht berücksichtigt! Es existiert also weder eine Skalierung, noch eine Lastverteilung!
Windows Server 2003
Ab Windows Server 2003 wurde das Problem mit dem einzelnen BHS pro AD-Standort behoben. Von nun an kann jeder DC an einem AD-Standort zeitgleich ein BHS sein. Es können also mehrere BHS pro AD-Standort zeitgleich existieren. Wurden mehrere DCs an einem AD-Standort manuell als BHS bestimmt, beschränken sich die möglichen BHS eines AD-Standorts auf diese DCs. Somit wurde eigentlich in Bezug auf die Skalierbarkeit sowie Lastverteilung Rechnung getragen. Man muss lediglich beim manuellen bestimmen von BHS Vorsicht walten lassen. Denn BHS werden pro Verzeichnispartition und pro Replikationstransportprotokoll bestimmt. Wird beispielsweise an einem AD-Standort kein BHS für die Schemapartition bestimmt, wird diese Verzeichnispartition (auf Englisch Naming Context, kurz NC) zu diesem AD-Standort niemals repliziert.
Diese neue Funktion der Lastverteilung hat jedoch einen gravierenden Nachteil. Denn haben sich in einer Hub-and-Spoke Topologie die BHS in den Außenstellen die Replikationstopologie mit einem BHS aus der Zentrale aufgebaut, überprüfen die BHS in den Außenstellen die Replikationstopologie nicht erneut, wenn weitere BHS Kandidaten in Form von zusätzlichen DCs in der Zentrale installiert werden. Sogar wenn mehrere DCs in der Zentrale manuell als bevorzugte BHS bestimmt werden, führen die BHS in den Außenstellen die AD-Replikation weiterhin mit dem bereits ausgewählten BHS in der Zentrale durch. Die neu hinzugefügten DCs in der Zentrale werden von den BHS in den Außenstellen einfach ignoriert.
Microsoft hat dieses Fehlverhalten erkannt. Leider erst, als Windows Server 2003 RTM wurde. Somit blieb keine Zeit mehr das im Quellcode des Serverbetriebssystems zu überarbeiten. Stattdessen wurde ein Tool entwickelt, um dieses Verhalten zu korrigieren. Das Tool heist Active Directory Load Balancer, kurz adlb.exe, und befindet sich im “Windows Server 2003 Active Directory Branch Office Guide”. Führt man das Tool jedes Mal aus, nachdem ein neuer DC in der Zentrale (Hub) hinzugefügt wurde, wird unter Berücksichtigung der neuen DCs die Replikationstopologie neu berechnet und möglicherweise weitere BHS an einem AD-Standort bestimmt. Bedauerlich dabei ist, dass man das Tool jedes Mal manuell ausführen muss, nach dem ein neuer DC hinzugefügt wurde.
Das Tool selbst und weitere Informationen dazu gibt es hier:
Windows Server 2003 Active Directory Branch Office Guide
Windows Server 2008
Unter Windows Server 2008 wurde die automatische Auswahl eines BHS verbessert, leider wieder einmal mehr halbherzig. Denn unter Windows Server 2008 nutzen lediglich Read-Only Domänencontroller (RODCs) die automatische Auswahl eines BHS. Beschreibbare DCs (RWDC) dagegen verhalten sich weiterhin wie unter Windows Server 2003, was die automatische Auswahl eines BHS anbetrifft. Das bedeutet also, dass ein RODC aus einer Außenstelle die neu hinzugefügten DCs in der Zentrale als BHS berücksichtigt, ein beschreibbarer Windows Server 2008 DC jedoch nicht. Für RODCs besteht nicht die Notwendigkeit, das zusätzliche Werkzeug adlb.exe auszuführen, denn die automatische BHS Lastverteilung ist bei RODCs standardmäßig aktiviert. Doch auf beschreibbaren Windows Server 2008 DCs muss in Bezug auf die BHS Lastverteilung, weiterhin das Tool adlb.exe ausgeführt werden, damit neue DCs als mögliche BHS berücksichtigt werden.
Möchte man die automatische Lastverteilung auf RODCs deaktivieren, zum Beispiel weil sich eine Firewall zwischen dem RODC und einem beschreibbaren DC befindet und der RODC stets die AD Aktualisierungen immer nur von einem bestimmten beschreibbaren DC erhalten soll, so kann man das mit diesem Registryeintrag, der standardmäßig nicht existiert:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Random BH Loadbalancing Allowed
1 = Aktiviert (standardmäßig)
0 = Deaktiviert
Review Bridgehead Server Load-Balancing Improvements with Windows Server 2008 RODCs
Die verbesserte Lastverteilung der BHS unter Windows Server 2008 R2
Ab Windows Server 2008 R2 wurde die BHS Lastverteilung zusätzlich zu RODCs, für beschreibbare DCs eingeführt. RODCs und vor allem beschreibbare DCs verteilen nun Replikationsverbindungen und die standortübergreifende Replikationslast gleichmäßig zwischen allen BHS, die an einem AD-Standort zur Verfügung stehen. Kommen zum Beispiel in einer Hub-and-Spoke Topologie weitere DCs in der Zentrale (Hub) und somit potentiell neue BHS dazu, berechnen Read-Only- und beschreibbare DCs aus den Außenstellen die Replikationstopologie neu. Die Replikationslast und Replikationsverbindungen werden dann stets gleichmäßig über alle DCs in der Zentrale verteilt.
Insbesondere in größeren AD Umgebungen profitiert man von dieser Verbesserung und deshalb sollten bei einer Domänenaktualisierung auf mindestens Windows Server 2008 R2, stets die DCs in der Zentrale als erste aktualisiert werden, um von der BHS Lastverteilung zu profitieren.
Es gibt aber bei dem verbesserten Auswahlverfahren eines BHS unter Windows Server 2008 R2 folgende Einschränkungen:
- Die BHS Lastverteilung funktioniert erst, wenn sich DCs mindestens in zwei AD-Standorten (logischerweise) befinden.
- Existiert eine „Full-Mesh“ AD-Standorttopologie (jeder AD-Standort repliziert mit jedem anderen), mit denselben Kosten in allen Standortverknüpfungen, kann keine Lastverteilung durchgeführt werden. Die BHS Lastverteilung findet immer zwischen zwei AD-Standorten statt.
- Wenn der KCC zum gleichen Zeitpunkt simultan auf allen BHS in den Außenstellen läuft, wird in allen eingehenden Replikationsverbindungen derselbe BHS aus der Zentrale verwendet. Erst wenn der KCC auf den BHS zwischen den Außenstellen, mindestens eine Sekunde versetzt läuft, findet die BHS Lastverteilung statt!
Weitere Informationen:
AD-PowerShell Befehle
Die Active Directory Verbindungsobjekte
Bridgehead Server Selection
How Active Directory Replication Topology Works
Use ADLB from the Windows Server 2003 Branch Office Guide to Rebalance Connections Between Writeable Domain Controllers in the Hub
The Role of the Inter-Site Topology Generator in Active Directory Replication
Description of Bridgehead Servers in Windows 2000
Möchte man im Active Directory Informationen über einen Dienst der innerhalb einer Domäne zur Verfügung stehen soll veröffentlichen, so benötigt man ein Service Connection Point (SCP) Objekt. Ein SCP wird bei der Installation von vielen Applikation automatisch, ohne das Zutun des Administrators erstellt. Die SCPs gehören zur Klasse serviceConnectionPoint, die wiederum von der Klasse connectionPoint abgeleitet ist.
Beispielsweise wird bei der Installation von Remotedesktoplizenzierung, Remote-Installation-Services, Hyper-V, Microsoft basierte virtuelle Maschinen, MS Virtual Machine Manager, der Autodiscover-Funktion ab Exchange 2007 etc. ein SCP im AD erstellt. Diese und viele anderen Dienste veröffentlichen ihr Dasein in der Domäne, durch das Erstellen von SCPs. ADAM / AD LDS stellt dabei keine Ausnahme dar. Client-Anwendungen wiederum verwenden SCPs, um den entsprechenden Dienst in der Domäne zu finden und um sich mit diesem zu verbinden.
Aktiviert man in der MMC Active Directory-Benutzer und -Computer (dsa.msc) unter Ansicht die Option Benutzer, Kontakte, Gruppen und Computer als Container, so kommen einige der SCPs unterhalb der Serverobjekte zum Vorschein.
Möchte man sich den Autodiscover SCP von Exchange in der grafischen Oberfläche anzeigen lassen, so kann man den SCP in der MMC Active Directory-Standorte und -Dienste (dssite.msc) zum Vorschein bringen. Dazu markiert man zuerst in der MMC dssite.msc mit einem Linksklick den Eintrag Active Directory-Standorte und -Dienste [FQDN des DCs], ruft mit einem Rechtklick das Kontextmenü auf und aktiviert unter Ansicht die Option Dienstknoten anzeigen. Danach navigiert man zum folgenden Container:
Services\Microsoft Exchange\<Exchange Organisation>\Administrative Groups\Exchange Administrative Group (FYDIBOHF23SPDLT)\Servers\<Exchange Server>\Protocols\Autodiscover\
Im Container Autodiscover findet man dann den SCP <Exchange Server>.
In ADSIEdit oder jedem anderen LDAP-Browser findet man den Autodiscover SCP von Exchange in der Konfigurationspartition im folgenden LDAP-Pfad:
CN=<Exchange Server>,CN=Autodiscover,CN=Protocols,CN=<Exchange Server>,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=<Exchange Organisation>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Root-Domäne
Die SCPs mit der AD-PowerShell abfragen
Welche SCPs innerhalb einer Domäne von welchen Objekten im AD veröffentlicht wurden, erfährt man mit diesem AD-Powershellbefehl:
Get-ADObject -LDAPFilter "(objectClass=serviceConnectionPoint)" | Select distinguishedName | FT -A –Wrap
In der Ausgabe erhält man den Distinguished Name (DN) aller SCPs die in der Domäne existieren. Aus dem DN lässt sich auch ableiten, welches Objekt den SCP erstellt hat.
Welche SCPs in der Konfigurationspartition existieren (bspw. Autodiscover von Exchange), kann man sich folgendermaßen anzeigen lassen:
Get-ADObject -LDAPFilter "(objectClass=serviceConnectionPoint)" -Searchbase "CN=Configuration,DC=Root-Domäne" | Select distinguishedName | FT -A -Wrap
Bestimmte SCPs mit der AD-PowerShell abfragen
Man kann natürlich auch nur bestimmte SCPs abfragen. Möchte man sich beispielsweise alle Hyper-V Hosts in der Domäne anzeigen lassen, so kann man dies mit diesem AD-PowerShellbefehl folgendermaßen durchführen:
Get-ADObject -LDAPFilter "(&(objectClass=serviceConnectionPoint)(CN=Microsoft Hyper-V))" | Select distinguishedName | FT -A -Wrap
Alle Microsoft basierte virtuelle Maschinen innerhalb einer Domäne, lassen sich mit diesem AD-PowerShellbefehl wie folgt Anzeigen:
Get-ADObject -LDAPFilter "(&(objectClass=serviceConnectionPoint)(CN=Windows Virtual Machine))" | Select distinguishedName | FT -A -Wrap
Den Autodiscover SCP von Exchange kann man sich wie folgt anzeigen lassen:
Get-ADObject -LDAPFilter "(objectClass=serviceConnectionPoint)" -Searchbase "CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Root-Domäne" | Select distinguishedName | FT -A -Wrap
Den Server auf dem die Remotedesktoplizenzierung installiert ist, kann man sich mit diesem AD-PowerShellbefehl anzeigen lassen:
Get-ADObject -LDAPFilter "(&(objectClass=serviceConnectionPoint)(CN=TermServLicensing))" | Select distinguishedName | FT -A -Wrap
Die SCPs mit dem Kommandozeilentool dsquery abfragen
Alle SCPs innerhalb der Gesamtstruktur (unter anderem Autodiscover von Exchange) lassen sich mit dsquery wie folgt Anzeigen:
dsquery * Forestroot -Filter (objectClass=serviceConnectionPoint)
Alle SCPs innerhalb der Domäne lassen sich mit dsquery wie folgt Anzeigen:
dsquery * Domainroot -Filter (objectClass=serviceConnectionPoint)
Bestimmte SCPs mit dsquery abfragen
Alle Hyper-V Hosts innerhalb einer Domäne lassen sich mit dem folgenden dsquery Befehl Anzeigen:
dsquery * Domainroot –Filter "(&(objectClass=serviceConnectionPoint)(CN=Microsoft Hyper-V))"
Alle Microsoft basierte virtuelle Maschinen innerhalb einer Domäne werden mit dsquery wie folgt angezeigt:
dsquery * Domainroot –Filter "(&(objectClass=serviceConnectionPoint)(CN=Windows Virtual Machine))"
Mit dsquery lässt sich der Server auf dem die Remotedesktoplizenzierung installiert ist, folgendermaßen Anzeigen:
dsquery * Domainroot –Filter "(&(objectClass=serviceConnectionPoint)(CN=TermServLicensing))"
Ersetzt man in den dsquery Befehlen das Domainroot durch Forestroot, wird die Abfrage in der Gesamtstruktur durchgeführt.
Weitere Informationen:
Creating a Service Connection Point
Where to Create a Service Connection Point
Publishing with Service Connection Points
Der Infrastrukturmaster ist dafür verantwortlich, die Integrität der Objektreferenzen zwischen domänenübergreifenden Objekten innerhalb einer Gesamtstruktur aktuell zu halten. Beispielsweise bei domänenübergreifenden Gruppenmitgliedschaften.
Fügt man in einem Single-Domain Forest ein Sicherheitsprinzipal, wie es ein Benutzer, eine Gruppe oder ein Computer darstellt, zu einer Gruppe hinzu, wird der Distinguished Name (DN) des Sicherheitsprinzipals ins member Attribut (Forward-Link) der Gruppe hinzugefügt. Das AD erstellt im Gegenzug ohne ein zusätzliches Objekt einen Back-Link (das memberOf Attribut im Sicherheitsprinzipal) und referenziert damit das Sicherheitsprinzipal, das zur Gruppe hinzugefügt wurde. Benennt man ein Sicherheitsprinzipal um, verschiebt oder löscht es, wird automatisch das member Attribut der Gruppe aktualisiert. Da der Infrastrukturmaster seine Aufgabe erst in einem Multi-Domain Forest wahrnimmt, befindet er sich in einem Single-Domain Forest in einem inaktiven Zustand, da es für ihn keine Arbeit gibt.
Möchte man aber innerhalb eines Multi-Domain Forest beispielsweise den BenutzerA aus der DomäneA zur GruppeB aus der DomäneB hinzufügen, so hat das AD ein Problem. Denn das AD kann keinen Back-Link zu einem Objekt erstellen, das sich in einer anderen Domäne und somit in einer anderen Domänenpartition befindet. Das AD löst dieses Problem durch das Erstellen eines Phantomobjekts. Mit Phantomobjekten (nicht zu verwechseln mit Tombstones, Lingering Objects oder Foreign Security Principals) ist es möglich, Objekte in anderen Domänen innerhalb der Gesamtstruktur zu referenzieren. Innerhalb der AD-Datenbank wird eine Referenz auf das Objekt als ein Zeiger auf das Phantomobjekt repräsentiert. Phantomobjekte werden also erst dann erstellt, wenn in der Gesamtstruktur mehr als eine Domäne existiert und zwischen zwei Objekten, die sich in verschiedenen Domänen befinden, eine Verknüpfung besteht!
Phantomobjekte werden aber nur vom Infrastrukturmaster erstellt. Deshalb ist es der Infrastrukturmaster aus der DomäneB, der ein Phantomobjekt für BenutzerA erstellt. Das Gruppenobjekt „GruppeB“ verweist mit dem Phantomobjekt auf das Benutzerobjekt „BenutzerA“. Dabei enthält das Phantomobjekt eine minimale Menge an Informationen, damit ein DC das ursprüngliche Objekt (BenutzerA) an seinem ursprünglichen Ort referenzieren kann. Jedes Phantomobjekt in der AD-Datenbank enthält vom referenzierten Objekt die folgenden Informationen: objectGUID, objectSID (für Verweise auf Sicherheitsprinzipale) und den DN des Objekts.
Der Infrastrukturmaster ist auch für die Verwaltung eines Phantomobjekts verantwortlich. Wenn das Sicherheitsprinzipal (BenutzerA), auf das sich ein Phantomobjekt bezieht, umbenannt, verschoben oder gelöscht wird, aktualisiert der Infrastrukturmaster das Phantomobjekt. Dazu vergleicht der Infrastrukturmaster in regelmäßigen Abständen die Phantomobjekte mit den Informationen vom globalen Katalog (GC). Stellt der Infrastrukturmaster dabei eine Abweichung fest, aktualisiert er das Phantomobjekt. Die Aktualisierung repliziert er dann zu seinen Replikationspartnern innerhalb der Domäne, die ebenfalls eine Kopie des Phantoms besitzen. Ohne diese Vorgehensweise würden die eigentlichen Änderungen an den referenzierten Objekten (z.B. BenutzerA wird umbenannt) nicht an das gegenüberliegende Objekt (GruppeB) übertragen werden.
Da der globale Katalog regelmäßig Aktualisierungen für alle Objekte in der Gesamtstruktur erhält, sind die Daten auf dem GC stets auf dem aktuellen Stand. Dadurch das ein GC bereits über ein Teilreplikat aller Objekte in der Gesamtstruktur besitzt, speichert er auch keine Phantomobjekte. Denn er kennt bereits jedes Objekt aus allen Domänen innerhalb der Gesamtstruktur und somit existieren keine Verweise auf Objekte, die ein GC nicht kennt. Daher darf der Infrastrukturmaster in einem Multi-Domain Forest nicht einem GC zugewiesen werden, denn er würde keine Unterschiede erkennen. Der Infrastrukturmaster leistet seine Arbeit innerhalb seiner Domäne ausschließlich an DCs, die kein GC sind.
Wird allerdings in einem Multi-Domain Forest auf jedem DC in der Domäne, in der auf dem Infrastrukturmaster der GC aktiviert wurde ebenfalls der GC aktiviert, werden auf keinem der DCs dieser Domäne jemals Phantomobjekte erstellt. Daher erübrigt sich das Aktualisieren der Phantomobjekte. Denn alle DCs dieser Domäne kennen bereits durch das Aktivieren des GC alle Objekte in der Gesamtstruktur und somit hat der Infrastrukturmaster nichts zu tun. In solch einem Fall wird der Infrastrukturmaster ebenfalls in einen inaktiven Zustand versetzt.
Die FSMO-Rollen verschieben
Übrigens wird das Entfernen eines Phantomobjekts nicht vom Infrastrukturmaster, sondern vom Garbage Collection Prozess durchgeführt.
Weitere Details zu Phantomobjekten liefert der folgende Artikel:
Phantome im Active Directory
Wenn der AD-Papierkorb in der Gesamtstruktur aktiviert ist
Ist allerdings der AD-Papierkorb aktiviert, der sich erst ab dem Gesamtstrukturfunktionsmodus „Windows Server 2008 R2“ aktivieren lässt, ist die Funktion des Infrastrukturmasters nicht mehr länger an einen einzelnen DC gebunden! Die Aufgabe des Infrastrukturmasters ist jetzt auf alle DCs in der Gesamtstruktur verteilt. Jeder DC in einem Multi-Domain Forest ist für die Aktualisierung seiner domänenübergreifenden Objektverweise, sprich, für das Phantomobjekt das sich in seiner lokalen AD-Datenbank befindet, verantwortlich. In dem Fall, dass das referenzierte Sicherheitsprinzipal umbenannt, verschoben oder gelöscht wird, aktualisiert jeder DC sein Phantomobjekt.
Wenn also der AD-Papierkorb aktiviert ist, hat der Infrastrukturmaster keine Aufgaben mehr und es ist irrelevant, welcher DC die FSMO-Rolle des Infrastrukturmaster innehat!
Der Active Directory-Papierkorb im Windows Server 2008 R2
Weitere Informationen:
Verknüpfte Attribute
Die verknüpften Attribute abfragen
Lingering Objects (veraltete Objekte)
Globaler Katalog (Global Catalog - GC)
Was passiert in der AD-Datenbank wenn ein Objekt gelöscht wird?
Phantoms, tombstones and the infrastructure master
7.1.5.5 Infrastructure FSMO Role
Verknüpfte Attribute (linked attributes) sind Verknüpfungspaare, die aus einem Forward-Link und einem Back-Link Attribut bestehen. Ob es sich bei einem Attribut im AD-Schema um ein verknüpftes Attribut handelt, wird von dem linkID Attribut bestimmt, das sich im attributeSchema-Objekt befindet. Das linkID Attribut im Forward-Link enthält immer einen geraden und das linkID Attribut im verknüpften Back-Link enthält stets einen ungeraden Wert, nämlich den Wert „Forward-linkID plus 1“. Der Administrator kann dabei ausschließlich das Forward-Link Attribut bearbeiten, nicht jedoch das Back-Link Attribut! Repliziert werden nur die Forward-Link Attribute, nicht jedoch die Back-Links.
Weitere Details liefert der folgende Artikel:
Verknüpfte Attribute
Alle verknüpften Attribute mit der AD-PowerShell abfragen
Alle Forward- und Back-Link Attribute die im AD-Schema existieren, kann man sich mit der AD-PowerShell wie folgt anzeigen lassen:
Get-ADObject -LDAPFilter "(&(objectClass=attributeSchema)(linkID=*))" -Properties lDAPDisplayName,linkID -SearchBase "CN=Schema,CN=Configuration,DC=AD2008R2,DC=Dikmenoglu,DC=DE" -searchScope oneLevel | Select lDAPDisplayName,linkID | Sort-Object linkID | FT -A
Alle verknüpften Attribute mit dem Kommandozeilentool dsquery abfragen
Mit dsquery lassen sich alle Forward- und Back-Link Attribute folgendermaßen anzeigen:
dsquery * "CN=Schema,CN=Configuration,DC=AD2008R2,DC=Dikmenoglu,DC=DE" -Scope oneLevel -Filter "(&(objectClass=attributeSchema)(linkID=*))" -attr lDAPDisplayName linkID -Limit 0
Alle verknüpften Attribute mit LDP abfragen
Nachdem man sich in LDP mit einem DC verbunden und mit dem AD “gebunden” hat, muss man unter Durchsuchen – Suchen zuerst diesen Filter angeben: (&(objectClass=attributeSchema)(linkID=*)). Es genügt als Suchbereich die Option Eine Ebene zu wählen und im Feld Attribute, die beiden Attribute lDAPDisplayName;linkID anzugeben. Anschließend werden alle verknüpften Attribute angezeigt.
Die verknüpften Attribute mit einem AD-PowerShell Skript abfragen
Mit dem folgenden AD-PowerShell Skript kann man sich gezielt nur die Forward-Link, Back-Link oder Forward- und Back-Link Attribute anzeigen lassen. Für das Skript ist es zwingend notwendig, dass die AD-PowerShell Cmdlets zur Verfügung stehen. Die AD-PowerShell, die out-of-the-box unter Windows Server 2008 R2 zur Verfügung steht, lässt sich auch in einer Windows Server 2003 und Windows Server 2008 Umgebung einsetzen. In diesen Umgebungen ist es jedoch erforderlich, das Active Directory Management Gateway Service bereitzustellen.
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
######################################################
#
# AD-PowerShell Skript zum Anzeigen von Forward-Link,
# Back-Link oder Forward- und Back-Link Attribute
#
# Von: Yusuf Dikmenoglu 11/2010
#
# http://blog.dikmenoglu.de
#
######################################################
clear
$auswahl = Read-Host "Welche Attribut Art soll angezeigt werden (1...Forward-Link 2...Back-Link 3...Forward- und Back-Link):"
switch ($auswahl){
1 {
Get-ADObject -LDAPFilter "(&(objectClass=attributeSchema)(linkID=*))" -Properties lDAPDisplayName,linkID -SearchBase "CN=Schema,CN=Configuration,DC=Root-Domäne" -searchScope oneLevel | Sort-Object linkID | ForEach-Object {
if (!($_.linkID % 2)){
Write-Host "Forward-Link: " $_.lDAPDisplayName $_.linkID
}
}
}
2 {
Get-ADObject -LDAPFilter "(&(objectClass=attributeSchema)(linkID=*))" -Properties lDAPDisplayName,linkID -SearchBase "CN=Schema,CN=Configuration,DC=Root-Domäne" -searchScope oneLevel | Sort-Object linkID | ForEach-Object {
if ($_.linkID % 2){
Write-Host "Back-Link: " $_.lDAPDisplayName $_.linkID
}
}
}
3 {
Get-ADObject -LDAPFilter "(&(objectClass=attributeSchema)(linkID=*))" -Properties lDAPDisplayName,linkID -SearchBase "CN=Schema,CN=Configuration,DC=Root-Domäne" -searchScope oneLevel | Sort-Object linkID | ForEach-Object {
if ($_.linkID % 2){
Write-Host "Back-Link: " $_.lDAPDisplayName $_.linkID
}
else {
Write-Host "Forward-Link: " $_.lDAPDisplayName $_.linkID
}
}
}
default{
Write-Host "Ungültige Eingabe"
}
}
In einer Windows Server 2008 R2 AD Umgebung ohne jegliche AD-Erweiterung (wie beispielsweise eigene Schemaerweiterungen, Exchange etc.), existieren folgende 97 verknüpfte Attribute:
member 2
memberOf 3
manager 42
directReports 43
owner 44
ownerBL 45
siteObject 46
siteObjectBL 47
nonSecurityMember 50
nonSecurityMemberBL 51
queryPolicyObject 68
queryPolicyBL 69
privilegeHolder 70
isPrivilegeHolder 71
managedBy 72
managedObjects 73
hasPartialReplicaNCs 74
msDS-IsPartialReplicaFor 75
hasMasterNCs 76
masteredBy 77
syncMembership 78
serverReference 94
serverReferenceBL 95
bridgeheadTransportList 98
bridgeheadServerListBL 99
netbootServer 100
netbootSCPBL 101
frsComputerReference 102
frsComputerReferenceBL 103
fRSMemberReference 104
fRSMemberReferenceBL 105
fRSPrimaryMember 106
siteLinkList 142
siteList 144
msCOM-PartitionLink 1040
msCOM-PartitionSetLink 1041
msDS-NC-Replica-Locations 1044
msFRS-Hub-Member 1046
msCOM-UserPartitionSetLink 1048
msCOM-UserLink 1049
msDS-SDReferenceDomain 2000
msDS-HasInstantiatedNCs 2002
msDS-NonMembers 2014
msDS-NonMembersBL 2015
msDS-MembersForAzRole 2016
msDS-MembersForAzRoleBL 2017
msDS-OperationsForAzTask 2018
msDS-OperationsForAzTaskBL 2019
msDS-TasksForAzTask 2020
msDS-TasksForAzTaskBL 2021
msDS-OperationsForAzRole 2022
msDS-OperationsForAzRoleBL 2023
msDS-TasksForAzRole 2024
msDS-TasksForAzRoleBL 2025
msDS-HasDomainNCs 2026
msDS-IsDomainFor 2027
msSFU30PosixMember 2030
msSFU30PosixMemberOf 2031
msDS-hasMasterNCs 2036
msDs-masteredBy 2037
msDS-ObjectReference 2038
msDS-ObjectReferenceBL 2039
msPKIDPAPIMasterKeys 2046
msPKIAccountCredentials 2048
msDFSR-ComputerReference 2050
msDFSR-ComputerReferenceBL 2051
msDFSR-MemberReference 2052
msDFSR-MemberReferenceBL 2053
msDS-KrbTgtLink 2100
msDS-KrbTgtLinkBl 2101
msDS-RevealedUsers 2102
msDS-RevealedDSAs 2103
msDS-hasFullReplicaNCs 2104
msDS-IsFullReplicaFor 2105
msDS-NeverRevealGroup 2106
msDS-RevealOnDemandGroup 2110
msDS-AuthenticatedAtDC 2112
msDS-AuthenticatedToAccountlist 2113
msDS-NC-RO-Replica-Locations 2114
msDS-NC-RO-Replica-Locations-BL 2115
msDS-PSOAppliesTo 2118
msDS-PSOApplied 2119
addressBookRoots2 2122
globalAddressList2 2124
templateRoots2 2126
msDS-BridgeHeadServersUsed 2160
msPKI-CredentialRoamingTokens 2162
msDS-OIDToGroupLink 2164
msDS-OIDToGroupLinkBl 2165
msDS-HostServiceAccount 2166
msDS-HostServiceAccountBL 2167
msDS-EnabledFeature 2168
msDS-EnabledFeatureBL 2169
msTSPrimaryDesktop 2170
msTSPrimaryDesktopBL 2171
msTSSecondaryDesktops 2172
msTSSecondaryDesktopBL 2173
In einer Windows Server 2008 R2 und Exchange 2010 SP1 Umgebung, existieren folgende 314 verknüpfte Attribute:
member 2
memberOf 3
altRecipient 12
altRecipientBL 13
publicDelegates 14
publicDelegatesBL 15
homeMDB 32
homeMDBBL 33
manager 42
directReports 43
owner 44
ownerBL 45
siteObject 46
siteObjectBL 47
nonSecurityMember 50
nonSecurityMemberBL 51
queryPolicyObject 68
queryPolicyBL 69
privilegeHolder 70
isPrivilegeHolder 71
managedBy 72
managedObjects 73
hasPartialReplicaNCs 74
msDS-IsPartialReplicaFor 75
hasMasterNCs 76
masteredBy 77
syncMembership 78
serverReference 94
serverReferenceBL 95
bridgeheadTransportList 98
bridgeheadServerListBL 99
netbootServer 100
netbootSCPBL 101
frsComputerReference 102
frsComputerReferenceBL 103
fRSMemberReference 104
fRSMemberReferenceBL 105
fRSPrimaryMember 106
authOrig 110
authOrigBL 111
dLMemSubmitPerms 112
dLMemSubmitPermsBL 113
unauthOrig 114
unauthOrigBL 115
dLMemRejectPerms 116
dLMemRejectPermsBL 117
responsibleLocalDXA 122
assocRemoteDXA 123
supportingStack 132
supportingStackBL 133
siteLinkList 142
siteList 144
msExchHomeSyncService 146
msExchChildSyncAgreements 147
msExchRoutingGroupMembersDN 1000
msExchHomeRoutingGroupDNBL 1001
msExchSourceBridgeheadServersDN 1002
msExchBridgeheadedLocalConnectorsDNBL 1003
msExchTargetBridgeheadServersDN 1004
msExchBridgeheadedRemoteConnectorsDNBL 1005
msExchCASchemaPolicy 1006
msExchSchemaPolicyConsumers 1007
msExchOwningPFTree 1008
msExchOwningPFTreeBL 1009
msExchPolicyList 1012
msExchPolicyListBL 1013
msExchUseOAB 1014
msExchUseOABBL 1015
msExchAddressListServiceLink 1016
msExchAddressListServiceBL 1017
msExchComputerLink 1018
msExchExchangeServerLink 1019
msExchConferenceZone 1020
msExchConferenceZoneBL 1021
msExchMasterService 1022
msExchMasterServiceBL 1023
msExchExportContainersLinked 1028
msExchExportContainersBL 1029
msExchResponsibleMTAServer 1030
msExchResponsibleMTAServerBL 1031
msExchImportContainerLinked 1032
msExchAppliesToSmtpVS 1034
msExchAppliesToSmtpVSBL 1035
msExchConferenceMailbox 1036
msExchConferenceMailboxBL 1037
msExchMCUHostsSites 1038
msExchMCUHostsSitesBL 1039
msCOM-PartitionLink 1040
msCOM-PartitionSetLink 1041
msDS-NC-Replica-Locations 1044
msFRS-Hub-Member 1046
msCOM-UserPartitionSetLink 1048
msCOM-UserLink 1049
msExchHomeRoutingGroup 1050
msExchRoutingGroupMembersBL 1051
msExchMobileMailboxPolicyLink 1058
msExchMobileMailboxPolicyBL 1059
msExchAvailabilityPerUserAccount 1060
msExchAvailabilityPerUserAccountBL 1061
msExchAvailabilityOrgWideAccount 1062
msExchAvailabilityOrgWideAccountBL 1063
msExchUMDTMFFallbackAutoAttendantLink 1064
msExchUMDTMFFallbackAutoAttendantBL 1065
msExchOWATranscodingFileTypes 1066
msExchOWATranscodingFileTypesBL 1067
msExchOWAAllowedFileTypes 1068
msExchOWAAllowedFileTypesBL 1069
msExchOWAAllowedMimeTypes 1070
msExchOWAAllowedMimeTypesBL 1071
msExchOWAForceSaveFileTypes 1072
msExchOWAForceSaveFileTypesBL 1073
msExchOWAForceSaveMIMETypes 1074
msExchOWAForceSaveMIMETypesBL 1075
msExchOWABlockedFileTypes 1076
msExchOWABlockedFileTypesBL 1077
msExchOWABlockedMIMETypes 1078
msExchOWABlockedMIMETypesBL 1079
msExchOWARemoteDocumentsAllowedServers 1080
msExchOWARemoteDocumentsAllowedServersBL 1081
msExchOWARemoteDocumentsBlockedServers 1082
msExchOWARemoteDocumentsBlockedServersBL 1083
msExchOWARemoteDocumentsInternalDomainSuffixList 1084
msExchOWARemoteDocumentsInternalDomainSuffixListBL 1085
msExchOWATranscodingMimeTypes 1086
msExchOWATranscodingMimeTypesBL 1087
msExchSMTPReceiveDefaultAcceptedDomainLink 1088
msExchSMTPReceiveDefaultAcceptedDomainBL 1089
msExchHABShowInDepartments 1090
msExchHABShowInDepartmentsBL 1091
msExchHABRootDepartmentLink 1092
msExchHABRootDepartmentBL 1093
msExchHABChildDepartmentsLink 1094
msExchHABChildDepartmentsBL 1095
msExchMobileRemoteDocumentsAllowedServers 1096
msExchMobileRemoteDocumentsAllowedServersBL 1097
msExchMobileRemoteDocumentsBlockedServers 1098
msExchMobileRemoteDocumentsBlockedServersBL 1099
msExchMobileRemoteDocumentsInternalDomainSuffixList 1100
msExchMobileRemoteDocumentsInternalDomainSuffixListBL1101
msExchServerSite 1102
msExchServerSiteBL 1103
msExchHostServerLink 1104
msExchHostServerBL 1105
msExchMDBAvailabilityGroupLink 1110
msExchMDBAvailabilityGroupBL 1111
msExchConfigurationUnitLink 1112
msExchConfigurationUnitBL 1113
msExchPolicyTagLink 1114
msExchPolicyTagLinkBL 1115
msExchRoleLink 1116
msExchRoleBL 1117
msExchUserLink 1118
msExchUserBL 1119
msExchDomainRestrictionLink 1120
msExchDomainRestrictionBL 1121
msExchConfigRestrictionLink 1122
msExchConfigRestrictionBL 1123
msExchApprovalApplicationLink 1124
msExchArbitrationMailboxesBL 1125
msExchCoManagedByLink 1126
msExchCoManagedObjectsBL 1127
msExchModeratedByLink 1128
msExchModeratedObjectsBL 1129
msExchOrganizationsGlobalAddressListsLink 1130
msExchOrganizationsGlobalAddressListsBL 1131
msExchOrganizationsAddressBookRootsLink 1132
msExchOrganizationsAddressBookRootsBL 1133
msExchOrganizationsTemplateRootsLink 1134
msExchOrganizationsTemplateRootsBL 1135
msExchExchangeRPCServiceArrayLink 1136
msExchExchangeRPCServiceArrayBL 1137
msExchParentPlanLink 1178
msExchParentPlanBL 1179
msExchBypassModerationLink 1180
msExchBypassModerationBL 1181
msExchBypassModerationFromDLMembersLink 1182
msExchBypassModerationFromDLMembersBL 1183
msExchFedAcceptedDomainLink 1184
msExchFedAcceptedDomainBL 1185
msExchServerAssociationLink 1186
msExchServerAssociationBL 1187
msExchSupervisionUserLink 1188
msExchSupervisionUserBL 1189
msExchSupervisionDLLink 1190
msExchSupervisionDLBL 1191
msExchSupervisionOneOffLink 1192
msExchSupervisionOneOffBL 1193
msExchMailboxMoveTargetMDBLink 1194
msExchMailboxMoveTargetMDBBL 1195
msExchRBACPolicyLink 1196
msExchRBACPolicyBL 1197
msExchMailboxMoveSourceMDBLink 1198
msExchMailboxMoveSourceMDBBL 1199
msExchArchiveDatabaseLink 1200
msExchArchiveDatabaseBL 1201
msExchRMSComputerAccountsLink 1202
msExchRMSComputerAccountsBL 1203
msExchDelegateListLink 1204
msExchDelegateListBL 1205
msExchDeviceAccessControlRuleLink 1206
msExchDeviceAccessControlRuleBL 1207
msOrg-Leaders 1208
msOrg-LeadersBL 1209
msExchIntendedMailboxPlanLink 1210
msExchIntendedMailboxPlanBL 1211
msExchDefaultPublicMDB 1212
msExchDefaultPublicMDBBL 1213
msExchMailboxMoveSourceUserLink 1214
msExchMailboxMoveSourceUserBL 1215
msExchMailboxMoveStorageMDBLink 1216
msExchMailboxMoveStorageMDBBL 1217
msExchMailboxMoveTargetUserLink 1218
msExchMailboxMoveTargetUserBL 1219
msExchSharedConfigLink 1220
msExchSharedConfigBL 1221
msExchMailboxMoveSourceArchiveMDBLink 1222
msExchMailboxMoveSourceArchiveMDBBL 1223
msExchMailboxMoveTargetArchiveMDBLink 1224
msExchMailboxMoveTargetArchiveMDBBL 1225
msExchShadowManagerLink 1226
msExchSupportedSharedConfigLink 1228
msExchSupportedSharedConfigBL 1229
msExchDisabledArchiveDatabaseLink 1230
msDS-SDReferenceDomain 2000
msDS-HasInstantiatedNCs 2002
msDS-NonMembers 2014
msDS-NonMembersBL 2015
msDS-MembersForAzRole 2016
msDS-MembersForAzRoleBL 2017
msDS-OperationsForAzTask 2018
msDS-OperationsForAzTaskBL 2019
msDS-TasksForAzTask 2020
msDS-TasksForAzTaskBL 2021
msDS-OperationsForAzRole 2022
msDS-OperationsForAzRoleBL 2023
msDS-TasksForAzRole 2024
msDS-TasksForAzRoleBL 2025
msDS-HasDomainNCs 2026
msDS-IsDomainFor 2027
msSFU30PosixMember 2030
msSFU30PosixMemberOf 2031
msDS-hasMasterNCs 2036
msDs-masteredBy 2037
msDS-ObjectReference 2038
msDS-ObjectReferenceBL 2039
msPKIDPAPIMasterKeys 2046
msPKIAccountCredentials 2048
msDFSR-ComputerReference 2050
msDFSR-ComputerReferenceBL 2051
msDFSR-MemberReference 2052
msDFSR-MemberReferenceBL 2053
msExchELCFolderLink 2054
msExchELCFolderBL 2055
msExchMailboxTemplateLink 2056
msExchMailboxTemplateBL 2057
msExchUMTemplateLink 2058
msExchUMTemplateBL 2059
msExchUMRecipientDialPlanLink 2060
msExchUMRecipientDialPlanBL 2061
msExchUMServerDialPlanLink 2062
msExchUMServerDialPlanBL 2063
msExchUMIPGatewayDialPlanLink 2064
msExchUMIPGatewayDialPlanBL 2065
msExchUMIPGatewayServerLink 2066
msExchUMIPGatewayServerBL 2067
msExchUMAutoAttendantDialPlanLink 2068
msExchUMAutoAttendantDialPlanBL 2069
msExchUMDialPlanDefaultAutoAttendantLink 2070
msExchUMDialPlanDefaultAutoAttendantBL 2071
msExchUMHuntGroupDialPlanLink 2072
msExchUMHuntGroupDialPlanBL 2073
msExchELCExpiryDestinationLink 2080
msExchAttachmentFilteringExceptionConnectorsLink 2082
msExchJournalingRulesLink 2084
msExchMailboxOABVirtualDirectoriesLink 2086
msExchMailboxOABVirtualDirectoriesBL 2087
msExchOABVirtualDirectoriesLink 2088
msExchOABVirtualDirectoriesBL 2089
msExchELCAutoCopyAddressLink 2090
msExchUMMailboxPolicyDialPlanLink 2092
msExchUMMailboxPolicyDialPlanBL 2093
msExchSmtpSendReceiveConnectorLink 2094
msExchTransportSubmissionServerOverrideList 2096
msExchServerAdminDelegationLink 2098
msExchServerAdminDelegationBL 2099
msDS-KrbTgtLink 2100
msDS-KrbTgtLinkBl 2101
msDS-RevealedUsers 2102
msDS-RevealedDSAs 2103
msDS-hasFullReplicaNCs 2104
msDS-IsFullReplicaFor 2105
msDS-NeverRevealGroup 2106
msDS-RevealOnDemandGroup 2110
msDS-AuthenticatedAtDC 2112
msDS-AuthenticatedToAccountlist 2113
msDS-NC-RO-Replica-Locations 2114
msDS-NC-RO-Replica-Locations-BL 2115
msDS-PSOAppliesTo 2118
msDS-PSOApplied 2119
addressBookRoots2 2122
globalAddressList2 2124
templateRoots2 2126
msDS-BridgeHeadServersUsed 2160
msPKI-CredentialRoamingTokens 2162
msDS-OIDToGroupLink 2164
msDS-OIDToGroupLinkBl 2165
msDS-HostServiceAccount 2166
msDS-HostServiceAccountBL 2167
msDS-EnabledFeature 2168
msDS-EnabledFeatureBL 2169
msTSPrimaryDesktop 2170
msTSPrimaryDesktopBL 2171
msTSSecondaryDesktops 2172
msTSSecondaryDesktopBL 2173
Gibt ein Benutzer sein Kennwort öfter falsch ein, als es in der Kontosperrungsrichtlinie oder in einem PSO (Password Setting Objects, ab Windows Server 2008) konfiguriert ist, wird sein Benutzerkonto gesperrt. Einige Administratoren verwechseln das mit einem deaktivierten Benutzerkonto. Das Deaktivieren eines Benutzerkontos ist jedoch ein administrativer Vorgang, der manuell mit entsprechenden administrativen Rechten durchgeführt werden muss.
Das Attribut, in dem der Zeitpunkt der Kontosperrung gespeichert ist, lautet lockoutTime.
Das Attribut lockoutTime kann dabei folgende Werte enthalten:
- Bei einem Benutzerkonto, das noch nie gesperrt wurde, der Benutzer sich also bisher immer erfolgreich an der Domäne authentisieren konnte, enthält das Attribut lockoutTime als Wert <Nicht festgelegt>. Wie oft der Benutzer ein falsches Kennwort eingeben darf bis sein Benutzerkonto gesperrt wird, kann von der Kontosperrungsrichtlinie, bzw. ab Windows Server 2008 durch ein PSO, vorgegeben werden.
- Hat ein Benutzer sein Kennwort häufiger falsch eingegeben, als es in der Kontosperrungsrichtlinie oder in einem PSO definiert ist, wird sein Benutzerkonto gesperrt. Dabei wird in lockoutTime ein Large Integer Wert eingetragen, der den Zeitpunkt der Kontosperrung darstellt.
- Wenn ein Benutzerkonto nach den Vorgaben der Kontosperrungsrichtlinie oder durch ein PSO automatisch wieder entsperrt wurde, bleibt in lockoutTime vorerst weiterhin der Zeitpunkt der Kontosperrung als ein Large Integer Wert gespeichert. Das Attribut lockoutTime enthält dann zwar weiterhin einen Zeitwert, aber der Haken Konto ist gesperrt in den Eigenschaften des Benutzerkontos ist nicht mehr gesetzt.
- Wenn sich jedoch der Benutzer nach der Kontosperrdauer an der Domäne erfolgreich authentisiert, wird lockoutTime genullt. Als Wert wird in lockoutTime „0“ gespeichert. Auch wenn ein gesperrtes Benutzerkonto vom Administrator entsperrt wurde, erhält das Attribut lockoutTime in den Eigenschaften des entsprechenden Benutzerkontos den Wert 0.
Der LDAP-Filter, mit dem man die gesperrten Benutzerkonten beispielsweise mit einer benutzerdefinierten gespeicherten Abfrage in der MMC Active Directory-Benutzer und -Computer ermitteln kann, lautet:
(&(sAMAccountType=805306368)(lockoutTime>=1))
Wenn jedoch in der Kontosperrungsrichtlinie oder in dem zugewiesenen PSO definiert ist, dass ein Benutzer nach einer bestimmten Zeit automatisch entsperrt wird, greift diese Abfrage nach den tatsächlich gesperrten Benutzerkonten nicht! Denn nach der automatischen Entsperrung des Benutzerkontos bleibt der Zeitpunkt der Kontosperrung in lockoutTime, noch bevor sich der Benutzer erfolgreich an der Domäne authentisiert, gespeichert. Dadurch werden mit dem genannten LDAP-Filter auch die mittlerweile automatisch entsperrten Benutzerkonten angezeigt.
Insbesondere, wenn man Besuch vom Conficker Wurm hat, der alle Benutzer im AD sperrt, möchte man zügig die echten gesperrten Benutzer finden und idealerweise alle gleichzeitig entsperren.
Mit dem oben genannten LDAP-Filter funktioniert die Suche nach den tatsächlich gesperrten Benutzerkonten nur, wenn ein möglichst aktueller Zeitwert verwendet wird. Wenn beispielsweise der Conficker Wurm am 10.10.2010 um 08:05 Uhr alle Benutzerkonten im AD sperrt, könnte man als Zeitangabe den 10.10.2010 – 08:00 Uhr verwenden. Der umgerechnete Large Integer Wert lautet 129311640045030000 und demnach würde der LDAP-Filter wie folgt aussehen:
(&(sAMAccountType=805306368)(lockoutTime>=129311640045030000))
Aber die Suche nach den tatsächlich gesperrten und vor allem das Entsperren dieser Benutzerkonten, lässt sich ganz einfach realisieren. Die Lösung ist wieder einmal die AD-PowerShell! Mit diesem State of the Art Werkzeug lässt sich das schnell und einfach mit einem Einzeiler erledigen.
Mit diesem Befehl werden alle tatsächlich gesperrten Benutzer angezeigt:
Search-ADAccount –LockedOut | FT Name
Mit dem folgenden Befehl werden alle tatsächlich gesperrten Benutzer entsperrt:
Search-ADAccount -LockedOut | Unlock-ADAccount
Danach bleibt, bis zur erfolgreichen Authentisierung des entsprechenden Benutzers an der Domäne, der Zeitpunkt der Kontosperrung weiterhin in lockoutTime gespeichert, aber die Benutzerkonten sind entsperrt!
Wer noch eine Windows Server 2003 bzw. Windows Server 2008 Umgebung betreibt und unter anderem von der AD-PowerShell noch nicht sofort profitieren kann, der kann die „AD Management Gateway Services“ installieren und kommt somit ebenfalls in den Genuß der AD-PowerShell.
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
Weitere Informationen:
Password Setting Objects erstellen und verwalten
Einen Large Integer Wert umrechnen
AD-PowerShell Befehle
Gespeicherte Abfragen
Gespeicherte Abfragen für dsa.msc
Objektdelegierungen einrichten
Der Objektdelegierungsassistent
Ein Verbindungsobjekt (auf Englisch: connection object) ist ein Active Directory-Objekt, das eine direkte logische Replikationsverbindung zwischen zwei Domänencontrollern (DC) darstellt. Bei den Verbindungsobjekten handelt es sich stets um unidirektionale Pull-Replikationsverbindungen. Dabei werden die Verbindungsobjekte automatisch von der Konsistenzprüfung (bekannt als Knowledge Consistency Checker, kurz KCC) erstellt und in der Konfigurationspartition, im folgenden LDAP-Pfad gespeichert:
CN=<Verbindungsobjekt>,CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne
Der KCC, der standardmäßig alle 15 Minuten die Replikationstopologie auf jedem DC neu berechnet, ist ein Active Directory Prozess. Er ist dafür zuständig, dass zum einen die Verbindung zwischen den Replikationspartnern besteht und zum anderen in der Gesamtstruktur eine effiziente sowie fehlertolerante Replikationstopologie entsteht. Dazu erstellt der KCC alle notwendigen Verbindungsobjekte. In der Regel erfordern diese keine Änderungen durch den Administrator. Die Anzahl der Verbindungsobjekte die vom KCC erstellt werden, hängt logischerweise von der Anzahl der DCs ab.
Das Merkmal eines vom KCC erstellten Verbindungsobjekts ist der Name der Replikationsverbindung. Dieser kann in der MMC Active Directory-Standorte und -Dienste (dssite.msc) überprüft werden und lautet <automatisch generiert>.
Wenn aber die vom KCC automatisch berechnete Replikationstopologie nicht den Anforderungen genügt, kann der Administrator an den Verbindungsobjekten Änderungen vornehmen. Der Administrator kann ein neues Verbindungsobjekt erstellen oder ein vom KCC erstelltes Verbindungsobjekt bearbeiten. Beides ist jedoch in den meisten Umgebungen nicht notwendig!
Das manuelle Erstellen eines neuen Verbindungsobjekts
Verbindungsobjekte können nicht nur vom KCC, sondern auch vom Administrator manuell erstellt werden. Zum Beispiel um die Replikationstopologie des Netzwerks anzupassen, oder um die Anzahl an Hops von einem DC zu einem anderen bestimmten DC zu verringern. Das hat aber einen gewaltigen Nachteil! Denn die Verbindungsobjekte, die vom KCC erstellt wurden, werden auch von diesem verwaltet. Das bedeutet, wenn Verbindungsobjekte durch den KCC erstellt werden, werden sie automatisch durch den KCC entfernt, sobald sich die Replikationstopologie ändert. Somit ist ein manuelles Eingreifen nicht erforderlich! Dahingegen werden die Verbindungsobjekte, die manuell vom Administrator erstellt wurden, nicht vom KCC entfernt, wenn sich die Replikationstopologie einmal ändern sollte. Manuell erstellte Verbindungsobjekte werden nicht vom KCC verwaltet und müssen, bei etwaigen Veränderungen in der Replikationstopologie, immer vom Administrator manuell entfernt werden. Das erfordert die Aufmerksamkeit des Administrators.
Ein vom Administrator erstelltes Verbindungsobjekt erkennt man am Namen. Wenn der Administrator ein neues Verbindungsobjekt erstellt, erhält es eine GUID als Namen, den man anschließend umbenennen kann.
Beim Erstellen eines Verbindungsobjekts muss der Quell-DC angegeben werden, von dem die AD-Änderungen repliziert werden sollen. Ist das Verbindungsobjekt erstellt, kann anschließend der Zeitplan bearbeitet werden und bei einem Verbindungsobjekt, das für die standortübergreifende AD-Replikation verwendet wird, kann zusätzlich noch das Transport-Protokoll geändert werden. In der grafischen Oberfläche wird ein Verbindungsobjekt in der MMC dssite.msc erstellt. Dort navigiert man zum AD-Standort, an dem sich der entsprechende DC befindet, wählt den DC aus und ruft mit einem Rechtsklick auf das NTDS Settings Objekt die Option „Neu à Verbindung“ auf.
Der KCC verwendet jedes manuell erstellte Verbindungsobjekt, als wenn er es selbst erstellt hätte. Gegebenenfalls führt der KCC aber eine erneute Konfiguration an den Verbindungsobjekten durch, um eventuell fehlende Verbindungsobjekte auszugleichen.
Das Bearbeiten eines vom KCC erstellten Verbindungsobjekts
Ändert der Administrator ein vom KCC erstelltes Verbindungsobjekt, erhält es als Namen ebenfalls eine GUID. Daran lässt sich in der MMC dssite.msc leicht erkennen, welche Verbindungsobjekte nicht vom KCC, sondern ausschließlich vom Administrator verwaltet werden (müssen)! Das Verbindungsobjekt lässt sich jedoch umbenennen, damit es leichter identifiziert werden kann.
In den Eigenschaften eines Verbindungsobjekts kann man den Zeitplan und den Quell-DC ändern. Im Zeitplan kann man definieren, an welchen Wochentagen, zu welcher Uhrzeit und wie oft (man hat die Wahl zwischen Keine, Einmal-, Zweimal- oder Viermal pro Stunde) die Replikation durchgeführt werden soll. Dabei muss man allerdings zwischen der standortinternen (Intra-Site) und standortübergreifenden (Inter-Site) AD-Replikation unterscheiden!
Denn standardmäßig findet die standortinterne AD-Replikation, ab dem Gesamtstrukturfunktionsmodus „Windows Server 2003“, bereits 15 Sekunden nach einer AD-Änderung statt. Bei der standortinternen AD-Replikation dient das Intervall im Verbindungsobjekt lediglich dazu, dass falls eine Änderungsbenachrichtigung durch einen Ziel-DC nicht empfangen bzw. verarbeitet werden sollte (beispielsweise wegen Überlastung), jeder DC im konfigurierten Intervall (standortintern standardmäßig „Einmal pro Stunde“) seine Replikationspartner in jedem Fall anfragt, ob es Änderungen gab. Falls ja, repliziert der Ziel-DC die AD-Änderungen als wenn er eine Änderungsbenachrichtigung erhalten hätte. Das Replikationsintervall im Intra-Site Verbindungsobjekt („Einmal pro Stunde“) wird vom NTDS Site Settings Objekt, genauer vom Attribut schedule das sich in den Eigenschaften des "NTDS Site Settings Objekt" befindet, vererbt.
Bei der standortübergreifenden AD-Replikation gilt der Zeitplan, der in der Standortverknüpfung (Site-Link) definiert ist. Dort ist festgelegt, dass standardmäßig alle 180 Minuten die standortübergreifende AD-Replikation stattfindet.
Das Intervall aus der Standortverknüpfung wird auf die Verbindungsobjekte, die für die standortübergreifende AD-Replikation verwendet werden, vererbt. Ändert man das Intervall in der Standortverknüpfung, werden automatisch die entsprechenden Verbindungsobjekte aktualisiert! Die Verbindungsobjekte werden aber weiterhin vom KCC verwaltet.
In den Eigenschaften eines Verbindungsobjekts kann man auch im Feld Replizierte Namenskontexte erkennen, welche Verzeichnispartitionen über dieses Verbindungsobjekt repliziert werden.
Ein manuell erstelltes oder bearbeitetes Verbindungsobjekt vom KCC verwalten lassen
Wurde ein Verbindungsobjekt manuell erstellt oder ein vom KCC erstelltes Verbindungsobjekt bearbeitet, trägt der Administrator die Verantwortung für dieses Verbindungsobjekt. Doch oft wird in der täglichen Praxis versehentlich eine Änderung an einem Verbindungsobjekt durchgeführt und selten steckt eine absichtlich gewollte administrative Änderung dahinter.
Die Nachteile der vom Administrator erstellten Verbindungsobjekte sind:
- Das Verbindungsobjekt bleibt weiterhin bestehen, obwohl es nicht mehr benötigt wird.
- Beim Ändern des Intervalls in der Standortverknüpfung vererbt sich die Aktualisierung nicht automatisch auf ein Verbindungsobjekt, das für die standortübergreifende AD-Replikation verwendet wird.
- Neue Anwendungsverzeichnispartitionen werden nicht automatisch repliziert.
Deshalb ist es empfehlenswert, wann immer möglich, die Verwaltung der Verbindungsobjekte dem KCC zu überlassen. Er verrichtet seine Arbeit zuverlässig und berechnet bei Veränderungen zeitnah die Replikationstopologie neu und gleicht eventuell fehlende Verbindungsobjekte aus.
Möchte man statt manuell verwalteter automatisch generierte und vom KCC verwaltete Verbindungsobjekte erhalten, so hat man folgende Möglichkeiten:
- Man löscht das manuell erstellte oder bearbeitete Verbindungsobjekt und wartet maximal 15 Minuten. Denn für den Aufbau der Replikationstopologie ist wie bereits erwähnt der KCC zuständig, der auf jedem DC alle 15 Minuten die Replikationstopologie neu berechnet. Spätestens nach 15 Minuten erstellt der KCC automatisch die notwendigen Verbindungsobjekte.
- Wer die Replikationsunterbrechung von maximal 15 Minuten nicht in Kauf nehmen kann, muss den KCC in der MMC dssite.msc manuell anstoßen, nach dem das entsprechende Verbindungsobjekt gelöscht wurde. Dazu gilt es mit einem Rechtsklick auf das NTDS Settings Objekt, unterhalb des entsprechenden DC-Objekts, die Option Replikationstopologie überprüfen unter Alle Aufgaben auszuwählen. Dadurch berechnet der KCC die Replikationstopologie sofort und erstellt die fehlenden Verbindungsobjekte.
- Auch mit dem Allroundwerkzeug für die AD-Replikation, REPADMIN, lässt sich der KCC sofort ausführen. Führt man in der Kommandozeile den Befehl REPADMIN /KCC <DC> aus, berechnet der KCC die Replikationstopologie neu und erstellt die erforderlichen Verbindungsobjekte.
Das Attribut options in den Eigenschaften eines Verbindungsobjekts
Doch die Verwaltung der manuell erstellten oder bearbeiteten Verbindungsobjekte lässt sich auch ohne das Löschen von Verbindungsobjekten und ohne eine Replikationsunterbrechung an den KCC im laufenden Betrieb übergeben! Dazu muss das options Attribut, das sich in den Eigenschaften des Verbindungsobjekts befindet, bearbeitet werden. Diese Vorgehensweise bietet sich ebenfalls für dann an, wenn man eine manuell verwaltete Replikationstopologie an den KCC übergeben und somit automatisch generierte Verbindungsobjekte erhalten möchte.
Das Attribut options im Verbindungsobjekt besteht aus einer Bitmaske, wobei die Bedeutung der Einzelnen Flags von Objektklasse zu Objektklasse variiert. Die Klassen, in denen das Attribut options existiert, sind: interSiteTransport, nTDSConnection, nTDSDSA, nTDSSiteSettings und siteLink. Wobei das options Attribut im Verbindungsobjekt wie das Verbindungsobjekt selbst zur Klasse nTDSConnection gehört.
Enthält das Attribut options den Wert 1 (Dezimal), wird das Verbindungsobjekt vom KCC verwaltet. Wird das vom KCC erstellte Verbindungsobjekt durch den Administrator geändert, ändert sich der Wert im Attribut options. Erstellt der Administrator ein Verbindungsobjekt, erhält das Attribut options den Wert 0 (Dezimal).
Das Attribut options im Verbindungsobjekt, besteht aus den folgenden Flags, wobei mehrere gleichzeitig gesetzt werden können:
- Bit 0 - Dezimal 1 – Hex 0x1 (IS_GENERATED): Das Verbindungsobjekt wird vom KCC verwaltet. Das ist der Wert, der am meisten verwendet wird.
- Bit 1 - Dezimal 2 – Hex 0x2 (TWOWAY_SYNC): Ist dieses Flag gesetzt, findet eine bidirektionale Replikation zwischen dem Quell- und Ziel-DC über ein und dasselbe Verbindungsobjekt statt, wozu ansonsten zwei Verbindungsobjekte nötig wären. Dieses Flag gibt an, dass der Ziel-DC den Quell-DC nach Abschluss der eingehenden Replikation darüber zu informieren hat, das der Quell-DC in die umgekehrte Richtung replizieren muss. Dieses Feature ist in Dial-up Szenarien interessant, in denen nur einer der beiden DCs eine DFÜ-Verbindung initiieren kann.
- Bit 2 - Dezimal 4 - Hex 0x4 (OVERRIDE_NOTIFY_DEFAULT): Mit diesem Flag werden die Benachrichtigungen überschrieben und die Replikationsdaten komprimiert.
- Bit 3 - Dezimal 8 - Hex 0x8 (USE_NOTIFY): Ist dieses Bit gesetzt, wird die Änderungsbenachrichtigung verwendet.
- Bit 4 - Dezimal 16 - Hex 0x10 (DISABLE_INTERSITE_COMPRESSION): Dieses Flag deaktiviert die Datenkomprimierung bei der standortübergreifende (Inter-Site) AD-Replikation.
- Bit 5 - Dezimal 32 - Hex 0x20 (USER_OWNED_SCHEDULE): Ist dieses Flag gesetzt, wurde vom Administrator ein benutzerdefinierter Zeitplan konfiguriert.
- Bit 6 - Dezimal 64 - Hex 0x40 (RODC_TOPOLOGY): Dieses Flag wird für die AD-Replikation zu einem RODC gesetzt. Wenn der KCC das Verbindungsobjekt eines RODCs erstellt, erhält das Attribut options den Dezimalwert 65. Der Wert 65 bedeutet, dass Bit 0 (IS_GENERATED) und Bit 6 (RODC_TOPOLOGY) gesetzt sind.
Options
Alle Verbindungsobjekte die vom Administrator verwaltet werden abfragen und vom KCC verwalten lassen
Alle Verbindungsobjekte die nicht vom KCC, sondern vom Administrator verwaltet werden und es sich nicht um ein Verbindungsobjekt eines RODCs handelt, kann man sich mit diesem AD-PowerShellbefehl Anzeigen lassen:
Get-ADObject -LDAPFilter "(&(objectCategory=nTDSConnection)(!(|(options:band:=1)(options:band:=65))))" -Properties Name -Searchbase "CN=Configuration,DC=Root-Domäne" -SearchScope Subtree | Select Name,DistinguishedName | FT -A -Wrap
Sollen alle manuell verwalteten Verbindungsobjekte ab sofort vom KCC verwaltet werden, so kann man das durch diesen AD-PowerShellbefehl erreichen:
Get-ADObject -LDAPFilter "(&(objectCategory=nTDSConnection)(!(|(options:band:=1)(options:band:=65))))" -Properties options -Searchbase "CN=Configuration,DC=Root-Domäne" -SearchScope Subtree | Set-ADObject -Replace @{options=1}
Übrigens kann man sich mit dem Befehl Repadmin /showconn <DC>, alle Verbindungsobjekte vom angegebenen DC anzeigen lassen.
Weitere Informationen:
Die Vektoren zur Steuerung der AD-Replikation
Die dringende AD-Replikation
Die Inter-Site (standortübergreifende) Änderungsbenachrichtigung aktivieren
Die Linked Value Replikation (LVR)
Zwei wichtige IDs eines DCs: DC GUID und InvocationId
Die unterschiedliche Größe der AD-Datenbank
Domänencontroller vergleichen
Die Active Directory-Replikation stellt sicher, dass der Datentransfer zwischen Verzeichnispartitionen auf unterschiedlichen Domänencontrollern (DCs) ordnungsgemäß durchgeführt wird. Dabei achtet das AD zum einen darauf, dass bei der Replikation keine Endlosschleifen entstehen und zum anderen, die AD-Daten unabsichtlich nicht repliziert werden. Deshalb enthält jede Verzeichnispartition mehrere Replikationsmetadaten, die sich auf die Replikation der jeweiligen Verzeichnispartition beziehen. Anhand der Replikationsmetadaten verwalten die DCs den Datentransfer von Verzeichnisänderungen. Denn neben der Übertragung der eigentlichen Daten, werden vom AD zusätzliche Informationen zu dieser Änderung übertragen. In den zusätzlichen Informationen sind unter anderem die Informationen zu dem DC enthalten, auf dem die ursprüngliche Änderung durchgeführt wurde, das Datum und die Uhrzeit der Änderung.
Da es sich bei der AD-Replikation um einen hochkomplexen Vorgang handelt, benötigen die DCs einen Mechanismus, der sicherstellt, dass zwischen zwei DCs nur die erforderlichen Änderungen repliziert werden. Dazu ist es notwendig, dass die DCs Änderungen, die noch nicht repliziert wurden, ermitteln können und sofern vorhanden, anschließend nur diese erforderlichen Änderungen replizieren. Ohne einen solchen Mechanismus würde jeder DC bei jeder AD-Replikation die komplette AD-Datenbank replizieren. Deshalb verwendet das AD für die Replikationsverwaltung eine Kombination aus der Update Sequence Number (USN), den beiden Vektoren High-Watermark Vector (HWMV) sowie Up-To-Dateness Vector (UTDV) und dem Änderungsstempel, bestehend aus der Versionsnummer (versionID) und dem Zeitstempel.
Aktualisierungstypen
Auf einem beschreibbaren DC können zwei Arten von Aktualisierungen an den AD-Informationen durchgeführt werden. Dabei handelt es sich um die ursprüngliche Aktualisierung (originating update) und um die replizierte Aktualisierung (replicated update).
Eine ursprüngliche Aktualisierung (auch bekannt als Ursprungsschreibvorgang) findet auf einem DC stets dann statt, wenn ein AD-Objekt bearbeitet, gelöscht, hinzugefügt oder verschoben wird.
Eine replizierte Aktualisierung findet hingegen dann statt, wenn die auf einem anderen DC durchgeführten AD-Änderungen auf den lokalen DC repliziert werden. Zwischen dem DC, auf dem die Aktualisierung durchgeführt wurde und seinen direkten Replikationspartnern muss es sich dabei nicht unbedingt um eine direkte eins-zu-eins Replikation handeln. Eine einzelne, replizierte Aktualisierung hat möglicherweise ihren Ursprung in einer Reihe von ursprünglichen Aktualisierungen auf demselben Objekt. Diese ursprünglichen Aktualisierungen können durchaus auch auf verschiedenen DCs durchgeführt worden sein. Beispielsweise wird auf DC1 im Benutzerobjekt Yusuf die Beschreibung und zur gleichen Zeit wird im selben Benutzerobjekt auf DC2 die Mailadresse geändert. DC3 erhält nun die Änderungen die im Benutzerobjekt Yusuf vorgenommen wurden separat von DC1 und DC2. Anschließend erhält DC4 von DC3 alle Änderungen durch eine einzige replizierte Aktualisierung.
Es findet also per se für jede beliebige Änderung im AD immer eine ursprüngliche Aktualisierung auf dem DC statt, auf dem die Änderung durchgeführt wurde. Alle anderen DCs erhalten die ursprüngliche Aktualisierung dann über die AD-Replikation aber nur dann, wenn sie ein Replikat der entsprechenden Verzeichnispartition besitzen. Dabei handelt es sich bei jeder ursprünglichen Aktualisierung im AD um eine vollständige Transaktion. Entweder wird der gesamte Ursprungsschreibvorgang in die AD-Datenbank übernommen oder nichts!
Die Update Sequence Number (USN)
Für die AD-Replikation ist es elementar zu erkennen, welche Daten sich geändert haben und infolgedessen repliziert werden müssen. Dabei basiert die Erkennung der Daten die repliziert werden müssen, auf der Update Sequence Number (USN), zu Deutsch Aktualisierungssequenznummer. Die USN ist ein 64Bit Wert und wird zum schnellen Auffinden indiziert. Ein Quell-DC verwendet USNs um festzustellen, welche Änderungen bei seinen direkten Replikationspartnern, die von ihm die aktuellsten Änderungen anfordern, bereits eingegangen sind. Der Ziel-DC wiederum verwendet USNs, um zu bestimmen, welche Änderungen er von seinem Replikationspartner benötigt, die er sich dann per Pull-Replikation repliziert. Jedes Attribut in jedem Objekt hat bereits seine eigene USN!
Jeder ursprünglichen und replizierten Aktualisierung wird automatisch eine fortlaufende DC-spezifische USN zugewiesen und diese hat im Vergleich mit anderen DCs, keine Bedeutung. Wenn zum Beispiel bei einem Benutzer die E-Mailadresse (das Attribut mail) auf DC01 geändert wird, erhält die Aktualisierung der Mailadresse auf diesem DC die USN 9530. Nach der Replizierung dieser Änderung, vergibt der direkte Replikationspartner DC02 derselben Mailadresse die USN 43643. Die nächste Änderung auf DC01 würde die USN 9531 erhalten, unabhängig vom geänderten Objekt.
Die USN der einzelnen Attribute eines bestimmten Objekts, auf einem bestimmten DC, kann man sich mit dem Kommandozeilentool REPADMIN wie folgt anzeigen lassen: Repadmin /showobjmeta <DC> "<DN des entsprechenden Objekts>“. Die USN der Attribute, sind in der Repadmin-Ausgabe, in der Spalte Lok.USN zu sehen.
Lässt man sich mit demselben Befehl die USNs der Einzelnen Attribute desselben Objekts von einem anderen DC anzeigen, so erkennt man, dass sich die USNs der Attribute komplett unterscheiden.
Beide DCs besitzen zwar erkennbar über komplett verschiedene USNs für dasselbe Objekt, aber das ist in Bezug auf die AD-Replikation einer Änderung Bedeutungslos.
Werden stattdessen während einer Aktualisierung mehrere Attribute eines Objekts gleichzeitig geändert (z.B. die Straße, Postfach, Ort, Bundesland, Postleitzahl und Land eines Benutzers), erhält jedes geänderte Attribut dieselbe USN. Somit wird der gesamten Aktualisierung nur eine einzige USN zugewiesen.
Welche drei Möglichkeiten für die Zuweisung einer USN gibt es?
Wird eine Änderung im AD vorgenommen, gibt es drei Möglichkeiten für die Zuweisung einer USN. Die erste wäre, der lokale USN-Wert wird mit dem geänderten Attribut gespeichert. Im geänderten Attribut wird die USN mit dem lokalen USN Wert gekennzeichnet. Führt man diesen REPADMIN-Befehl aus Repadmin /showobjmeta <DC> "<DN des entsprechenden Objekts>“, sieht man den lokalen USN Wert der Einzelnen Attribute in der Spalte Lok.USN.
Als nächstes wird die USN für das indizierte Attribut uSNChanged im geänderten Objekt verwendet. Das system only Attribut uSNChanged, das in jedem Objekt enthalten ist, kennzeichnet die höchste USN für jedes beliebige Attribut des Objekts. Oder anders ausgedrückt, das Attribut uSNChanged enthält die USN für die letzte Änderung an einem Objekt, die auf diesem DC durchgeführt wurde. Dabei wird die lokale USN, zusammen mit dem Attribut uSNChanged sowohl bei einer ursprünglichen Aktualisierung, als auch bei einer replizierten Aktualisierung angewendet. Durch beide Aktualisierungstypen wird die lokale USN und das Attribut uSNChanged eines DCs erhöht! Wenn beispielsweise die Mailadresse (das Attribut mail) eines Benutzers geändert wird, erhält zum einen das Attribut mail, als auch das Attribut uSNChanged denselben USN Wert, z.B. 6700. Wird anschließend die Beschreibung (das Attribut description) im selben Benutzerobjekt, auf demselben DC geändert, erhält die lokale USN des Attributs description als auch uSNChanged im Benutzerobjekt denselben Wert, also 6701. Der Wert in der lokalen USN des Attributs mail bleibt jedoch weiterhin auf 6700 bestehen, da diese USN bei der letzten Änderung dem Attribut mail auf diesem DC zugeordnet wurde.
Wenn man in der MMC Active Directory-Benutzer und -Computer (dsa.msc) unter Ansicht die Option „Erweiterte Features“ aktiviert, findet man anschließend in den Eigenschaften eines Objekts, im Reiter Objekt, unter anderem die aktuelle USN (das Attribut uSNChanged) des Objekts.
Und zuletzt wird die USN im originating USN, auf Deutsch im ursprünglichen USN Wert gespeichert, die im Up-To-Dateness Vector (UTDV) verwendet wird. Dieser Wert wird nur bei einer ursprünglichen Aktualisierung festgelegt. Bei einem Ursprungsschreibvorgang auf einem DC, wird die neue USN mit jedem aktualisierten Attribut im lokalen USN Wert und zusätzlich im ursprünglichen USN Wert gespeichert. Im Gegensatz zur lokalen USN und dem Attribut uSNChanged, wird die ursprüngliche USN mit dem Wert des aktualisierten Attributs repliziert. Führt man den Befehl Repadmin /showobjmeta <DC> "<DN des entsprechenden Objekts>“ auf einem deutschen DC aus, findet man die ursprüngliche USN in der Spalte Ur. USN. Wenn zum Beispiel die Straße im Benutzerobjekt Yusuf auf dem DC geändert wird, erhält im Attribut streetAddress die lokale USN, die ursprüngliche USN und das Attribut uSNChanged denselben Wert!
Wird nun die geänderte Straße repliziert, wird neben dem geänderten Attribut streetAddress auch die ursprüngliche USN repliziert, die im Übrigen auf dem Ziel-DC nicht geändert wird. Auf dem Ziel-DC wird aber die lokale USN und das Attribut uSNChanged bearbeitet, da beide Werte DC-spezifisch sind. Die ursprüngliche USN wird so lange nicht geändert, bis das Attribut erneut aktualisiert wird.
Man kann erkennen, dass das Benutzerobjekt Yusuf Dikmenoglu auf dem R2DCON01 erstellt und das Attribut streetAddress am 25.08.2010 um 23:15:46 Uhr auf dem R2DCON02 geändert wurde.
Die höchste USN eines DCs
Jeder DC merkt sich auch in einem eigens dafür vorgesehenen Attribut, welche USN er als letztes einer lokalen AD-Änderung zugewiesen hat. Dabei kann eine lokale AD-Änderung durch eine ursprüngliche und replizierte Aktualisierung stattfinden. Die aktuelle USN eines DCs, sprich die letzte bestätigte bzw. zugewiesene USN des DCs, wird im Attribut highestCommittedUSN gespeichert. Dieses Attribut befindet sich in den Eigenschaften des rootDSE-Objekts, wobei jeder DC sein eigenes rootDSE Objekt besitzt. Mit anderen Worten: Das Attribut highestCommittedUSN enthält die höchste USN auf diesem DC!
Der Wert im Attribut highestCommittedUSN ändert sich bereits, sobald ein DC gestartet wird. Denn es werden Änderungen an der AD-Datenbank durchgeführt, auch ohne dass ein Administrator Änderungen im AD vorgenommen hat. Daher kann es sein, dass sich der Wert im Attribut highestCommittedUSN nach zwei hintereinander durchgeführten Änderungen um mehrere und nicht nur um eine einzige USN unterscheidet.
Mit REPADMIN kann man sich die höchste USN auf einem DC wie folgt Anzeigen lassen:
Repadmin /showattr <DC> "" /atts:highestCommittedUSN
Von allen DCs aus der Domäne kann man sich die Werte mit diesem Befehl anzeigen lassen:
Repadmin /showattr * "" /atts:highestCommittedUSN
Mit der AD-PowerShell kann man sich den Wert aus dem Attribut highestCommittedUSN von einem DC folgendermaßen anzeigen lassen:
Get-ADRootDSE –Server <DC> | Select highestCommittedUSN | FL
Natürlich kann man sich das Attribut highestCommittedUSN ebenfalls mit LDP anzeigen lassen. Dazu genügt es sich in LDP lediglich mit einem DC zu verbinden. Danach erhält man alle Einträge, unter anderem das Attribut highestCommittedUSN, aus dem rootDSE-Objekt von dem DC, mit dem man sich in LDP verbunden hat.
Dank des Attributs highestCommittedUSN, kann man sich die letzten durchgeführten Änderungen auf einem DC anzeigen lassen. Möchte man sich die letzten 500 Änderungen an der AD-Datenbank auf einem bestimmten DC anzeigen lassen, so kann man dies mit einem LDIFDE-Export herausfinden. Der LDIFDE-Befehl zum Export lautet wie folgt:
Ldifde /d „DC=<Domäne>,DC=<TLD> /s <DC> /x /r „(uSNChanged>=<Wert>)” /f C:\USNÄnderungen.txt
Nicht so schnell! Vorher muss man natürlich die aktuelle (höchste) USN des DCs in Erfahrung bringen. Daher gilt es zuerst eine Abfrage nach dem Attribut highestCommittedUSN durchzuführen. Mit der AD-PowerShell kann man die aktuelle USN wie folgt in Erfahrung bringen:
Get-ADRootDSE | Select highestCommittedUSN | FL
Enthält das Attribut highestCommittedUSN als Wert 5500, muss man lediglich im Ldifde-Filter „(uSNChanged>=5000)” angeben und schon werden die letzten 500 Änderungen, die in der AD-Datenbank dieses DC durchgeführt wurden, exportiert.
Der High-Watermark Vector (HWMV)
Der HWMV (auch bekannt als direct up-to-dateness vector) ist ein Mechanismus, der vom AD bei der Replikation der AD-Informationen verwendet wird, um die Replikation effizient und bandbreitenschonend durchzuführen. Der HWMV dient auch zur Ressourcenschonung, denn es verringert während einer AD-Replikation die CPU-Zeit und die Anzahl an Festplatten I/O eines DCs.
Durch den HWMV können die zwischen den DCs zu replizierenden AD-Informationen bestimmt werden. Dadurch ist es anderen DCs möglich, Änderungen basierend auf einer speziellen USN von einem Replikationspartner anzufordern.
Die Basis für den High-Watermark Vector stellt die USN einer Verzeichnispartition dar. Dabei erhöht sich der HWMV einer Verzeichnispartition auf einem DC, durch beide Aktualisierungstypen.
Der HWMV wird vom Ziel-DC für jede Verzeichnispartition und für jeden seiner direkten Replikationspartner verwaltet. Jeder DC verwaltet für jede Verzeichnispartition die er hält, eine HWMV-Tabelle. In der HWMV-Tabelle ist die höchste replizierte USN (also der HWMV) der entsprechenden Verzeichnispartition, von allen eingehenden direkten Replikationspartnern gespeichert. Mit dem HWMV verfolgt der Ziel-DC in seiner HWMV-Tabelle, welche Änderung, aus welcher Verzeichnispartition, er bereits von einem bestimmten Replikationspartner erhalten hat.
Jeder DC der kein GC ist, verwaltet je eine HWMV-Tabelle für die Schemapartition, Konfigurationspartition, Domänenpartition sowie für die beiden DNS Anwendungsverzeichnispartition (ab Windows Server 2003) „ForestDNSZones“ und „DomainDNSZones“, also insgesamt fünf HWMV-Tabellen. Ein GC in einer Gesamtstruktur mit mehreren Domänen, verwaltet zusätzlich je eine HWMV-Tabelle für jede andere Domänenpartition.
Doch letztlich handelt es sich bei dem HWMV lediglich um den aktuellen Wert im Attribut uSNChanged, den der Ziel-DC von einem bestimmten Replikationspartner erhalten hat! Wird eine Aktualisierung an einem Objekt durchgeführt, erhält automatisch auch das Attribut uSNChanged im geänderten Objekt einen höheren Wert. Der Quell-DC repliziert dann zusätzlich neben der eigentlichen Aktualisierung, das Attribut uSNChanged des zuletzt geänderten Objekts zum Ziel-DC. Der Ziel-DC wiederum, trägt den Wert aus dem mitgesendeten Attribut uSNChanged für seinen Replikationspartner, als den HWMV für die entsprechende Verzeichnispartition in seine HWMV-Tabelle ein. Und obwohl das Attribut uSNChanged mit der Aktualisierung zum Ziel-DC repliziert wurde, erhält das Attribut uSNChanged im selben Objekt auf dem Ziel-DC, nicht denselben Wert den der Quell-DC mitgeschickt hat!
Im HWMV wird neben weiteren Replikationsmetadaten, der Datenbank-GUID (Globally Unique Identifier) und der objectGUID, die beide in der Gesamtstruktur einmalig sind, und nicht der Computername des Remote-DCs gespeichert. Dadurch das sich der objectGUID zu Lebzeiten eines DCs niemals ändert, kommt es auch nicht zu Problemen, wenn sich der Computername eines DCs ändert. Bei dem Datenbank-GUID handelt es sich um das Attribut invocationId und dieser befindet sich so wie der objectGUID in der Konfigurationspartition, in den Eigenschaften des NTDS Settings Objekts eines DCs. Der LDAP-Pfad lautet: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne.
Zwei wichtige IDs eines DCs: DC GUID und InvocationId
Den High-Watermark Vector anzeigen
Führt man den REPAMIN-Befehl Repadmin /showrepl /verbose aus, wird in der Ausgabe die HWMV USN neben dem Eintrag „/OU“ (steht für object update), für jede Verzeichnispartition von jedem Replikationspartner (und nicht der eigene HWMV!) angezeigt. Der Wert der mit der Angabe von „/OU“ angezeigt wird, ist der echte HWMV für die entsprechende Verzeichnispartition des Replikationspartners! Die object update USN ist der tatsächliche HWMV der benötigt wird, um die Attribute bzw. Objekte in der entsprechenden Verzeichnispartition zu bestimmen, die repliziert werden müssen.
Den Fortschritt innerhalb eines Replikationszyklus zeigt die object update USN an (gibt an ob gerade repliziert wird) und der USN-Wert bei „/PU“ (steht für property update), zeigt den letzten erfolgreich durchgeführten(!) Replikationszyklus an. Am Ende eines Replikationszyklus lautet die USN im object update und im property update gleich. Existiert bei /PU kein Wert, bedeutet das, dass die AD-Replikation noch nie erfolgreich durchgeführt wurde, wie es bei der Erstsynchronisation eines neuen DCs der Fall sein kann. Wenn sich die Werte im object update und im property update unterscheiden, bedeutet dies, dass ein Replikationszyklus im Gange ist. Die beiden Werte „/OU“ und „/PU“, die das Repadmin ausliest, stammen vom Attribut repsFrom. Das mehrwertige, optionale (system only) Attribut repsFrom wird nicht zwischen den DCs repliziert (aber in den GC schon) und befindet sich in den Eigenschaften der entsprechenden Verzeichnispartition! In dem Attribut ist von jedem Replikationspartner neben weiteren Replikationsmetadaten der HWMV (nicht der eigene!), gespeichert. Zum Anzeigen der Werte aus repsFrom eignet sich LDP.
Die Replikationsmetadaten eines Objekts anzeigen
Die Replikationsmetadaten eines Objekts kann man sich mit einer Abfrage nach dem mehrwertigen (multivalue) constructed Attribut msDS-ReplAttributeMetaData anzeigen lassen. Dieses Attribut zeigt die Metadaten für jedes replizierte Attribut im XML Format an. Aus den Metadaten erfährt man unter anderem, auf welchem DC ein Attribut geändert wurde. Mit REPADMIN kann man sich die Replikationsmetadaten eines Objekts folgendermaßen anzeigen lassen:
Repadmin /showattr <DC> "<DN des Objekts>" /atts: msDS-ReplAttributeMetaData
In der AD-PowerShell lautet die Abfrage wie folgt:
Get-ADObject -Server <DC> "<DN des Objekts>" -Properties msDS-ReplAttributeMetaData
Im Folgenden einfachen Beispiel wird gezeigt, was es mit dem HWMV auf sich hat
1. In einer Domäne existieren zwei DCs: DC01 und DC02. Der aktuelle HWMV der Domänenpartition von DC01 ist 20500 und von DC02 37250. In der HWMV-Tabelle auf DC01 ist der HWMV der Domänenpartition von DC02 gespeichert. Dieser lautet wie bereits genannt: 37250. In der HWMV-Tabelle für die Domänenpartition auf DC02 ist wiederum gespeichert, dass der HWMV der Domänenpartition von DC01 20500 ist.
2. Wird nun auf dem Quell-DC DC02 ein Benutzer erstellt (es wird eine ursprüngliche Aktualisierung in der Domänenpartition durchgeführt), erhöht sich der lokale HWMV der lokalen Domänenpartition von DC02, auf den neuen Wert 37258. Da aber DC01 von DC02 noch nicht benachrichtigt wurde, dass Änderungen vorliegen und demzufolge die AD-Replikation noch nicht stattgefunden hat, ist weiterhin in der HWMV-Tabelle auf DC01 als HWMV Wert für die Domänenpartition auf DC02 37250 gespeichert. Erst wenn die AD-Replikation stattgefunden hat, aktualisiert DC01 seine HWMV-Tabelle.
3. Innerhalb eines AD-Standorts versendet DC02 ab dem Gesamtstrukturfunktionsmodus Windows Server 2003 nach 15 Sekunden eine Änderungsbenachrichtigung (change notification) an DC01. Standortübergreifend wird die Benachrichtigung, dass Änderungen vorliegen, nach dem in der Standortverknüpfung konfigurierten Zeitplan verschickt. Zur Erinnerung: Bei der AD-Replikation findet per se eine Pull-Replikation und keine(!) Push-Replikation statt! Wenn DC01 die Benachrichtigung erhalten hat, dass Änderungen auf DC02 verfügbar sind, initiiert DC01 die AD-Replikation. DC01 sendet neben weiteren Replikationsmetadaten, die detaillierter im folgenden UTDV-Beispiel aufgelistet werden, den HWMV an DC02, der für DC02 in der HWMV-Tabelle auf DC01 gespeichert ist.
4. Nun, da DC02 den HWMV für die Domänenpartition kennt, den DC01 in seiner HWMV-Tabelle für DC02 gespeichert hat, sendet DC02 die Änderungen zwischen den HWMV-Werten 37250 und 37258. Letzten Endes also das Benutzerobjekt. Zeitgleich aktualisiert der Ziel-DC DC01 seinen lokalen HWMV für die Domänenpartition von 20500 auf 20508, sowie den HWMV von DC02 in seiner HWMV-Tabelle auf 37258.
Wenn es jetzt keinen anderen Mechanismus als den HWMV gäbe, würde die Änderung die gerade zu DC01 repliziert wurde, wieder zurück zu DC02 repliziert werden. Schließlich hat sich auf DC01 durch die replizierte Aktualisierung der lokale HWMV der Domänenpartition erhöht. Das bedeutet im Umkehrschluss, dass Änderungen auf DC01 vorliegen die angeblich repliziert werden müssen. Damit es zu genau dieser Endlosschleife nicht kommt, gibt es einen weiteren Vektor, nämlich den Up-To-Dateness Vector.
Der Up-To-Dateness Vector (UTDV)
So wie beim HWMV, stellt die USN die Basis für den Up-To-Dateness Vector dar. Der Up-To-Dateness Vector ist ein weiterer Mechanismus der ebenfalls dazu dient, die zu replizierenden AD-Informationen zwischen den DCs zu verwalten, damit die AD-Replikation effizient durchgeführt werden kann. Der UTDV verhindert, dass dieselbe Änderung, die der DC erhalten hat, permanent zurück repliziert wird und dadurch eine Endlosschleife entsteht. Deshalb spricht man beim UTDV auch von Propagierungsdämpfung.
Durch den Up-To-Dateness Vector (auf Deutsch Aktualitätsvektor), auch bekannt als Up-To-Date Vector, verfolgt der Ziel-DC die ursprünglichen Aktualisierungen (originating update) in allen Verzeichnispartitionen, die er von beliebigen DCs erhalten hat. Der lokale UTDV eines DCs erhöht sich dabei nur, wenn der DC selbst eine Änderung im AD, also eine ursprüngliche Aktualisierung in der lokalen AD-Datenbank durchführt. Erhält der DC eine replizierte Aktualisierung, erhöht sich lediglich sein lokaler HVMW, aber nicht der lokale UTDV! Den UTDV eines anderen DCs kennt ein DC nur dann, wenn der Quell-DC eine ursprüngliche Aktualisierung in einer Verzeichnispartition die auch auf dem Ziel-DC existiert, durchgeführt hat und die Änderung repliziert wird (was standardmäßig immer der Fall ist).
Genau wie bei den HWMV-Tabellen verwaltet jeder DC zusätzlich je eine UTDV-Tabelle für jede Verzeichnispartition, die ein DC hält. In den entsprechenden UTDV-Tabellen wird jeder beschreibbare DC aufgelistet, der jemals eine ursprüngliche Aktualisierung in einer Verzeichnispartition durchgeführt hat, was in der Praxis auf jeden beschreibbaren DC in fast allen Verzeichnispartitionen zutrifft. In einer UTDV-Tabelle speichert jeder DC die Datenbank-GUIDs (das Attribut invocationId) der Replikationspartner. Des Weiteren werden die Einträge in den entsprechenden UTDV-Tabellen für die Lebensdauer einer Verzeichnispartition verwaltet, unabhängig davon, ob der DC oder die Verzeichnispartition vom DC bereits entfernt wurde.
Jeder DC, der kein GC ist, verwaltet je eine UTDV-Tabelle für die Schemapartition, Konfigurationspartition, Domänenpartition sowie für die beiden DNS Anwendungsverzeichnispartition (ab Windows Server 2003) „ForestDNSZones“ und „DomainDNSZones“, also insgesamt fünf UTDV-Tabellen. Ein GC in einer Gesamtstruktur mit mehreren Domänen verwaltet zusätzlich je eine UTDV-Tabelle für jede andere Domänenpartition.
Für die gesamtstrukturweiten Verzeichnispartitionen Schemapartition, Konfigurationspartition sowie die Anwendungsverzeichnispartition ForestDNSZones verfolgt ein DC in der jeweiligen UTDV-Tabelle den UTDV für alle DCs in der Gesamtstruktur. Im Grunde verfolgen bei der Schemapartition alle DCs einer Gesamtstruktur lediglich den UTDV eines DCs, nämlich den vom Schemamaster. Der Schemamaster ist der Einzige DC, der in der Schemapartition Änderungen durchführen darf. Was die Konfigurationspartition und die DNS Anwendungsverzeichnispartition „ForestDNSZones“ anbetrifft, verfolgt jeder DC den UTDV, jedes DCs in der Gesamtstruktur. Denn jeder DC erstellt Objekte in der Konfigurationspartition (z.B. Verbindungsobjekte) und jeder DC erstellt SRV-Einträge in der Anwendungsverzeichnispartition „ForestDNSZones“, genauer in der Forward Lookup Zone _msdcs.Root-Domäne.de. Für die Domänenpartition und für die DNS Anwendungsverzeichnispartition „DomainDNSZones“, verwaltet jeder DC den UTDV in der entsprechenden UTDV-Tabelle, für jeden anderen DC in der Domäne. Ein GC in einer Gesamtstruktur mit mehreren Domänen, verfolgt zusätzlich die Up-To-Dateness Vektoren für jeden DC aus den anderen Domänenpartitionen.
Genau genommen spiegelt das Attribut highestCommittedUSN aus dem rootDSE-Objekts eines DCs den lokalen UTDV eines DCs wieder. In dem Attribut highestCommittedUSN speichert der DC die letzte bestätigte und somit die höchste USN eines DCs, die einer lokalen AD-Änderung zugewiesen wurde.
Den Up-To-Dateness Vector anzeigen
Die Up-To-Dateness Vektoren, die ein bestimmter DC für eine Verzeichnispartition von seinen direkten und transitiven Replikationspartnern in seiner UTDV-Tabelle gespeichert hat, kann man sich mit dem Kommandozeilenbefehl Repadmin /showutdvec <DC> <DN der Verzeichnispartition> anzeigen lassen. Der Befehl listet auf dem angegebenen DC die eigene höchste USN und die höchste USN seiner direkten sowie transitiven Replikationspartner für die angegebene Verzeichnispartition auf, die zum Zeitpunkt der Abfrage in seiner lokalen UTDV-Tabelle gespeichert sind.
Repadmin /showutdvec
Führt man den Kommandozeilenbefehl Repadmin /showutdvec <DC> <DN der Root-Domäne> auf einem DC in der Root-Domäne aus, werden die UTDV für die Domänenpartition nur von allen DCs der Root-Domäne angezeigt und nicht der GC aus der Subdomäne! Denn wie bereits geschrieben, verfolgt der UTDV nur die ursprüngliche Aktualisierung, die innerhalb einer Verzeichnispartition durchgeführt wurde, und deshalb erscheint bei der Abfrage auf dem DC in der Root-Domäne der GC aus der Subdomäne nicht auf. Ein GC hat nur das Schreibrecht in der Domäne und somit nur in der Domänenpartition, in der er selbst Mitglied ist. Es werden zwar in einem Multi-Domain Forest alle Domänenpartitionen in den GC repliziert, jedoch besitzt der GC in allen anderen Domänenpartitionen nur das Leserecht! Erst wenn man denselben(!) Repadmin-Befehl auf einem DC in der Subdomäne ausführt, wird neben den DCs der Root-Domäne auch der GC der Subdomäne angezeigt.
Das Attribut, in dem die Up-To-Dateness Vektoren der Replikationspartner gespeichert sind
Jeder UTDV ist in dem system only Attribut replUpToDateVector gespeichert, das nicht zwischen den DCs repliziert wird (aber in den GC schon) und sich in den Eigenschaften einer Verzeichnispartition befindet. In diesem Attribut werden die UTDV von allen Replikationspartnern gespeichert, die jemals eine ursprüngliche Aktualisierung in der entsprechenden Verzeichnispartition durchgeführt und repliziert haben. In dem Attribut ist aber nicht der eigene UTDV gespeichert!
Am einfachsten lassen sich die Werte des Attributs, mit LDP anzeigen. Nach dem man sich in LDP zuerst mit einem DC verbunden und anschließend mit dem AD "Gebunden" hat, kann man sich unter Durchsuchen - Suchen die Werte aus dem Attribut replUpToDateVector für die angegebene Verzeichnispartition anzeigen lassen.
Möchte man in Erfahrung bringen, welche DCs hinter den Datenbank-GUIDs stecken die einem das LDP anzeigt, so kann man das leicht herausfinden. Dazu sollte man zuerst den Repadmin-Befehl Repadmin /showutdvec <DC> <DN der Verzeichnispartition> ausführen. Bei diesem Befehl werden die Computernamen der DCs angezeigt. Wenn anschließend der gleiche Befehl, mit dem Parameter /nocache ausgeführt wird, werden die Datenbank-GUIDs angezeigt. Anhand der UTDV Werte kann man dann sehen, hinter welchem Computernamen welche Datenbank-GUID steckt.
Anhand eines einfachen Beispiels, wird die Funktionsweise des UTDV gezeigt
1. In einer Domäne existieren drei DCs: DC01, DC02 und DC03. Der aktuelle HWMV der Domänenpartition von DC01 ist 20508, von DC02 37258 und von DC03 39270. Der aktuelle UTDV von DC01 ist 20508, von DC02 37258 und von DC03 39270. In den HWMV- und den UTDV-Tabellen auf allen DCs, sind jeweils die aktuellen Werte der anderen beiden DCs gespeichert.
2. Angenommen ein Administrator ändert auf dem Quell-DC DC01 im Benutzerobjekt Yusuf die Beschreibung. Es findet also eine einzelne ursprüngliche Aktualisierung auf DC01 statt und dieser weist dem Attribut description die lokale und ursprüngliche USN 20509 zu.
Der Wert 20509 wird als lokaler HWMV und UTDV für die Domänenpartition und im Attribut highestCommittedUSN auf DC01 gespeichert. Denn das ist zu diesem Zeitpunkt, die letzte bestätigte und höchste USN auf DC01.
3. DC01 versendet nach 15 Sekunden eine Änderungsbenachrichtigung zu DC02 und nach weiteren drei Sekunden zu DC03 und informiert beide DCs, dass Änderungen in der Domänenpartition vorliegen, die repliziert werden müssen.
4. Im Gegenzug senden die Ziel-DCs DC02 sowie DC03, die folgenden Informationen zum Quell-DC DC01:
-
Die Verzeichnispartition, in diesem Fall die Domänenpartition, in der die Änderung durchgeführt wurde.
-
Die maximale Anzahl der angeforderten Objekte.
-
Die maximale Anzahl der angeforderten Werte.
-
Den HWMV für die Domänenpartition vom Quell-DC DC01, den die Ziel-DCs DC02 und DC03 in ihren HWMV-Tabellen für DC01 gespeichert haben. Anhand des mitgesendeten HWMV erkennt der Quell-DC DC01, welche Änderungen die Ziel-DCs bereits besitzen und repliziert nur die aktuellsten Änderungen. Das bedeutet, es werden lediglich die Änderungen mit einer größeren USN, als der mitgesendete HWMV angefordert (in dem Beispiel, alle Änderungen ab der HWMV USN 20508), sofern der UTDV den Vorgang nicht verwirft.
-
Die Ziel-DCs senden ihre gesamte UTDV-Tabelle der entsprechenden Verzeichnispartition zum Quell-DC. Die UTDV-Tabelle enthält einen Eintrag für jeden DC, der ein vollständiges Replikat der Verzeichnispartition hält. Für die Domänenpartition sind es alle DCs der Domäne, für die Konfigurationspartition sind es alle DCs der Gesamtstruktur usw.
5. Der Quell-DC DC01 wiederum, antwortet dann unter anderem mit diesen Informationen:
-
Die DC-GUID (das Attribut objectGUID) von DC01.
-
Die Datenbank-GUID (das Attribut invocationId) von DC01.
-
Eine Reihe von Einträgen, die die Objektaktualisierung betreffen.
-
Der höchste uSNChanged Wert. Diesen Wert trägt der Ziel-DC in seine HWMV-Tabelle, als den aktuellen HWMV Wert für den Quell-DC ein.
-
Den UTDV von DC01
6. Findet nun die eigentliche Pull-Replikation vom Quell DC DC01 zu den Ziel-DCs DC02 und DC03 statt, wird neben dem aktualisierten Attribut description auch die ursprüngliche USN 20509 zu den Ziel-DCs repliziert.
7. Wenn die Ziel-DCs diese Änderung erhalten, aktualisieren sie in ihrer HWMV- und UTDV-Tabelle der Domänenpartition, die Werte für den Quell-DC DC01 auf den neuen Wert 20509. Zusätzlich aktualisieren die Ziel-DCs ihren eigenen HWMV, jedoch nicht ihren eigenen UTDV. Die Änderung wurde schließlich auf dem Quell-DC DC01 durchgeführt. Zur Erinnerung: Der UTDV wird nur bei einer ursprünglichen und nicht bei einer replizierten Aktualisierung erhöht.
8. Nach der Replikation liegen auf den Ziel-DCs Änderungen vor, die angeblich repliziert werden müssen. Auf beiden Ziel-DCs hat sich der lokale HWMV erhöht. Der neue HWMV der Domänenpartition von DC02 ist 37259 und von DC03 39271.
Wenn nun DC02 eine Änderungsbenachrichtigung an DC03 sendet und ihn darüber informiert, dass Änderungen vorliegen, sendet im Gegenzug DC03 den HWMV zu DC02, den er für DC02 in seiner HWMV-Tabelle gespeichert hat, also 37258 und seine komplette UTDV-Tabelle. In der UTDV-Tabelle die DC03 zu DC02 sendet, stehen die Werte „DC01-UTDV Domain NC 20509“ und „DC02-UTDV Domain NC 37258“.
9. Anhand des HWMV 37258 den DC03 zu DC02 gesendet hat, geht DC02 davon aus, dass DC03 die aktuelle Änderung noch nicht erhalten hat.
Und an dieser Stelle, kommt der UTDV zum Einsatz! DC02 erkennt nämlich anhand der UTDV-Tabelle (genauer an dem Eintrag DC01-UTDV Domain NC 20509), die DC03 vor der Replikation zu DC02 gesendet hat, das DC03 bereits die Änderung von DC01 erhalten hat. Die Änderung wird also nicht erneut repliziert! Danach aktualisiert DC03 nur den HWMV und UTDV von DC02 in seinen Tabellen, auf den aktuellen Wert 37259.
10. Das gleiche Verfahren wird in umgekehrter Konstellation angewendet, also wenn DC03 die beiden anderen DCs DC01 und DC02 informiert das Änderungen vorliegen oder wenn DC01 von DC02 benachrichtigt wird. Das Einzige was passiert ist, das jeder DC in seiner HWMV- und UTDV-Tabelle, die aktuellen Werte der beiden anderen Replikationspartner einträgt.
Der Änderungsstempel
Wenn ein Objekt erstellt wird, erhält jedes einzelne Attribut für das ein Wert vergeben wurde, einen Änderungsstempel. Der Änderungsstempel besteht aus dem Ursprungsserver, dem Zeitstempel und der Versionsnummer. Wird ein Attribut geändert, werden diese drei Komponenten aktualisiert.
Die drei Komponenten bedeuten:
Ursprungsserver: Bei dem Ursprungsserver handelt es sich um den DC, auf dem die ursprüngliche Aktualisierung eines Attributs durchgeführt wurde. Dieser Wert wird mit dem aktualisierten Attribut auf die Replikationspartner repliziert.
Zeitstempel: Bei der Änderung eines Attributs, wird der Zeitpunkt der Durchführung, in Form von Datum und Uhrzeit, mit dem Attribut gespeichert. Dieser Zeitwert wird ebenfalls mit dem aktualisierten Attribut repliziert.
Versionsnummer: An der Versionsnummer lässt sich erkennen, wie oft ein Attribut geändert wurde. Bei der Erstellung eines Objekts, wird jedem Attribut das einen Wert enthält, die Versionsnummer 1 zugewiesen. Alle Attribute die keinen Wert besitzen, erhalten die Versionsnummer 0. Jedes Mal wenn sich der Wert eines Attributs ändert, erhöht sich die Versionsnummer um einen Zähler. Auch dieser Wert wird so wie die anderen beiden Komponenten auf die Replikationspartner repliziert.
Mit Repadmin lassen sich die Komponenten mit diesem Befehl Anzeigen:
Repadmin /showobjmeta <DC> <DN des Objekts>
In der Repadmin-Ausgabe befindet sich der Ursprungsserver in der Spalte Ursprüngl. DSA. Hinter dieser Komponente steckt das Attribut objectGUID eines DCs. Wie zu erkennen, befindet sich der Zeitstempel in der Spalte Ur.Zeit/Datum und die Versionsnummer in der Spalte Ver.
Mittels des Änderungsstempels wird bei einem Replikationskonflikt darüber entschieden, welche Änderung übernommen wird. Wie das AD einen Replikationskonflikt auflöst und welche Konflikte wann entstehen können, beschreibt der folgende Artikel:
Active Directory-Replikationskonflikt
Weitere Informationen:
Die Linked Value Replikation (LVR)
Die unterschiedliche Größe der AD-Datenbank
Die konstruierten Attribute abfragen
Domänencontroller vergleichen
Die Active Directory-Attribute hinter den Feldnamen
Troubleshooting replication with repadmin
How the Active Directory Replication Model Works: Active Directory
Ein weit verbreitetes Missverständnis ist, das ein Ereignis, welches die dringende AD-Replikation auslöst, sofort an alle Domänencontroller (DC) repliziert wird. Genau genommen handelt es sich bei einer dringenden AD-Replikation (urgent replication) noch nicht einmal um eine echte sofortige Replikation. In Wirklichkeit wird lediglich die Benachrichtigung, dass Änderungen auf dem Quell-DC vorliegen, an erster Stelle der Replikationswarteschlange hinzugefügt.
Genau wie bei der standortinternen (Intra-Site) Replikation, basiert die dringende AD-Replikation auf Änderungsbenachrichtigungen (change notification). Außer das beim Eintreten eines wichtigen Ereignisses die Benachrichtigung unverzüglich versendet wird, statt 15 Sekunden (bzw. 300 Sekunden unter Windows 2000) abzuwarten. Diese Änderungsbenachrichtigung wird sofort an alle Replikationspartner versendet, noch bevor die in der Replikationswarteschlange anstehenden Änderungsbenachrichtigungen verschickt werden. Jeder DC, der eine dringende Aktualisierung erhält, leitet diese ebenfalls umgehend an seine Replikationspartner weiter. Durch diese Vorgehensweise ist sichergestellt, dass alle DCs am gleichen AD-Standort innerhalb von Sekunden aktualisiert werden.
Durch die dringende AD-Replikation erhalten die Replikationspartner in gewohnter Weise sofort eine Änderungsbenachrichtigung über das RPC over IP Protokoll. Aufgrund des hohen Replikationsaufkommens werden bei der dringenden AD-Replikation standardmäßig die AD-Standortgrenzen nicht überschritten. Das lässt sich jedoch konfigurieren.
Ereignisse, die eine dringende AD-Replikation auslösen
Die dringende AD-Replikation wird bei Eintreten bestimmter Ereignisse standardmäßig nur innerhalb eines AD-Standorts durchgeführt. Dabei ist es unabhängig, unter welchem Betriebssystem die DCs betrieben werden. Ist allerdings die standortübergreifende Änderungsbenachrichtigung in der Standortverknüpfung (Site-Link) aktiviert, werden diese Ereignisse auch unverzüglich zwischen den AD-Standorten repliziert.
Siehe dazu:
Die Inter-Site (standortübergreifende) Änderungsbenachrichtigung aktivieren
Zwischen den DCs, die sich innerhalb des gleichen AD-Standorts befinden, wird die dringende AD-Replikation durch folgende Änderungstypen ausgelöst:
- Benutzerkontosperrung (nachdem ein Benutzer sein Kennwort zu oft falsch eingegeben hat). Die Sperrung eines Benutzerkontos wird über die dringende AD-Replikation in erster Linie zu dem DC, der die FSMO-Rolle des PDC-Emulators innehat, repliziert. Das Entsperren eines Benutzerkontos hingegen löst keine dingende AD-Replikation aus!
- Bearbeitung der Kontosperrungsrichtlinie. Die Bearbeitung der gleichen Optionen in einem PSO (Password Setting Object) löst hingegen keine dringende AD-Replikation aus! Die Änderung eines PSO wird über die normale standortinterne (Intra-Site) und standortübergreifende (Inter-Site) AD-Replikation durchgeführt.
- Bearbeitung der domänenweiten Kennwortrichtlinie. Aber das Bearbeiten der Kennwortvorgaben in einem PSO löst ebenfalls keine dringende AD-Replikation aus! Die Änderung der Kennwortvorgaben innerhalb einer PSO wird ebenfalls über die normale standortinterne und standortübergreifende AD-Replikation durchgeführt.
- Verschiebung der RID-Master FSMO-Rolle auf einen anderen DC.
- Änderung eines LSA-Schlüssels (Local Security Authority, lokale Sicherheitsautorität). Wenn zum Beispiel das Kennwort des Computerkontos eines DCs oder für eine Vertrauensstellung geändert wird.
Die dringende AD-Replikation durch eine Benutzerkontosperrung
Gibt ein Benutzer sein Kennwort häufiger falsch ein, als es in der Kontosperrungsrichtlinie oder im PSO definiert ist, wird sein Benutzerkonto gesperrt. Die Benutzerkontosperrung wird dann über die dringende AD-Replikation zum PDC-Emulator repliziert. Unabhängig davon, an welchem AD-Standort dieser sich befindet.
Anschließend wird ebenfalls über die dringende AD-Replikation die Benutzerkontosperrung zu den folgenden DCs repliziert:
- Zu allen DCs der gleichen Domäne, die sich am gleichen AD-Standort befinden wie der DC der die FSMO-Rolle des PDC-Emulators innehat.
- Zu allen DCs der gleichen Domäne, die sich am gleichen AD-Standort befinden wie der DC der die Benutzerkontosperrung durchgeführt hat.
- Zu allen DCs der gleichen Domäne, die sich an einem AD-Standort befinden zu der die standortübergreifende Änderungsbenachrichtigung (und demnach die dringende AD-Replikation) mit dem AD-Standort aktiviert wurde, in dem sich der PDC-Emulator oder der DC befindet, der die Benutzerkontosperrung durchgeführt hat.
Wenn die Benutzerauthentisierung an einem DC, nicht jedoch am PDC-Emulator fehlschlägt, wird die Authentisierung auf dem PDC-Emulator wiederholt. Aus diesem Grund ist letzten Endes auch der PDC-Emulator derjenige, der das Benutzerkonto nach den Vorgaben der Kontosperrungsrichtlinie zuerst sperrt. Und nicht der DC, der die fehlgeschlagene Benutzerauthentisierung als erster entgegennahm.
Die Replikation einer Kennwortänderung
Oftmals wird auch fälschlicherweise angenommen, dass die Kennwortänderung eines Benutzers über die dringende AD-Replikation zu allen anderen DCs repliziert wird. Kennwortänderungen werden anders als die normale AD-Replikation und anders als die dringende AD-Replikation durchgeführt.
Bei der Kennwortänderung eines Domänen-Benutzers oder eines Computerkontos repliziert der DC, der die Kennwortänderung durchgeführt hat, umgehend das neue Kennwort durch den sicheren Kanal zum PDC-Emulator. Das neue Kennwort wird sogar dann zum PDC-Emulator repliziert, wenn dieser an einem anderen AD-Standort steht. Dabei greift der DC auch nicht auf die Bridgeheadserver an den AD-Standort zurück. Der DC, auf dem das Kennwort geändert wurde, nutzt stattdessen eine RPC over IP-Verbindung direkt zum PDC-Emulator, um das Kennwort zu aktualisieren.
Authentisiert sich der Benutzer danach an einem DC (z.B. aus einem anderen AD-Standort) der das neue Kennwort noch nicht kennt, fragt der DC beim PDC-Emulator nach, ob ihm ein neueres Kennwort vorliegt, bevor er dem Benutzer die Anmeldung verweigert. Falls ja, wird der Benutzer vom PDC-Emulator authentisiert und der Benutzer kann sich anmelden. Falls nicht, schlägt die Anmeldung fehl. Der PDC-Emulator hat also bei der Kennwortfrage immer das letzte Wort. Wenn die Kennwortnachfrage beim PDC-Emulator erfolgreich verlief, repliziert der PDC-Emulator das neue Kennwort unverzüglich zu dem DC, von dem die Anfrage kam. Dadurch ist sichergestellt, dass der DC nicht erneut wegen des geänderten Kennworts beim PDC-Emulator nachfrägt.
Die Kennwortaktualisierung wird sofort zum PDC-Emulator repliziert, ohne Rücksicht auf einen eventuell konfigurierten Zeitplan in der Standortverknüpfung. Anschließend wird sie innerhalb des AD-Standorts des PDC-Emulators und innerhalb des AD-Standorts des DC, der die Kennwortänderung durchgeführt hat, durch die standortinterne AD-Replikation zu den anderen DCs repliziert. Alle anderen DCs, die sich an entfernten AD-Standorten befinden, erhalten die Kennwortänderung ganz normal durch die standortübergreifende AD-Replikation.
Ist allerdings der PDC-Emulator nicht erreichbar (beispielsweise wegen Überlastung) oder schlägt die RPC over IP-Verbindung fehl, wird die Kennwortänderung über das normale Replikationsverfahren (standortintern und standortübergreifend) an alle DCs inklusive dem PDC-Emulator repliziert.
Wenn es nicht gewünscht wird, dass die Kennwortaktualisierung eines Benutzers oder eines Computers sofort zum PDC-Emulator an einem anderen AD-Standort repliziert wird, kann man dieses Verhalten unterbinden. Dazu muss folgender neuer Eintrag in die Registry erstellt werden:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters
REG_DWORD
AvoidPdcOnWan
1 = Aktiviert (True)
Dieser Registryeintrag muss auf jedem DC erstellt werden, der eine Kennwortaktualisierung nicht sofort zu einem (an einem entfernten AD-Standort stehenden) PDC-Emulator replizieren soll. Der PDC-Emulator erhält die Kennwortaktualisierung dann ganz normal über den konfigurierten Zeitplan für die standortübergreifende AD-Replikation. Befindet sich aber der PDC-Emulator am gleichen AD-Standort wie der DC, der die Kennwortaktualisierung durchgeführt hat, wird der Registryeintrag ignoriert und das neue Kennwort wird unverzüglich zum PDC-Emulator repliziert.
Komfortabler lässt sich diese Einstellung über die folgende GPO konfigurieren:
Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Netzwerkanmeldung\Verbindung mit PDC bei Anmeldungsfehler herstellen
Wird diese Richtlinie auf Deaktiviert konfiguriert, repliziert der DC, auf dem die Kennwortänderung stattgefunden hat, das neue Kennwort ebenfalls nicht sofort zum PDC-Emulator an einem anderen AD-Standort. Stattdessen wird das neue Kennwort dann über den konfigurierten Zeitplan für die standortübergreifende AD-Replikation repliziert. Wenn sich jedoch der PDC-Emulator am gleichen AD-Standort befindet wie der die Kennwortänderung durchführende DC, wird das neue Kennwort sofort zum PDC-Emulator repliziert.
Auf der anderen Seite hat man sowohl mit dem Registryeintrag als auch mit der GPO Einfluss darauf, wie sich ein DC Verhalten soll, wenn sich ein Benutzer oder Computer mit einem für den DC fremden Kennwort authentisieren möchte. Setzt man den Registryeintrag oder konfiguriert man die GPO, leitet der DC die Kennwortabfrage nicht an den PDC-Emulator weiter, wenn dieser sich an einem anderen AD-Standort befindet.
| |