Das Active Directory (AD) stets zu pflegen, ist eines der Aufgaben eines AD-Administrators. Mit der Zeit entstehen Leichen was die Computerkonten im AD betrifft. Clients die verschrottet wurden, sind vorher nicht aus der Domäne entfernt worden. Aber auch wenn Clients oder Mitgliedsserver aus der Domäne entfernt und zu einer Arbeitsgruppe (AG) hinzugefügt werden, wird nicht automatisch das Computerkonto im AD gelöscht. Es wird lediglich deaktiviert und bleibt im AD bestehen. Im Nachgang muss dann das Computerkonto manuell entfernt werden.
State oft the Art löscht man die Computerkonten mit der AD-PowerShell. Weitere Möglichkeiten findet man im folgenden Artikel:
Computerkonto löschen
# Alle deaktivierten Computerkonten, also alle Computer (Clients und Mitgliedsserver) die aus der Domäne entfernt und in eine AG hinzugefügt oder manuell deaktiviert wurden, werden mit diesem Befehl angezeigt:
Search-ADAccount -AccountDisabled -ComputersOnly | Sort-Object | FT Name -A
Sollen die deaktivierten Computerkonten aus einer bestimmten Organisationseinheit (OU) angezeigt werden, so gilt es diesen Befehl zu verwenden:
Search-ADAccount -AccountDisabled -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Sort-Object | FT Name -A
# Alle deaktivierten Computerkonten werden auf Nachfrage, nacheinander mit diesem Befehl gelöscht:
Search-ADAccount -AccountDisabled -ComputersOnly | Sort-Object| Remove-ADComputer
Deaktivierte Computerkonten aus einer bestimmten OU werden auf Nachfrage mit diesem Befehl entfernt:
Search-ADAccount -AccountDisabled -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Sort-Object| Remove-ADComputer
Sollen alle deaktivierten Computerkonten auf einmal ohne Nachfrage gelöscht werden, so muss der Parameter „-Confirm:“ mit dem Wert „$False“ mit angegeben werden. Sprich:
Search-ADAccount –AccountDisabled -ComputersOnly | Remove-ADComputer -Confirm:$False
Ohne Nachfrage werden die deaktivierten Computerkonten aus einer OU wie folgt gelöscht:
Search-ADAccount –AccountDisabled -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Remove-ADComputer -Confirm:$False
# Alle Computer die sich seit 180 Tagen nicht am AD angemeldet haben werden mit dem folgenden Befehl angezeigt. Damit der Parameter AccountInactive verwendet werden kann, muss sich jedoch der Domänenfunktionsmodus mindestens auf der Ebene “Windows Server 2003” befinden:
Search-ADAccount -AccountInactive –Timespan 180 –ComputersOnly | Sort-Object | FT Name -A
Möchte man sich alle Computer aus einer bestimmten OU anzeigen, die sich seit 180 Tagen nicht mehr am AD angemeldet haben, so sieht der Befehl folgendermaßen aus:
Search-ADAccount -AccountInactive –Timespan 180 -Searchbase “OU=<OU>,DC=Domäne,DC=de” –ComputersOnly | Sort-Object | FT Name -A
Gelöscht werden die Computerkonten dann wie folgt:
Search-ADAccount -AccountInactive –Timespan 180 -ComputersOnly | Remove-ADComputer -Confirm:$False
Aus einer bestimmten OU werden die Computerkonten so entfernt:
Search-ADAccount -AccountInactive –Timespan 180 -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Remove-ADComputer -Confirm:$False
# Alle Computer die seit dem 01.01.2010 inaktiv sind und sich nicht mehr am AD angemeldet haben, werden wie folgt angezeigt:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" –ComputersOnly | Sort-Object | FT Name -A
Alle Computer aus einer bestimmten OU, die sich seit dem 01.01.2010 nicht mehr am AD angemeldet haben, werden so angezeigt:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" -Searchbase “OU=<OU>,DC=Domäne,DC=de” –ComputersOnly | Sort-Object | FT Name -A
Alle Computerkonten die sich seit dem 01.01.2010 nicht mehr am AD angemeldet haben, lassen sich dann mit diesem Befehl löschen:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" –ComputersOnly | Remove-ADComputer -Confirm:$False
Die Computer einer bestimmten OU, die seit dem 01.01.2010 inaktiv sind, werden wie folgt gelöscht:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" -Searchbase “OU=<OU>,DC=Domäne,DC=de” –ComputersOnly | Remove-ADComputer -Confirm:$False
Weitere Informationen:
Das Erstellungsdatum eines AD-Objekts mit der AD-PowerShell abfragen
AD-PowerShell Befehle
Zwei wichtige IDs eines Domänencontrollers (DC) sind der DC GUID (Globaly Unique Identifier) und der Datenbank GUID. Beide IDs sind wichtige Bestandteile bei der AD-Replikation. Mit dem Kommandozeilenbefehl Repadmin /Showrepl <DC> kann man sich beide IDs anzeigen lassen. Gibt man den <DC> nicht an, wird der Befehl gegen den DC ausgeführt, auf dem man den Repadmin Befehl ausführt. Führt man den Befehl auf einem Windows Server 2003 DC aus, so erhält man diese Ausgabe auf dem ersten DC einer Gesamtstruktur:
Auf einem Windows Server 2008 R2 DC sieht das Ergebnis auf dem ersten DC wie folgt aus:
Jeder DC besitzt eine eindeutige DC GUID innerhalb einer Gesamtstruktur, der auch als Directory Service Agent GUID (kurz DSA-GUID) bekannt ist. Mit der DC GUID der im Attribut objectGUID gespeichert ist, wird der DC in der Gesamtstruktur identifiziert. Dabei spielt es auch keine Rolle in welcher Domäne sich der DC innerhalb einer Gesamtstruktur befindet. Der DC GUID eines DCs ist in der Gesamtstruktur einmalig und ändert sich solange der DC existiert (im Gegensatz zu der invocationId) niemals! Es sei denn, der DC wird zuerst herunter- und anschließend wieder zum DC heraufgestuft. Denn der DC GUID eines DCs wird beim heraufstufen eines Servers zu einem DC erstellt und beim herunterstufen eines DCs entfernt. Natürlich ist das manuelle bearbeiten des DC GUIDs ebenso nicht möglich, weil das Attribut objectGUID system-only ist. Das Attribut objectGUID findet man in den Eigenschaften des „NTDS Settings“ Objekts unterhalb des entsprechenden DC-Objekts in der Konfigurationspartition und ist als ein Oktett-String gespeichert. Der LDAP-Pfad zum “NTDS Settings” Objekt lautet: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne.
Die objectGUID wird unter anderem auch dazu verwendet, um die Reihenfolge der DCs einer ringförmigen Replikationstopologie zu bestimmen und ist außerdem bei der Wahl des Bridgeheadservers eines AD-Standorts von Bedeutung. Damit der DC für seine Replikationspartner erreichbar ist, erstellt dieser mit der objectGUID in der Forward Lookup Zone _msdcs.Root-Domäne im DNS einen CNAME Eintrag.
Beim heraufstufen eines Servers zu einem DC wird der AD-Datenbank (NTDS.dit) ebenfalls eine GUID zugeordnet, die als Datenbank GUID bezeichnet wird. Diese GUID wird dazu verwendet, um die AD-Datenbank eines DCs bei einem Replikationsaufruf zu identifizieren. Bei der Datenbank GUID handelt es sich um das Attribut invocationId und befindet sich so wie die objectGUID ebenfalls in der Konfigurationspartition, in den Eigenschaften des NTDS Settings Objekts eines DCs im LDAP-Pfad: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne. Auch die invocationId wird wie die objectGUID beim heraufstufen eines Servers zu einem DC erstellt und beim herunterstufen eines DCs entfernt. Replikationspartner nutzen die invocationId und die Update Sequence Number (USN) um die aktuellen Änderungen für die AD-Replikation zu bestimmen.
Die invocationId des ersten DCs mit dem die Gesamtstruktur erstellt wurde, hat den gleichen Wert wie die objectGUID. Bei allen weiteren DCs einer Gesamtstruktur werden unterschiedliche Werte in den beiden Attributen objectGUID und invocationId gespeichert.
Im Gegensatz zur objectGUID ändert sich die invocationId wenn:
- eine neue Anwendungsverzeichnispartition erstellt wird. Oder wenn eine bestehende Anwendungsverzeichnispartition entfernt und erneut erstellt wird.
- der DC mit einer gültigen Sicherung und einer unterstützten Rücksicherungsmethode (supportet von Microsoft!) rückgesichert wird. Eine gültige Sicherung ist eine Sicherung die mit einer Sicherungssoftware durchgeführt wurde, dass das entsprechende API des Betriebssystems verwendet und somit das AD in Kenntnis setzt, dass eine Sicherung durchgeführt wurde. Nur wenn eine gültige und somit eine supportete Sicherung mindestens vom System State durchgeführt wird, erspart man sich je nach Umgebung größeren Schaden im Fall einer Rücksicherung! Ab Windows Server 2003 SP1 kann man mit dem Kommandozeilenbefehl Repadmin /Showbackup überprüfen, ob eine Verzeichnispartition jemals supportet gesichert wurde.
Eine unterstützte Rücksicherung findet in Abstimmung mit der AD-Replikation statt. Denn nur wenn das AD durch eine ordnungsgemäß durchgeführte System State Sicherung und einer supporteten Rücksicherungsmethode rückgesichert wird, erhält die invocationId auf dem rückgesicherten DC einen neuen Wert. Dadurch erkennen alle anderen DCs, dass die Metadaten für die AD-Replikation zu dem rückgesicherten DC hinfällig sind und das die AD-Replikation ab dem durchgeführten Sicherungsdatum mit dem der DC rückgesichert wurde, neu aufgebaut und durchgeführt werden muss. Einige Sicherungsprogramme (bis Windows Server 2003 NTBACKUP und ab Windows Server 2008 Wbadmin, ARCServe…) führen eine ordnungsgemäße Sicherung und Rücksicherung des System States durch und darauf kommt es an!
Das entscheidende bei der Rücksicherung ist nun mal, dass die invocationId einen neuen Wert erhalten muss! Das ist genau der Nachteil bei Image-Programmen. Beim klassischen Imagen zieht man sich eine eins zu eins Kopie des DCs. Sollte es nun zum Rückspielen des Images kommen, erhält die invocationId keinen neuen Wert und somit erfahren je nach Umgebung die Replikationspartner auch nicht, dass ein DC rückgesichert wurde und das die Replikation mit dem rückgesicherten DC neu aufgebaut werden muss. Beim rücksichern eines Images schafft man sich ein USN Rollback, was je nach Fall zu einem größeren Schaden für die AD-Umgebung bedeutet! Im günstigsten Fall hätte man sich lediglich den zurück-geimageten DC zerstört. Diesen müsste man dann gewaltsam herunterstufen und anschließend die Metadaten des AD bereinigen (siehe weiterführende Informationen). Im ungünstigsten Fall hätte man mindestens doppelte RIDs verteilt, nicht mehr gültige Computerkontokennwörter und keine funktionierende AD-Replikation mit diesem DC mehr!
Wenn eine unterstützte Rücksicherung stattgefunden hat, wird der nicht mehr gültige Wert aus dem Attribut invocationId in das Attribut retiredReplDSASignatures (das sich ebenfalls im NTDS Settings Objekt eines DCs befindet) gesetzt.
Auch eine IFM (Install from Media) Installation eines DCs kommt einer Rücksicherung eines DCs gleich. Denn bei einer IFM-Installation wird der Wert aus dem Attribut invocationId das von der Sicherung stammt, in das Attribut retiredReplDSASignatures auf dem neuen DC geschrieben. Der Grund dafür ist, wenn ein Verbindungsobjekt für die Replikation erstellt wird, überprüft der neue DC sein Attribut retiredReplDSASignatures um festzustellen ob das Attribut einen Wert enthält, der mit den invocationIds im Up-To-Dateness Vector (UTDV) des Ziel-DCs übereinstimmt. Durch diese Vorgehensweise ist sichergestellt, dass nur eine Teilmenge der AD-Datenbank, nämlich nur die Änderungen die ab der Sicherung durchgeführt wurden repliziert wird.
Durch die ausschließlich ordnungsgemäß durchgeführte Sicherung und der Rücksicherungsmethode wird ein USN Rollback und somit Schaden verhindert! Wenn man sich nicht sicher ist ob das eingesetzte Sicherungsprogramm eine unterstützte Sicherung sowie Rücksicherung durchführt, sollte man ein klärendes Telefonat mit dem Hersteller führen. Von ungültigen Sicherungsmethoden wie das Rücksichern eines Images, VM-Images und VM-Snapshots (mindestens auf Servern die transaktionale Datenbanken bereitstellen wie ein DC, Exchange und SQL) sollte man stets Abstand halten und wird seitens Microsoft auch nicht supportet!
Auf einem DC ist es Pflicht mindestens das System State zu sichern und das kann man bereits mit Windows-Bordmittel (NTBACKUP, Wbadmin) durchführen!
Weiterführende Informationen:
Domänencontroller-Installation von einer Sicherung
Images als Sicherung?
Das Active Directory gewaltsam vom DC entfernen
Die Metadaten des Active Directory unter Windows Server 2008 bereinigen
Der RID-Master und sein RID-Pool
Lingering Objects (veraltete Objekte)
How to detect and recover from a USN rollback in Windows Server 2003
How To Convert a String Formatted GUID to a Hexadecimal String Form For Use When Querying the Active Directory
Immer wieder stolpere ich darüber, dass Administratoren den DHCP-Dienst als Sicherheitsfeature missbrauchen oder durch entsprechende Konfigurationen auf dem DHCP-Server glauben, dadurch Sicherheit im Netzwerk zu schaffen.
Um die Frage im Titel gleich vorweg zu beantworten: DHCP ist nicht im Geringsten ein Sicherheitsfeature!
Zur Erinnerung: DHCP steht für Dynamic Host Configuration Protocol und dieses Protokoll ermöglicht das dynamische Zuweisen von IP-Informationen durch einen DHCP-Server an DHCP-Clients, wie z.B. an Computer oder Drucker. Dadurch ist es jedem Externen der Zutritt zu den Büroräumen hat oder ein Mitarbeiter der sein privates Laptop mit ins Büro bringt möglich, sein Laptop mit dem Netzwerk zu verbinden und somit automatisch eine IP-Adresse vom DHCP-Server zu erhalten. Denn eine Option den Windows DHCP-Server so zu konfigurieren, das lediglich Clients die Mitglied in der Domäne sind nur eine IP-Lease erhalten existiert nicht. Der DHCP-Server dient einzig und allein nur zum verteilen von IP-Informationen und stellt keineswegs ein Sicherheitsfeature dar!
Einige Administratoren behaupten vielleicht nun: Dann konfiguriert man im DHCP-Server einen IP-Bereich der nur so viele IP-Adressen enthält wie auch tatsächlich benötigt werden und erstellt für jedes DHCP Gerät eine Reservierung. Bei einer Reservierung wird die entsprechende IP-Adresse zusammen mit der MAC-Adresse der Netzwerkkarte hinterlegt. Dadurch ist es fremden DHCP Geräten nicht mehr möglich, eine IP-Adresse vom DHCP-Server zu beziehen. Weiter wird dann argumentiert, dass mit diesem Verfahren ein „Otto-Normal Benutzer“ überfordert ist um diese Barriere zu umgehen. Doch dank des Internets und dem Netzwerkkartentreiber kann auch ein normaler Benutzer die MAC-Adresse eines Clients erspähen und somit mit seinem privaten Laptop die IP-Informationen vom DHCP-Server beziehen.
Anstatt durch den DHCP-Server scheinbare Sicherheit im Netzwerk zu schaffen, sollte man stattdessen z.B. IPSec-Richtlinien einführen. Damit kann man zwar nicht verhindern das Dritte IP-Informationen vom DHCP-Server erhalten, sie können aber nicht am Windows-Netzwerk teilnehmen. Denn durch die Einführung von IPSec-Richtlinien wird die gesamte Netzwerkkommunikation mit IPSec verschlüsselt. Andere Techniken um Dritte von der Netzwerkkommunikation auszuschließen sind 802.1x, VLANs oder Network Access Protection (NAP) das ab Windows Server 2008 zur Verfügung steht.
Daher: Die Sicherheit im Netzwerk ist keine einmalige Angelegenheit, ganz im Gegenteil. Die Sicherheit eines Netzwerks muss ständig kontrolliert und gegeben falls angepasst werden. Das ist ein Vorgang der nie aufhört. Dabei fängt die Sicherheit bereits an der Eingangstür zum Gebäude an! Können Personen unbemerkt ins Gebäude eindringen und sich unbemerkt Zugriff zum Netzwerk und zu den Systemen beschaffen? Denn wenn der physikalische Zugriff zum Netzwerk und zu den Systemen gegeben ist, existiert schlichtweg keine Sicherheit!
Der Distinguished Name (DN) der einzelnen Verzeichnispartitionen die auf einem Domänencontroller (DC) gespeichert sind, werden in den folgenden Attributen gespeichert. Diese Attribute gehören zur nTDSDSA-Objektklasse und befinden sich in den Eigenschaften des „NTDS Settings“ Objekts des jeweiligen DCs. Zu finden ist das Objekt in diesem LDAP-Pfad: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne.
Die im Verlauf dieses Artikels verwendeten Abfragen werden unter anderem über alle AD-Standorte hinweg durchgeführt. Möchte man die Abfrage auf einen bestimmten AD-Standort eingrenzen, so muss im Filter der gewünschte AD-Standort mit angegeben werden. Also anstatt "CN=Sites,CN=Configuration,DC=Root-Domäne" muss es dann so lauten: "CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne".
In welchen Attributen ist die Information gespeichert, welche Verzeichnispartitionen sich auf einem DC befinden?
hasMasterNCs = In diesem mehrwertigen (multivalue) Attribut werden die DNs der beschreibbaren Verzeichnispartitionen die sich auf einem DC befinden gespeichert. Diese sind standardmäßig die Schema-, Konfigurations- und Domänenpartition. In diesem Attribut werden aber keine Anwendungsverzeichnispartitionen gespeichert, wie z.B. die beiden DNS-Partitionen ForestDNSZones sowie DomainDNSZones. Auf RODCs enthält dieses Attribut logischerweise keinen Wert, da auf einem RODC keine beschreibbaren Verzeichnispartitionen gespeichert sind da der RODC auf alle Verzeichnispartitionen lediglich das Leserecht besitzt!
hasPartialReplicaNC = In diesem mehrwertigen Attribut werden die DNs der Domänenpartitionen aus den anderen Domänen innerhalb einer Gesamtstruktur gespeichert, die sich auf einem DC befinden. Das Attribut enthält nur dann einen Wert, wenn zum einen mehr als eine Domäne in der Gesamtstruktur existiert und zum anderen, auf dem DC der globale Katalog (GC) aktiviert wurde! Da ein GC lediglich das Leserecht auf die Domänenpartitionen aus anderen Domänen hat, sind in diesem Attribut die DNs der Domänenpartitionen worauf ausschließlich das Leserecht besteht gespeichert. Da man auf einem RODC auch den GC aktivieren kann, werden bei der Abfrage nach diesem Attribut auch RODCs angezeigt.
msDS-HasDomainNCs = In diesem einwertigen (single-value) Attribut das erst ab Windows Server 2003 existiert, wird der DN der Domänenpartition die sich auf einem DC befindet gespeichert. RODCs verwenden ebenfalls dieses Attribut und werden demzufolge auch bei Abfragen mit angezeigt.
msDS-hasFullReplicaNCs = In diesem mehrwertigen Attribut das nur von einem RODC genutzt wird, sind die DNs der Verzeichnispartitionen: Schemapartition, Konfigurationspartition, Domänenpartition (in der sich der RODC befindet) sowie den beiden DNS-Anwendungsverzeichnispartitionen DomainDNSZones und ForestDNSZones gespeichert.
msDS-hasMasterNCs = In diesem mehrwertigen Attribut werden sämtliche DNs der beschreibbaren Verzeichnispartitionen die sich auf einem DC befinden gespeichert. Standardmäßig enthält das Attribut ab Windows Server 2003 die DNs der folgenden Verzeichnispartitionen: Schemapartition, Konfigurationspartition, Domänenpartition sowie die beiden Anwendungsverzeichnispartitionen DomainDNSZones (der eigenen Domäne) und ForestDNSZones. Da ein RODC keine beschreibbaren Verzeichnispartitionen vorhält, erscheinen bei der Abfrage nach diesem Attribut demzufolge auch keine RODCs!
msDS-NC-Replica-Locations = In diesem mehrwertigen Attribut, das sich im Container CN=Partitions,CN=Configuration,DC=Root-Domäne in den Eigenschaften der Cross-Reference (crossRef) Objekte befindet, sind in den crossRef Objekten der Anwendungsverzeichnispartitionen der DN der NTDS Settings-Objekte aller DCs gespeichert, die eine Replik der entsprechenden Anwendungsverzeichnispartition gespeichert haben. Ab Windows Server 2003 sind es mindestens die beiden DNS-Partitionen "DomainDNSZones" und "ForestDNSZones".
Welche beschreibbaren Verzeichnispartitionen sind auf einem DC gespeichert?
Um herauszufinden welche beschreibbaren Verzeichnispartitionen auf einem DC gespeichert sind, sollte eine Abfrage nach dem Attribut msDS-hasMasterNCs erfolgen.
Mit der AD-PowerShell
$ADSI = [ADSI]"LDAP://<DC>:389/CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne"
$ADSI."msDS-hasMasterNCs"
Oder mit diesem AD-PowerShell Befehl:
Get-ADObject -LDAPFilter “(&(objectClass=nTDSDSA)(msDS-hasMasterNCs=*))“ -Searchbase "CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne" -Properties msDS-hasMasterNCs -SearchScope Subtree | Select msDS-hasMasterNCs | % {write $_."msDS-hasMasterNCs"}
Mit LDP
Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN das „NTDS Settings“ Objekt des entsprechenden DCs in der Konfigurationspartition angeben. Also: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (&(objectClass=nTDSDSA)(msDS-hasMasterNCs=*)). Als Suchbereich sollte die Option „Unterstruktur“ ausgewählt und im Feld Attribute msDS-hasMasterNCs angegeben werden.
Mit Dsquery
dsquery * "CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne" -attr msDS-hasMasterNCs
Alle Verzeichnispartitionen einer Gesamtstruktur anzeigen
Die Verzeichnispartitionen einer Gesamtstruktur sind standardmäßig:
-
die Schemapartition (wird auf alle DCs innerhalb einer Gesamtstruktur repliziert, egal in welcher Domäne sie sich befinden).
-
die Konfigurationspartition (wird auf alle DCs innerhalb einer Gesamtstruktur repliziert, egal in welcher Domäne sie sich befinden).
-
die jeweilige Domänenpartition (wird auf alle DCs innerhalb der jeweiligen Domäne repliziert). Wenn sich mehrere Domänen in der Gesamtstruktur befinden, werden alle Domänenpartitionen aufgelistet.
-
die Anwendungsverzeichnispartition ForestDNSZones (wird auf alle DCs innerhalb einer Gesamtstruktur repliziert, egal in welcher Domäne sie sich befinden).
-
die Anwendungsverzeichnispartition DomainDNSZones der jeweiligen Domäne (wird auf alle DCs innerhalb der jeweiligen Domäne repliziert). Existieren mehrere Domänen in einer Gesamtstruktur und wurde die Forward Lookup Zone der entsprechenden Domäne in der DomainDNSZones-Partition gespeichert, werden alle DomainDNSZones-Anwendungsverzeichnispartitionen aufgelistet.
Alle Verzeichnispartitionen einer Gesamtstruktur mit der AD-PowerShell abfragen
Get-ADObject -LDAPFilter "(objectCategory=crossRef)" -Properties * -Searchbase "CN=Partitions,CN=Configuration,DC=Root-Domäne" | ? {$_.systemFlags -band 5} –SearchScope OneLevel | Select ncName
Oder mit dieser AD-PowerShell Abfrage
Get-ADObject -LDAPFilter "(&(objectCategory=crossRef)(systemflags:1.2.840.113556.1.4.804:=5))" -Properties * -Searchbase "CN=Partitions,CN=Configuration,DC=Root-Domäne" -SearchScope OneLevel | Select ncName
Mit LDP
Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN den Partitions Container in der Konfigurationspartition angeben. Also: CN=Partitions,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (&(objectCategory=crossRef)(systemFlags:.12.840.113556.1.4.803:=5)). Als Suchbereich sollte die Option „Eine Ebene“ ausgewählt und im Feld Attribute ncName angegeben werden.
Mit Dsquery
dsquery partition
Oder mit:
dsquery * "CN=Partitions,CN=Configuration,DC=Root-Domäne" -Filter "(&(objectCategory=crossRef)(systemFlags:1.2.840.113556.1.4.804:=5))" -Scope OneLevel -attr ncName
Alle beschreibbaren DCs und die Verzeichnispartitionen anzeigen, die jeweils auf den DCs gespeichert sind
Mit der AD-PowerShell
Get-ADObject -LDAPFilter "(objectClass=nTDSDSA)" -Properties msds-hasMasterNCs -Searchbase "CN=Sites,CN=Configuration,DC=Root-Domäne" | Select distinguishedName,msDS-hasMasterNCs | FT –A -Wrap
Mit LDP
Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN den Sites Container in der Konfigurationspartition angeben. Also: CN=Sites,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (objectClass=nTDSDSA). Als Suchbereich sollte die Option „Unterstruktur“ ausgewählt und im Feld Attribute distinguishedName;msDS-hasMasterNCs angegeben werden.
Mit Dsquery
dsquery * "CN=Sites,CN=Configuration,DC=Root-Domäne" -Filter "(ob jectclass=nTDSDSA)" -attr distinguishedName msds-hasMasterNCs -Limit 0 > C:\Temp\dsquery.txt
Alle Anwendungsverzeichnispartitionen einer Gesamtstruktur anzeigen
Alle Anwendungsverzeichnispartitionen die in einer Gesamtstruktur existieren, standardmäßig sind das ab Windows Server 2003 die beiden DNS-Anwendungsverzeichnispartitionen DomainDNSZones und ForestDNSZones, werden mit der folgenden AD-PowerShell Abfrage angezeigt. Existieren mehrere Domänen in der Gesamtstruktur die mindestens unter Windows Server 2003 betrieben werden, wird für jede Domäne die DNS-Anwendungsverzeichnispartition DomainDNSZones angezeigt.
AD-PowerShell
Get-ADObject -LDAPFilter "(&(objectCategory=crossRef)(systemflags:1.2.84 0.113556.1.4.803:=5))" -Properties * -Searchbase "CN=Partitions,CN=Configuration ,DC=Root-Domäne" -SearchScope OneLevel | Select dnsRoot | FT
Auch mit diesem AD-PowerShell Befehl lassen sich alle Anwendungsverzeichnispartitionen einer Gesamtstruktur Anzeigen:
Get-ADObject -LDAPFilter "(objectCategory=crossRef)" -Searchbase "CN=Partitions,CN=Configuration,DC=Root-Domäne" -Properties * -SearchScope OneLevel | Where {$_.systemFlags -band 4} | Select dnsRoot
Mit LDP
Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN den Partitions Container in der Konfigurationspartition angeben. Also: CN=Partitions,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (&(objectCategory=crossRef)(systemFlags:.12.840.113556.1.4.803:=5)). Als Suchbereich sollte die Option „Eine Ebene“ ausgewählt und im Feld Attribute dnsRoot angegeben werden.
Mit Dsquery
Mit Dsquery werden alle Anwendungsverzeichnispartitionen einer Gesamtstruktur mit dieser Kommandozeilenabfrage angezeigt:
dsquery * "CN=Partitions,CN=Configuration,DC=Root-Domäne" -Filter "(&(objectCategory=crossRef)(systemflags:1.2.840.113556.1.4.803:=5))" -Scope OneLevel -attr dnsRoot
Welche Anwendungsverzeichnispartitionen sind auf einem DC gespeichert?
Um sich die Anwendungsverzeichnispartitionen die auf einem bestimmten DC gespeichert sind anzuzeigen, gilt es eines der folgenden Abfragen durchzuführen. Standardmäßig werden ab Windows Server 2003 die beiden DNS-Partitionen ForestDNSZones und DomainDNSZones (der jeweiligen Domänen) angezeigt.
Mit der AD-PowerShell
Get-ADObject -LDAPFilter "(&(objectcategory=crossRef)(systemFlags:1.2.840.113556.1.4.803:=5)(msDS-NC-Replica-Locations=CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne))" –Properties * -Searchbase "CN=Partitions,CN=Configuration,DC=Root-Domäne" -SearchScope OneLevel | Select dnsRoot
Oder mit diesem AD-PowerShell Befehl:
Get-ADObject -LDAPFilter "(&(objectCategory=crossRef)(msDS-NC-Replica-Locations=CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne))" -Properties * -Searchbase "CN=Partitions,CN=Configuration,DC= Root-Domäne" -SearchScope OneLevel | Where {$_.systemFlags -band 5} | Select dnsRoot
Mit LDP
Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN den Partitions Container in der Konfigurationspartition angeben. Also: CN=Partitions,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (&(objectcategory=crossRef)(systemFlags:1.2.840.113556.1.4.803:=5)(msDS-NC-Replica-Locations=CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne)). Als Suchbereich sollte die Option „Eine Ebene“ ausgewählt und im Feld Attribute dnsRoot angegeben werden.
Mit Dsquery
dsquery * "CN=Partitions,CN=Configuration,DC=Root-Domäne" -Scope OneLevel -attr dnsRoot -Filter "(&(objectcategory=crossRef)(systemFlags:1.2.840.113556.1.4.803:=5)(msDS-NC-Replica-Locations=CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne))"
Auf welchen beschreibbaren DCs ist die Anwendungsverzeichnispartition ForestDNSZones gespeichert?
Mit dem folgenden AD-PowerShell Befehl werden alle DCs angezeigt, auf denen die ForestDNSZones-Partition gespeichert ist. Dabei spielt es auch keine Rolle, an welchem AD-Standort sich die DCs befinden.
Get-ADObject -LDAPFilter "(&(objectClass=nTDSDSA)(msDS-hasMasterNCs=DC=ForestDNSZones,DC=Root-Domäne))" -Searchbase "CN=Sites,CN=Configuration,DC=Root-Domäne" -SearchScope Subtree | Select distinguishedName | FT
Mit LDP
Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN den Sites Container in der Konfigurationspartition angeben. Also: CN=Sites,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (&(objectClass=nTDSDSA)(msDS-hasMasterNCs=DC=ForestDNSZones,DC=Root-Domäne)). Als Suchbereich sollte die Option „Unterstruktur“ ausgewählt und im Feld Attribute distinguishedName angegeben werden.
Mit Dsquery
dsquery * "CN=Sites,CN=Configuration,DC=Root-Domäne" -Filter "(&(objectClass=nTDSDSA)(msDS-hasMasterNCs=DC=ForestDNSZones,DC=Root-Domäne))" -Scope Subtree -attr distinguishedName
Auf welchen beschreibbaren DCs ist die Anwendungsverzeichnispartition DomainDNSZones gespeichert?
Um die DCs abzufragen auf denen die DNS-Partition DomainDNSZones gespeichert ist, gilt es den folgenden AD-PowerShell Befehl auszuführen. Die DomainDNSZones Verzeichnispartition wird jeweils nur innerhalb der Domäne repliziert.
Get-ADObject -LDAPFilter "(&(objectClass=nTDSDSA)(msDS-hasMasterNCs=DC=DomainDNSZones,DC=Domäne))" –Properties * -Searchbase "CN=Sites,CN=Configuration,DC=Root-Domäne" -SearchScope Subtree | Select distinguishedName | FT -A –Wrap
Mit LDP
Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN den Sites Container in der Konfigurationspartition angeben. Also: CN=Sites,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (&(objectClass=nTDSDSA)(msDS-hasMasterNCs=DC=DomainDNSZones,DC=Domäne)). Als Suchbereich sollte die Option „Unterstruktur“ ausgewählt und im Feld Attribute distinguishedName angegeben werden.
Mit Dsquery
dsquery * "CN=Sites,CN=Configuration,DC=Root-Domäne" -Filter "(&(objectClass=nTDSDSA)(msDS-hasMasterNCs=DC=DomainDNSZones,DC=Domäne))" -Scope Subtree -attr distinguishedName
Einfache Abfrage mit DNSCMD
Eine andere einfache Variante um zu überprüfen ob auf einem bestimmten DC die beiden DNS-Anwendungsverzeichnispartitionen gespeichert sind, stellt das DNS-Kommandozeilentool dnscmd dar. Die Abfrage in einer Kommandozeile die auch domänenübergreifend funktioniert lautet so:
Dnscmd <DC> /EnumDirectoryPartitions
Weitere Informationen:
Die unterschiedliche Größe der AD-Datenbank
Domänencontroller vergleichen
Mit Windows Server 2008 führte Redmond den Read Only Domänencontroller (kurz RODC) ein. Der RODC der für Außenstellen die eine geringe bis keine physikalische Sicherheit den Servern bieten können konzipiert wurde, ist ein Domänencontroller (DC) der ausschließlich einen lesenden Zugriff auf die Active Directory-Domänendienste (AD DS) hat. Der RODC kann keine Änderungen in den AD DS und im AD-integrierten DNS vornehmen (RODNS). Clients oder Applikationen die einen Lesezugriff auf die AD DS benötigen erhalten Zugriff auf den RODC, während Clients oder Applikationen die einen Schreibvorgang in die AD DS durchführen wollen, diesen nicht auf dem RODC durchführen können sondern vom RODC an einen beschreibbaren DC verwiesen werden.
Der RODC besitzt ein vollständiges Replikat der AD-Datenbank, mit allen Attributen und Objekten die sich auch auf einem beschreibbaren DC befinden. Neben dem Unterschied das der RODC lediglich das Leserecht auf die AD-Datenbank hat, werden im Gegensatz zu einem beschreibbaren DC standardmäßig auch keine Benutzer- oder Computeranmeldeinformationen auf dem RODC gespeichert, außer das eigene Computerkonto sowie ein besonderes krbtgt-Konto für diesen RODC. Damit die Anmeldeinformationen der entsprechenden Benutzer-, Computer- und Dienstkonten auf dem RODC gespeichert werden können, muss das explizit in der Kennwortreplikationsrichtlinie (Password Replication Policy, kurz PRP) auf einem beschreibbaren DC gestattet werden, damit der RODC Authentifizierungs- und Dienstticketanforderungen eigenständig verarbeiten kann. Mit der Kennwortreplikationsrichtlinie wird bestimmt, ob die Anmeldeinformationen eines Benutzer- oder Computerkontos von einem beschreibbaren DC auf den RODC repliziert werden können.
Weitere Informationen zum RODC bekommt man in den folgenden beiden Artikeln:
Read-Only Domain Controller (RODC)
Die Installation eines RODC
Der gefilterte Attributsatz vom RODC
Diverse Applikationen könnten die AD-Domänendienste als Datenspeicher verwenden und sensible Daten darin speichern. Oder evtl. möchte man einfach nicht, dass bestimmte Daten von Benutzern (z.B. die Adressdaten oder die Personalnummer) auf einen RODC repliziert werden. Natürlich sollen diese kritischen Daten ebenfalls geschützt sein und nicht auf einem RODC gespeichert werden, falls der RODC kompromittiert, gestohlen oder die Sicherheit gefährdet wird. Und für genau diesen Anwendungstyp gibt es den gefilterten Attributsatz. Der gefilterte Attributsatz (auf Englisch: Filtered Attribute Set, kurz FAS) ist ein dynamischer Attributsatz, die nie auf einen RODC in der Gesamtstruktur repliziert werden da sie sensible oder vertrauliche Daten enthalten. Der gefilterte Attributsatz kann aber erst ab Windows Server 2008 konfiguriert werden.
Damit ein Attribut das wichtige Daten enthält nicht auf einen RODC repliziert wird, sollten die folgenden Schritte durchgeführt werden:
-
Das entsprechende Attribut sollte zu dem gefilterten Attributsatz (FAS) hinzugefügt werden. Damit wird verhindert, dass das Attribut an die RODCs in der Gesamtstruktur repliziert wird. Die Konfiguration des gefilterten Attributsatzes betrifft die Gesamtstruktur und kann nicht pro Domäne konfiguriert werden!
-
Des Weiteren sollte das Attribut als vertraulich gekennzeichnet werden. Dies ist eine weitere Sicherheitseinstellung das konfiguriert werden sollte, wenn man nicht möchte das ein sensibles Attribut zu einem RODC repliziert werden soll! Ein Attribut wird als vertraulich gekennzeichnet, in dem die Leseberechtigung für das entsprechende Attribut für die Gruppe Authentifizierte Benutzer entfernt wird. Somit können diese Attribute von den Mitgliedern der Gruppe Authentifizierte Benutzer (das betrifft alle Benutzer- sowie Computerkonten, inklusive RODCs) nicht mehr gelesen werden. Auch die Konfiguration eines vertraulichen Attributs betrifft die Gesamtstruktur und kann nicht pro Domäne konfiguriert werden! Doch bevor ein Attribut als vertraulich gekennzeichnet wird, sollte der Vorgang in einer Testumgebung ausgiebig getestet werden!
-
Der Gesamtstrukturfunktionsmodus sollte sich aus Sicherheitsgründen mindestens auf Windows Server 2008 befinden. Denn die Attribute die sich im gefilterten Attributsatz befinden, werden nur von DCs die mindestens unter Windows Server 2008 laufen berücksichtigt! Windows Server 2003 DCs ignorieren die Konfiguration das ein Attribut geschützt ist und replizieren die Attribute die sich in dem gefilterten Attributsatz befinden trotzdem auf einen RODC. Die Domänenpartition in der sich der RODC befindet wird zwar erst ab einem beschreibbaren Windows Server 2008 DC auf den RODC repliziert, doch wenn auf dem RODC der globale Katalog (ROGC) aktiviert wird, baut sich eine eigene Replikationstopologie für die Replikation des GCs auf. Existieren in der Gesamtstruktur noch weitere Domänen mit Windows Server 2003 GCs in denen ebenfalls ein gefilterter Attributsatz konfiguriert wurde, ist es durchaus möglich das ein Windows Server 2003 GC den gefilterten Attributsatz aus seiner Domäne zu einem RODC repliziert.
-
Das Hinzufügen eines systemkritischen Attributs zum gefilterten Attributsatz ist nicht möglich! Ein systemkritisches Attribut ist ein Attribut, das z.B. für die ordnungsgemäße Funktion der AD DS oder für das Kerberos-Authentifizierungsprotokoll benötigt wird. Erst wenn in den Eigenschaften des entsprechenden Attributs im Attribut schemaFlagsEx, das aus einer Bitmaske besteht, das Flag FLAG_ATTR_IS_CRITICAL aktiviert ist, handelt es sich um ein systemkritisches Attribut. Dieses Flag existiert aber erst seit Windows Server 2008 und Windows Server 2003 DCs würden diese Einstellung ignorieren. Daher ist es umso mehr wichtig, dass sich nicht nur der Schemamaster auf mindestens einem Windows Server 2008 DC, sondern der Gesamtstrukturfunktionsmodus sich zwingend im Modus Windows Server 2008 oder höher befindet. Denn wäre der Schemamaster ein Windows Server 2003 DC, würde sich ein systemkritisches Attribut dem gefilterten Attributsatz scheinbar erfolgreich hinzufügen lassen. Aber da ein Windows Server 2003 DC die Konfiguration eines gefilterten Attributsatzes sowieso nicht kennt, sollte in einer Gesamtstruktur in der ein gefilterter Attributsatz genutzt wird ein Windows Server 2003 DC ohnehin nicht mehr existieren!
Die technische Umsetzung wie ein Attribut zum gefilterten Attributsatz hinzugefügt wird, findet wie folgt statt
-
Um ein Attribut zum gefilterten Attributsatz hinzuzufügen und somit die Replikation des entsprechenden Attributs zu einem RODC zu verwehren, muss im zu schützenden Attribut das zehnte Bit (also Bit 9) im searchFlags Attribut gesetzt werden. Im searchFlags Attribut kann unter anderem bestimmt werden, dass ein Attribut zum gefilterten Attributsatz hinzugefügt wird und das es vertraulich ist. Im searchFlags Attribut das aus einer Bitmaske besteht, muss im zehnten Bit als Wert in Hexadezimal 0x200 und in Dezimal 512 eingetragen werden. Anschließend wird das entsprechende Attribut zu keinem RODC in der Gesamtstruktur repliziert.
-
Im Attribut searchFlags liegt auch das Geheimnis, warum ein Windows Server 2003 DC die Attribute im gefilterten Attributsatz nicht berücksichtigt. Denn das zehnte Bit, also Bit 9 in searchFlags ist erst mit Windows Server 2008 und der Einführung des RODCs hinzugekommen.
-
Soll ein Attribut zum gefilterten Attributsatz hinzugefügt werden, sollte es auch als vertraulich deklariert werden. Als vertraulich deklariert und somit die Leseberechtigung den Authentifizierten Benutzern entzogen, wird ein Attribut durch das Setzen des achten Bits (Bit 7) ebenfalls im searchFlags Attribut. Dieses Flag kam mit Windows Server 2003 SP1 hinzu. Daher sollte darauf geachtet werden, dass wenn mit diesem Flag Attribute als vertraulich definiert werden, alle DCs in der Gesamtstruktur mindestens unter Windows Server 2003 SP1 installiert sind. Alle älteren Serverversionen ignorieren die Kennzeichnung als vertraulich! Im achten Bit des searchFlags Attributs muss als Wert in Hexadezimal 0x080 und in Dezimal 128 eingetragen werden.
-
Demnach erhält also searchFlags als Wert 640 in Dezimal (in Hexadezimal 0x280), damit zum einen das gewünschte Attribut zum gefilterten Attributsatz hinzugefügt und zum anderen, als vertraulich definiert wird. Trägt man als Wert 641 ein, wird zugleich das Attribut indiziert. Sollten bereits andere Flags im searchFlags Attribut konfiguriert sein, müssen die Werte addiert werden!
Den gefilterten Attributsatz abfragen
Standardmäßig befinden sich die folgenden Attribute ab Windows Server 2008 im gefilterten Attributsatz:
ms-FVE-KeyPackage
ms-FVE-RecoveryPassword
ms-PKI-AccountCredentials
ms-PKI-DPAPIMasterKeys
ms-PKI-RoamingTimeStamp
ms-TPM-OwnerInformation
Um die Attribute die sich im gefilterten Attributsatz befinden abzufragen, muss eine Abfrage nach dem Attribut searchFlags mit dem Wert 512 (das zehnte Bit in searchFlags) durchgeführt werden.
Die Abfrage mit der AD-PowerShell könnte wie folgt lauten
Get-ADObject -LDAPFilter "(objectClass=attributeSchema)" -Searchbase "CN=Schema,CN=Configuration,DC=Root-Domäne" -Properties searchFlags | Where {$_.searchFlags -band 512} | Select Name,searchFlags | Sort Name | FT -Autosize -Wrap
Auch mit diesem AD-PowerShell Befehl lassen sich die gefilterten Attribute anzeigen:
Get-ADObject -LDAPFilter "(&(ObjectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=512))" -SearchBase “CN=Schema,CN=Configuration,DC=Root-Domäne” -SearchScope Subtree | Select Name | Sort Name | FT -Autosize -Wrap
Mit LDP lässt sich der gefilterte Attributsatz folgendermaßen anzeigen
Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN die Schemapartition und als Filter (searchFlags:1.2.840.113556.1.4.803:=512) angeben.
Weitere Informationen:
How to mark an attribute as confidential in Windows Server 2003 Service Pack 1
Anhang D: Schritte zum Hinzufügen eines Attributs zu einem Attributsatz mit RODC-Filter
Search-Flags Attribute
|