DCs und FSMO-Rollen werden über ntdsutil verwaltet. Der ausführende Benutzer muss die Rollen Schema-Admin und Organisation-Admin inne haben, um die entsprechenden Änderungen vornehmen zu können:
CMD „als Administrator ausführen

1. Rollen verschieben Bevcor eine DC aus dem AD entfernt wird, sollten seine Rollen auf einen verbleibenden DC verschoben werden. Die aktuellen Rolleninhaber lassen sich mit dem folgenden Befehl abfragen:

netdom query fsmo

Ist der ursprüngliche Rolleninahber noch verfügbar verfügbar, können die Rollen über die folgenden Befehle übertragen werden:

ntdsutil
roles
connections
connect to server NEUER-ROLLENINHABER
fsmo maintenance
q
transfer rid master
transfer pdc
transfer infrustructure master
transfer shema master
transfer domain master

Ist der ursprüngtliche Rolleninhaber nciht mehr verfügbar, muss das „transfer“ durch ein „seize“ ersetzt werden, um die Übertragung zu erzwingen.

Alte Einträge aus dem AD entfernen Ist der alte DC nicht mehr ansprechbar müssen seine früheren Funktionen aus dem AD entfernet werden. Auch dieser Schritt wird sinnvoll mit NTDSUTIL durchgeführt:

ntdsutil: metadata cleanup
metadata cleanup: connections
server connections: connect to server FUNKTIONIERENDER-SERVER
server connections: q
metadata cleanup: select operation target
select operation target: list domains
select operation target: select domain ‹x›
select operation target: list sites
select operation target: select site ‹y›
select operation target: list servers in site
select operation target: select server ‹z›
q
remove selected server

Alten Server aus AD entfernen:

1. Alten Server unter „Active Directory-Standorte und Dienste“ löschen
2. Alten Server aus „Active Directory Benutzer und Computer“ löschen
3. Alten Server aus „DNS“ löschen

Zeitraum für die Abfrage in einer Variablen speichern (Hier 365 Tage):
Die Variable gilt nur in der aktuellen Session. Wird die Powershell geschlossen, muss die Variable vor dem Ausführen der folgenden Zeilen neu gesetzt werden.

$v_time = (Get-Date).AddDays(-365)

Erzeugen und Speichern einer Liste der zum Suchmuster passenden AD-Konten (Hier unter d:\result.csv):

Get-ADComputer -Property Name,lastLogonDate -Filter {lastLogonDate -lt $v_time} | Select-Object Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion,LastLogonDate | Select-Object Name,LastLogonDate | Export-CSV d:\result.csv -NoTypeInformation 

Wenn in der Liste nur AD-Konten enthalten sind, die gelöscht werden sollen, die Suche wiederholen und an die gefundenen Maschinen-Konten löschen lassen:

Get-ADComputer -Property Name,lastLogonDate -Filter {lastLogonDate -lt $v_time} | Remove-ADComputer

Vor dem Löschen der Computerkonten erfolgt noch eine Sicherheitsabfrage.

Sonderfall: AD-Konto wurde noch nie genutzt

Get-ADComputer -Filter * -Property * | where-object lastlogondate -eq $null | Select-Object Name,LastLogonDate | Export-CSV d:\result.csv -NoTypeInformation -Encoding UTF8

Sind nur wenig Objekte gelöscht worden, können sie am besten über das Tool ADRestore.Net wiederhergestellt werden (Nicht auf den DCs installieren!)
Das Tool ist selbsterklärend.
AD-Restore.Net

Sind AD-Objekte gelöscht worden, bleiben sie für „X“ Tage im AD-Papierkorb.
Sie lassen sich per Befehlszeile zurückholen:

Get-ADObject -Filter {givenname -eq 'Test1'}
Get-ADObject -Filter {givenname -eq 'Test1'} -IncludeDeletedObjects
Get-ADObject -Filter {givenname -eq 'Test1'} -IncludeDeletedObjects | Restore-ADObject
 
Get-ADObject -Searchbase 'CN=Deleted Objects,DC=SG,DC=test,DC=intra' -LdapFilter '(objectclass=organizationalUnit)' -IncludedeletedObjects
 
Get-ADObject -Searchbase 'CN=Deleted Objects,DC=SG,DC=test,DC=intra' -LdapFilter '(objectclass=user)' -IncludedeletedObjects
Get-ADObject -filter 'name -like "Test*"' -searchbase 'CN=Deleted Objects,DC=SG,DC=test,DC=intra' -Includedeletedobjects -properties lastknownparent

Wichtig:
Diese Befehle funktioniern nur in der Powershell, wenn die entsprechenden AD-Erweiterungen geladen wurden

cmd oder powershell „als Administrator ausführen“ Update der Gruppenrichtlinien:

gpupdate /force

Prüfung der Gruppenrichtlinien:

gpresult /r

powershell „als Administrator ausführen“

Get-GPResultantSetOfPolicy -ReportType Html -Path $env:USERPROFILE\desktop\report.html

Gruppenrichtlinie für Remotesystem abfragen:

Get-GPResultantSetOfPolicy -computer script01 -ReportType Html -Path -Path $env:USERPROFILE\desktop\report.html

der Benutzer muss an dem System schon einmal eingelogt gewesen sein

AdminSDHolder ist die Ursache für einige Probleme, deren Ursache zunächst verwirrend ist:

• Einem AD-Objekt gegebene Berechtigungen werden nach einigen Minuten automatisch wieder entfernt
  irgend etwas setzt alle Rechte auf einem Objekt wieder auf einen noch nicht bekannten Standard zurück.
• Vererbungen auf ein AD-Objekt werden nach einigen Minuten automatisch wieder entfernt
  Rechte auf das fragliche Objekt werden nicht vererbt und bei manueller Korrektur werden die Änderungen nach einiger Zeit von irgendwas rückgängig gemacht.
• OWA2007/2010 kann nicht genutzt werden, da die „Spracheinstellung“ nicht gesetzt werden kann.
  Der Exchange Server hat nicht die erforderlichen Rechte, bei einem Benutzer die OWA-Sprache in das entsprechende AD-Feld zu schreiben.
• Exchange 2010 „New-LocalMoveRequest“ geht nicht mit „Client Permission“.
  Bei der Migration bricht Exchange ab, da angeblich keine Rechte auf das Postfach bestehen.
• ActiveSync funktioniert nicht
  Alle anderen Benutzer können normal arbeiten nur dieser fragliche Benutzer kann kein Pushmail nutzen.
• Mails an öffentliche Ordner von Administratoren
  Wird von einem Administrator eine Mail an einen mailaktivierten Ordner gesendet, kommt ein „554 5.2.1 unzustellbar“ zurück, auch wenn er sich die erforderlichen Rechte eingerichtet hat. Der Store möchte den Absender prüfen, ihm fehlen aber die erforderlichen Berechtigungen dazu. Normale Anwender können diesen Ordner erreichen.

Diese Liste ist nicht vollständig.

In einem Active Directory gibt es Administratoren und normale Benutzer. Und es gibt besondere Gruppen, über die ein Benutzer mehr Berechtigungen erhalten kann (wie z.B. Kontenoperatoren). Bei einer ungeschickten Konfiguration könnte dies zu einer Sicherheitslücke führen: Beispiel:

• Ein Helpdesk Mitarbeiter hat das Recht, Kennworte auf andere Benutzer zurück zu setzen.
• Ein administrativer Benutzer mit Privilegien ist in einer dieser OUs angelegt

Der Helpdesk-Mitarbeiter könnte so das Kennwort des administrativen Kontos zurücksetzen, sich damit anmelden und Schaden anrichten.

Das Active Directory „schützt“ daher seine Admin-Konten. Dieser Prozess läuft auf jedem DC per Default alle Stunde. Diese Vorgabe kann in der Registrierung angepasst werden.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"AdminSDProtectFrequency"=dword:00000e10

Der Wert wird in Sekunden angegeben und kann zwischen 60 und 7200 (2 Stunde) liegen.

• Active Directory - AdminSDHolder, Protected Groups and SDPROP
  https://technet.microsoft.com/en-us/library/2009.09.sdadminholder.aspx
• 817433 Delegated permissions are not available and inheritance is automatically disabled
• 232199 Description and Update of the Active Directory AdminSDHolder object
• 318180 AdminSDHolder thread affects transitive members of distribution groups

Genau dieser Hintergrundthread sucht regelmäßig nach Objekten in administrativen Gruppen und führt dann vier Dinge aus:

• Feld AdminCount = „1“
  
• Deaktivierung der Vererbung von Berechtigungen
  
• Setzt die Rechte anhand des AdminSDHolder-Templates
  
  Gerade dieser letzter Punkt ist für Exchange relevant, weil damit auch jedes „SendAs“-Recht immer wieder außer Kraft gesetzt wird. Bitte prüfen Sie genau, ob eine Änderung des Templates der richtige Weg ist.
• Eintrag im Eventlog
  Zumindest bei Windows 2008R2 DCs findet sich folgender Eintrag:
  

  Log Name:      Security
  Source:        Microsoft-Windows-Security-Auditing
  Event ID:      4780
  Task Category: User Account Management
  Level:         Information
  Keywords:      Audit Success
  Computer:      dc1.msxfaq.de
  Description:
  The ACL was set on accounts which are members of administrators groups.
   
   
  Subject:
        Security ID:        ANONYMOUS LOGON
        Account Name:       ANONYMOUS LOGON
        Account Domain:     NT AUTHORITY
        Logon ID:           0x3e6
   
  Target Account:
        Security ID:        MSXFAQ\DC1 $
        Account Name:       DC1$
        Account Domain:     DC=msxfaq,DC=de
   
  Additional Information:
        Privileges:         -
   
  Every hour, the Windows domain controller that holds the primäry domain controller
   (PDC) Flexible Single Master Operation (FSMO) role compares the ACL on all security
   principal accounts (Users, groups, and machine accounts) present für its domain in
   Active Directory and that are in administrative groups against the ACL on the
   AdminSDHolder object.  If the ACL on the principal account differs from the ACL
   on the AdminSDHolder object, then the ACL on the principal account is reset to
   match the ACL on the AdminSDHolder object and this event is generated.

  
  Also stellt sich die Frage, welche Gruppen denn als „schützenswert“ zählen.

Windows schützt die eingebauten administrativen Gruppen gegen zu viele Berechtigungen. Dazu sind im Active Directory so genannte Standardrechte hinterlegt die auf gekennzeichnete Objekte immer wieder angewendet werden. Die sind z.B. die Gruppen:

• Enterprise Administratoren
• Schema Administratoren
• Domain Administratoren
• Administrators
• Account Operators
• Server Operators
• Print Operators
• Backup Operators
• Cert Publishers

Zusätzlich sind auch noch folgende Benutzer besonders geschützt:

• Administrator
  Der Default Administrator
• krbtgt
  Kerberos Account

Der Schutz bezieht sich aber nicht nur auf die Gruppen selbst, sondern auch auf die Konten, die Mitglieder dieser Gruppen sind. Dabei wirken sich sogar indirekte Mitgliedschaften über andere Gruppen hinweg aus und auch die Mitgliedschaft über Verteiler aus, also Gruppen ohne SID. Das ist zu beachten, da das Tool „WHOAMI“ solche Verteiler nicht mit berücksichtigt.

<box 90% round #FFFF33 #FFFF00 #FFFF99 #FFFF99| Hinweis>Der Schutz durch AdminCount ist wichtig, da z.B. Exchange 2010 der Gruppe „Organization Management“ umfangreiche Berechtigungen vergibt, z.B. Um die Mitglieder von Verteilern zu pflegen. Leider wird hier nicht zwischen Gruppen die für Exchange relevant und anderen Gruppen unterschieden. Nur dank AdminSDHolder kann sich also ein Exchange Administrator nicht zum Domänen Administrator aufschwingen.</box>

<box 90% round #FFFF33 #FFFF00 #FFFF99 #FFFF99| Hinweis> Das Feld „AdminCount“ ist nicht in den GC repliziert. Wer mehrere Domänen hat, muss also nacheinander alle Domains durchlaufen und absuchen. Sh. http://msdn.microsoft.com/en-us/library/windows/desktop/ms675212(v=vs.85).aspx</box>

Mit einer einfachen LDAP-Abfrage können Sie dies z.B. gegen den DC abfragen. Im GC ist das Attribut nicht vorhanden!

REM Export in Textdatei
ldifde -d "dc=msxfaq,dc=de" -r "(admincount=*)" -f admincount.txt -l "dn,admincount"

Export auf Bildschirm

dsquery * -filter "(admincount=1)"

In einer PowerShell können diese Informationen über ADSI abgefragt werden (EMC):

# Suche der Adminaccounts in der aktuellen Domain
([adsisearcher]"(AdminCount=1)").findall()

Eine Abfrage mit Softerra LDAP-Browser oder LDP funktionieren genauso. Selbst mit der normalen MMC für Benutzer und Computer können Sie eine passende benutzerdefinierte Suche ausführen:

Bei Exchange 2007 kann auch ein Eventlogeintrag hilfreich sein. Wenn ein Benutzer erstmals ein Postfach bekommt, dann versucht Exchange die Mailbox Security Descriptoren zu setzen. Das funktioniert natürlich auch nicht, wenn der Benutzer keine vererbten Berechtigungen hat. Im Eventlog findet sich dann:

Ereignistyp: Warnung
Ereignisquelle: MSExchangeIS
Ereigniskategorie: Allgemein
Ereignis-ID: 9554
Datum: 12.09.2008
Zeit: 19:22:44
Benutzer: Nicht zutreffend
Computer: SRV01
Beschreibung:
Die Postfach-SD in der DS konnte nicht aktualisiert werden. Postfach-Guid:
12345678-1234-1234-1234-123456789abd. Fehlercode 0x80070005

Administratoren sollten kein Postfach haben oder Benutzer mit Postfach sollten nie auch Administrator sein.

Möglicherweise ist einfach die Vererbung abgeschaltet. Aber auch dann hilft ADFind http://www.joeware.net/freetools/tools/adfind/ weiter.

adfind -sc aclnoinherit -b "dc=msxfaq,dc=de"

Damit werden am Bildschirm alle Objekte ausgegeben, bei denen die Vererbung deaktiviert ist. Besonders perfide sind natürlich Gruppenmitgliedschaften, die man auf den ersten Blick auch mal übersehen kann.

Auf den ersten Blick fällt hier nicht auf, dass hier jemand irrtümlicherweise die Domänenbenutzer in die lokale Administratoren-Gruppe der Domäne addiert hat.

Function: Set-AdminUser – Clear AdminCount and Enable Security Inheritance \\http://www.ehloworld.com/1621

Das Problem ist natürlich auch Microsoft nicht unbemerkt geblieben, dass Administratoren auch „normale Anwender“ in vielleicht nur temporär administrative Gruppen addieren und die Folgen nicht bedenken. Um solche einen Irrtum rückgängig zu machen, reicht es leider nicht, den Benutzer wieder aus der Gruppe zu entfernen, denn die Änderungen werden dabei nicht rückgängig gemacht. Das Entfernen aus einer Admingruppe ist aber der Anfang der „Reparatur“.

Microsoft selbst hat ein VBScript (resetaccountsAdminSDHolder.vbs im KB Artikel 817433 Delegated permissions are not available and inheritance is automatically disabled) veröffentlicht, um alle Objekte mit „Admincount=1“ zu finden und sowohl die Vererbung wieder zu aktivieren als auch den Admincount auf 0 zu setzen. Es ist ziemlich ungefährlich, dieses Skript zu aktivieren, da der Hintergrundprozess entsprechende Administratoren schnell wieder schützt. Sie können also das Skript starten und einen Stunde später wieder nach dem Admincount suchen, um verbliebene Administratoren zu finden.

Allerdings setzt dieses Skript nicht die Standardrechte zurück. Dies ist aber auf folgenden Wegen möglich:

• MMC für Benutzer
  In der erweiterten Ansicht gibt es mittlerweile einen Knopf zum Zurücksetzen
  
• ResetAccountsAdminSDHolder.vbs
  Microsoft hat im KB-Artikel „817433 Delegated permissions are not available and inheritance is automatically disabled“ das Verhalten ebenfalls erklärt und ein VBScript veröffentlicht, um AdminSDHolder und Berechtigungen zurück zu setzen. Da KB-Artikel manchmal auch „verschwinden“, ist das Skript hier als Download hingelegt. resetaccountsadminsdholder.zip
• DSACLS
  Über das Kommandozeilenprogramm DSACLS können Sie ebenfalls die Standardrechte auf einzelne Objekte oder ganze OUs und Domains anwenden.
  <box 90% round #FFFF33 #FFFF00 #FFFFCC #FFFFCC | Achtung>Prüfen Sie genau, ob Sie nicht absichtlich auf bestimmten Objekten zusätzliche Berechtigungen vergeben haben. So gibt man oft einem Clusterdienstkonto das Recht, den ServicePrincipalName (Siehe Kerberos) zu setzen.

DSACLS ersetzt auch Rechte auf OUs, d.h. eventuell zur Delegierung von administrativ vergebene Berechtigungen werden ebenfalls entfernt. Verschiedene Programme (z.B. OCS) vergeben auch Berechtigungen an Dienstkonten</box>