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:

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:

1. 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.
   
   
2. 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>
   
   
3. Als nächstes gilt es mit einem Rechtsklick auf CN=Operations,CN=ForestUpdates,CN=Configuration,DC=<Root-Domain> die Option New -> Object... auszuwählen.
   
   
4. Als class muss der Eintrag container ausgewählt werden.
   
   
5. Im nächsten Schritt muss als Value dieser Wert eingegeben warden: 94fdebc6-8eeb-4640-80de-ec52b9ca17fa.
   
   
6. Danach sollte man auf auf More Attributes klicken und unter Select a property to view die Option showInAdvancedViewOnly auswählen.
   
   
7. Zusätzlich sollte im Bereich Attribute Values im Feld Edit Attribute als Wert TRUE eingetragen und mit SET bestätigt werden.
   
   
8. 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

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

######################################################
#
# 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()

Die Remote Server Administration Tools, kurz RSAT, für Windows 7 Service Pack 1 sind Released-To-Web (RTW)

Wenn man unter Windows 7 Service Pack 1 versucht das bisherige RSAT zu installieren, erhält man diese Fehlermeldung:

Error message when installing RSAT: 'This update is not applicable to your computer'

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.

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

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.

• 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

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

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

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

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

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"

      }

}

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.

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:

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

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

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

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

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

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

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

In der AD-PowerShell

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

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

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

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

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

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

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

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

• Performance: Werden auf einem DC weitere Applikationen und Dienste installiert, kostet das Ressourcen. Damit steigt das Risiko, dass wenn sich viele Benutzer zur gleichen Zeit an der Domäne authentisieren, dem DC nicht genügend Ressourcen zur Verfügung stehen um jede Authentisierung eines Benutzers erfolgreich durchzuführen. Wenn intensiv mit AD-Abfragen gearbeitet wird, können die fehlenden Ressourcen den DC unnötig auslasten und von Nachteil sein.
  
  
• Sicherheit: Werden auf einem DC Applikationen oder Dienste installiert, muss man bei entsprechender Rollentrennung dem Betreuer dieser Applikation bzw. der Dienste Rechte auf dem DC einräumen. Oftmals wird dann der Benutzer in die Gruppe der BuiltIn\Administratoren oder in die Gruppe der Domänen-Admins hinzugefügt, was beides selbstverständlich keineswegs gewünscht ist. Denn zum einen sind das zu viele Rechte die man dem Benutzer einräumt und zum anderen, birgt das Gefahren. Der Benutzer, wenn der DC auch noch der Einzige in der Domäne ist, könnte die Domäne gefährden.
  
  Mit Einführung von Windows Server 2008 und dem RODC hat man die Situation entschärft, was die Sicherheit der AD DS anbetrifft. Der Administrator für die Anwendung kann auf einem RODC lokale Adminrechte erhalten und hat dennoch keine weiteren Rechte auf die AD DS.
  
  Es sollten alle Server hinter Schloss und Riegel stehen und nur Befugten sollte der Zugang erlaubt sein. Doch aus AD-Sicht ist es nicht weiter tragisch wenn „nur“ der Applikationsserver anstatt eines DCs unter dem Schreibtisch steht.
  
  
• Rollentrennung: Folgt man der Empfehlung und betreibt dedizierte DCs, kann man in einem Problemfall einen DC in einer Umgebung mit mehreren DCs einfach ersetzen. Ist jedoch auf dem DC eine wichtige Applikation installiert, gestaltet sich der Austausch besonders schwierig!
  
  
• Stabilität: Das Installieren von Applikationen und Diensten gefährdet die Stabilität eines DCs (RWDC und RODC). Denn bereits das Installieren eines zusätzlichen nicht kompatiblen (Drucker?) Treibers kann zu Instabilitäten führen, so dass es regelmäßig zum BSOD (Blue Screen of Death) kommt. Dies kann natürlich auch zum Totalausfall des Active Directories führen, bspw. durch Inkonsistenzen die durch solche Abstürze entstehen. Wenn sich in der Domäne mehrere DCs befinden, kann man einen dedizierten DC im laufenden Betrieb herunterstufen, den Computernamen ändern und anschließend wieder zum DC heraufstufen. Ob das die installierte Applikation auf dem DC verkraftet ist fraglich. Ein installierter Exchange Server verhindert dies sehr wirkungsvoll.
  
  

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

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

• Was die Performance des DCs anbetrifft, sollte eine Applikation bzw. Dienst vor dem Einsatz auf einem DC in einer produktiven Umgebung, ausgiebig in einer Testumgebung möglichst realitätsgetreu getestet werden. Das wichtigste dabei ist das Monitoring. Erst wenn die Tests nach mehreren Tagen zufriedenstellende Ergebnisse geliefert haben, sollte man die Applikation oder den Dienst auf dem DC in der produktiven Umgebung installieren. Bei den Tests die als Referenz dienen, sollte man über mehrere Tage die Auslastung des DCs (CPU, RAM, HDD, NIC) zu verschiedenen Zeitpunkten verteilt über den Tag aufzeichnen. Wurde die Applikation bzw. der Dienst auf dem produktiven DC installiert, sollte man die Auslastung des DCs ständig mit der Referenz vergleichen.

  Natürlich ist das ein Kraftakt den sich ein Unternehmen mit 5 Angestellten zwei Mal überlegt, ob er diese Tests durchführen soll bzw. kann. Ich kann es aber jedem nur ans Herz legen!
  
  
• Derjenige der die Applikation bzw. den Dienst auf einem DC mit Domänen-Adminrechten betreut, muss vertrauenswürdig sein. Schließlich kann der Betreuer mit Domänen-Adminrechten der Domäne schaden bis hin zu zerstören! Die Virtualisierung ist eine Möglichkeit, die einem bei der Rollentrennung behilflich sein kann.
  
  
• Es sollten ausschließlich vertrauenswürdige Applikationen und Dienste die vorher ausgiebig getestet wurden auf einem DC installiert werden. Dabei sollte die Datensicherung mit höchster Priorität sichergestellt sein. Sowohl die tatsächliche Durchführung einer funktionierenden System State Sicherung auf der einen Seite, als auch die Sicherung der Daten auf der anderen Seite sollte stets überprüft werden.

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

Warum Exchange nicht auf einem DC installiert werden sollte

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

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

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

  Der Exchange Administrator ist standardmäßig Mitglied in der Gruppe BuiltIn\Administratoren und ist dadurch Administrator auf den DCs! Das ist natürlich zwecks Rollentrennung und vor allem in größeren Umgebungen mit verteilter Administration nicht erwünscht.

  Alle Exchange Dienste werden als LocalSystem ausgeführt, was ein größeres Sicherheitsrisiko darstellt wenn eine Sicherheitslücke entsteht. Existiert z.B. ein Sicherheitsloch im AD das einem Angreifer den Zugriff auf das AD erlaubt, kann dieser auch auf Exchange (und umgekehrt) zugreifen.
  
  
• Ressourcen: Werden die zur Verfügung stehenden Ressourcen auf dem Exchange Server knapp (CPU, RAM, HDD, NIC), leidet darunter auch der DC. Denn läuft z.B. Exchange aus welchen Gründen auch immer voll, hat nicht nur Exchange ein Problem sondern auch der DC! Oder wenn sich ein Exchange-Dienst aufhängt und somit den ganzen Server auslastet, zieht das auch den DC in Mitleidenschaft so das dieser unter Umständen keine Anfragen mehr beantworten kann.
  
  
• Neustart: Es kann bis zu zehn Minuten dauern den DC herunterzufahren bzw. neu zu starten. Denn standardmäßig wird der Dienst LSASS.exe in dem das AD ausgeführt wird eher beendet, bevor die Exchange Dienste die vom AD abhängig sind beendet werden. Dadurch kommt es zu mehreren Timeouts und deshalb zu dem langsamen Verhalten. Eine mögliche Abhilfe für dieses Problem ist die Exchange-Dienste (insbesondere den Informationstore) manuell zu stoppen, bevor der DC heruntergefahren oder neu gestartet wird.
  
  

• DCPROMO: Des Weiteren ist das Ausführen von DCPROMO auf einem Exchange Server nicht supportet! Das bedeutet, wurde Exchange auf einem DC installiert, darf der DC nicht heruntergestuft werden. Zuerst müsste Exchange deinstalliert werden, ehe der DC anschließend heruntergestuft werden kann. Oder wenn Exchange auf einem Mitgliedsserver installiert wurde, darf dieser nicht mit DCPROMO zum DC heraufgestuft werden.

  Siehe (unter dem Abschnitt "Directory Server Architecture\Installing Exchange 2010 on Directory Servers"):

  Exchange 2010 System Requirements: Exchange 2010 Help
  
  

• Exchangeabhängigkeit vom GC: Selbst wenn man mehr als einen DC/GC in der Domäne besitzt, wird Exchange immer den DC/GC nutzen, auf dem es installiert ist. Das bedeutet im Umkehrschluss, dass Exchange den Betrieb einstellt, sollte mit der DC Funktion auf dem Server etwas im Argen liegen.

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

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

Virtualization Support Wizard
Exchange Server Supportability Matrix

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

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

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

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

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

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

und

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

Die fein abgestimmten Kennwortrichtlinien

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

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

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

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

Die Voraussetzungen

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

Die Attribute eines PSO

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

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

Verknüpfte Attribute
Die konstruierten Attribute abfragen

Die PSO-Attribute mit einer Zeitangabe

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

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

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

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

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

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

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

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

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

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

• Es gibt jedoch drei Einstellungen die direkt im Benutzerobjekt vorgenommen werden können, um stets die Kennwortvorgaben eines PSOs auszuhebeln. Die drei Optionen lassen sich mit den Flags des userAccountControl Attributs konfigurieren und sind:

  - Kennwort läuft nie ab
  - Kennwort mit umkehrbarer Verschlüsselung speichern
  - Kennwort nicht erforderlich
  
  How to use the UserAccountControl flags to manipulate user account properties
  
  Im Übrigen setzen diese drei Flags die Kennwortvorgaben die in der DDP konfiguriert sind, ebenso außer Kraft!

PSOs mit der AD-PowerShell erstellen und verwalten

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

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

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

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

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