4 Interner Aufbau der ADDS-Datenbank

Transkript

1 4 Interner Aufbau der ADDS-Datenbank Die ADDS-Datenbankdatei ist als Datei ntds.dit (für directory information table ) im Dateisystem im Ordner %systemroot%\ntds zu finden: Diese Datei enthält hierarchisch angeordnet ADDS-Objekte. Man unterscheidet allerdings mehrere Bereiche innerhalb der ADDS-Datenbank, die einen eigenen Replikationsbereich haben. Diese Bereiche werden als ADDS-Partitionen oder ADDS- Namenskontexte bezeichnet. 4.1 ADDS-Partitionen (ADDS-Namenskontexte) Einen guten Überblick über die auf jedem DC verfügbaren ADDS-Partitionen erhält man mit dem Tool replmon. Dieses Tool ist Bestandteil der Windows Server 2003 R2 32 bit Support Tools und im Moment nicht in eigener Version für Windows Server 2008 verfügbar. Beispiel: srv02 ist DC für contoso.intern, aber kein GC Mag. Christian Zahler, August

2 Seit Windows 2000 stehen folgende Partitionen zur Verfügung: Windows Server 2008 R2: Active Directory Name der ADDS-Partition Domänenpartition (DC=contoso,DC=intern), auch Domänennamenskontext: In dieser Partition sind sämtliche Benutzer-, Computer- und Gruppenkonten der Domäne gespeichert, weiters Organisationseinheiten, Gruppenrichtliniencontainer, freigegebene Drucker und Ordner, AD-integrierte DNS- Zonen usw. Konfigurationspartition (CN=Configuration,DC=contoso,DC=intern): In dieser Partition sind alle Einstellungen gespeichert, die die Gesamtstruktur betreffen. Beispiel: Sortierungsreihenfolge für Benutzerkonten, Exchange- Konfiguration, alternative UPN-Suffixe usw. Schemapartition (CN=Schema,CN=Configuration,DC=contoso, DC=intern): In dieser Partition ist das ADDS-Schema enthalten. Das Schema besteht aus Klassen (Vorlagen für ADDS-Objekte) und Attributen. Replikation auf Alle DCs in der Domäne; schreibgeschütztes Teilreplikat auf alle GCs im Forest Alle DCs in der Gesamtstruktur Alle DCs in der Gesamtstruktur (beschreibbares Replikat nur auf dem Schemamaster) Mit Windows Server 2003 wurde das Konzept der Anwendungspartitionen (application partitions) eingeführt. Diese ADDS-Partitionen können für spezielle Serverdienste verwendet werden. Microsoft selbst verwendet Anwendungspartitionen zur Speicherung AD-integrierter DNS-Zonen: Name der ADDS-Partition DomainDNSZones (DC=DomainDNSZones,DC=contoso,DC=intern): In dieser Partition befinden sich DNS-Zonen, die domänenweite Bedeutung haben. ForestDNSZones (DC=ForestDNSZones,DC=contoso,DC=intern): In dieser Partition befinden sich DNS-Zonen, die gesamtstrukturweite Bedeutung haben. Replikation auf Alle DCs in der Domäne, die auch gleichzeitig DNS-Server sind Alle DCs in der Gesamtstruktur, die auch gleichzeitig DNS-Server sind Die Anzeige, welche ADDS-Partitionen auf einem bestimmten DC vorhanden sind, ist auch mit dem Befehlszeilentool dsget möglich (Hinweis: Teilreplikate eines GCs werden nicht angezeigt!): C:>dsget server "cn=srv02,cn=servers,cn=wien,cn=sites,cn=configuration,dc=contoso,dc=intern" -part DC=ForestDnsZones,DC=contoso,DC=intern DC=DomainDnsZones,DC=contoso,DC=intern CN=Schema,CN=Configuration,DC=contoso,DC=intern CN=Configuration,DC=contoso,DC=intern DC=contoso,DC=intern dsget war erfolgreich 4.2 ADDS-Replikation innerhalb eines Standorts Die ADDS-Replikation verwendet unterschiedliche Mechanismen, je nachdem, ob innerhalb desselben Standorts (Intra-Site-Replikation) oder standortübergreifend (Inter-Site-Replikation) repliziert werden soll. 90 Mag. Christian Zahler, August 2012

3 Eckdaten für Intra-Site-Replikation: Die zu replizierenden Daten werden nicht komprimiert. Als Protokoll wird RPC (Remote Procedure Call) verwendet. Store-and-Forward: Jeder Domänencontroller kommuniziert mit einer Untergruppe von Domänencontrollern, um Replikationsänderungen zu übertragen, anstatt dass ein Domänencontroller für die Kommunikation mit allen anderen Domänencontrollern verantwortlich ist, für die die Änderung erforderlich ist. Um die Menge des Replikationsverkehrs zu minimieren, erfolgt die Replikation auf Attributebene. Wenn also bei einem Benutzerkonto das Kennwort geändert wird, so wird nur das geänderte Kennwort repliziert. Jeder Replikationsvorgang stellt eine Reaktion auf eine Änderungsbenachrichtigung dar. Wird beispielsweise bei einem Benutzerkonto die Adresse geändert, so erfolgt diese Änderung zunächst nur auf einem Domänencontroller. Diese Änderung nennt man auch ursprüngliche Änderung. Dieser Domänencontroller benachrichtigt nach einer (änderbaren) Zeitspanne von 15 Sekunden den ersten eingetragenen Replikationspartner, nach jeweils 3 Sekunden dann die weiteren Replikationspartner. Dringende Replikation: Wenn eine Änderung an einem Attribut vorgenommen wird, das als sicherheitsrelevant eingestuft ist, benachrichtigt der Quelldomänencontroller die Replikationspartner sofort. Eine solche unverzügliche Benachrichtigung wird als dringende Replikation bezeichnet. Die Aufforderung zu einer solchen dringenden Replikation zwischen Domänencontrollern erfolgt beispielsweise, wenn ein Administrator die Kontosperrungsrichtlinie oder die Kennwortrichtlinien für eine Domäne ändert. Die Replikationspartner fordern auf Grund der erhaltenen Änderungsbenachrichtigung die ADDS- Änderungen beim ersten DC an, dieser sendet die erforderlichen Änderungen. Der Mechanismus entspricht einer Pull-Replikation. (Anmerkung: Push-Replikationen können nur mit speziellen Tools etwa replmon durchgeführt werden.) Unnötige Active Directory -Replikationen werden durch Update Sequence Numbers (USNs oder Aktualisierungssequenznummern) verhindert. Jeder Domänencontroller weist jedem geänderten Attribut und Objekt eine USN zu. USNs werden lokal auf jedem DC verwaltet und nicht repliziert. Jeder Domänencontroller zeichnet die USNs, die er von seinen Replikationspartnern erhält, in einer Tabelle auf. Diese Tabelle vergleicht die USNs, die der Domänencontroller für ein bestimmtes Objekt von seinen Replikationspartnern erhalten hat, und trägt den Unterschied als Aktualitätsvektor ein. Pro ADDS-Partition existiert ein Aktualitätsvektor (engl. Up-to-dateness vector), der mit einem speziellen repadmin-kommando angezeigt werden kann. Das folgende Beispiel gibt den Aktualitätsvektor für die Domänenpartition der Domäne contoso.intern aus. C:\>repadmin /showutdvec srv05 dc=contoso,dc=intern Caching GUIDs... USN Time :52:42 Wien\SRV05 USN Time :34:22 USN Time :17:30 USN Time :13:30 USN Time :52:58 USN Time :55:27 Wien\SRV05 USN Time :41:25 C:\>repadmin /showutdvec srv05 dc=contoso,dc=intern /nocache USN Time :52:42 USN Time :34:22 USN Time :17:30 USN Time :13:30 USN Time :55:35 USN Time :58:56 USN Time :41:25 Mag. Christian Zahler, August

4 Zusätzlich existiert eine Hochwassermarke (engl. High Water Mark) pro Replikationspartner. Diese Marke kann mit folgender Anweisung sichtbar gemacht werden: C:>repadmin /showreps /verbose Gmuend\SRV07 DC Options: IS_GC Site Options: (none) DC object GUID: 2df44c24-73ce-45c4-af2a-0a1d6fe39934 DC invocationid: 2df44c24-73ce-45c4-af2a-0a1d6fe39934 ==== INBOUND NEIGHBORS ====================================== DC=contoso,DC=intern Wien\SRV11 via RPC DC object GUID: edb7110a-2c bea0-f e4e Address: edb7110a-2c bea0-f e4e._msdcs.contoso.intern DC invocationid: 89a606f b8-aad2-5a DO_SCHEDULED_SYNCS WRITEABLE COMPRESS_CHANGES NO_CHANGE_NOTIFICATIONS USNs: 83230/OU, 83230/PU Last :22:59 was successful. Gmuend\SRV02 via RPC DC object GUID: e81ee8bb-15f7-4e08-b39b-f2008db23491 Address: e81ee8bb-15f7-4e08-b39b-f2008db23491._msdcs.contoso.intern DC invocationid: a4856e79-3f5a-4a d7891a53505 SYNC_ON_STARTUP DO_SCHEDULED_SYNCS WRITEABLE USNs: /OU, /PU Last :25:27 was successful. In den Zeilen, die mit USNs: beginnen, sieht man die High Water Mark als Zahl, die mit /OU gekennzeichnet ist. Wenn Domänencontroller A beispielsweise Informationen über ein neues Kennwort versendet, sind drei Elemente enthalten: das neue Kennwort, den Namen des Domänencontrollers und seine USN für das Attribut: <NeuesKennwort, DomänenControllerA, USN=4>. Beispiel: Domänencontroller B enthält eine Tabelle, die die USNs des Kennwortattributs von Domänencontroller A und C vergleicht. Diese Tabelle sieht wie folgt aus: Von USN Aktualitätsvektor Domänencontroller A 4 2 Domänencontroller C 2 1 Wenn Domänencontroller C eine Änderungsbenachrichtigung an Domänencontroller B sendet, enthält diese Benachrichtigung die USN = 2 von Domänencontroller C. Da Domänencontroller B für Domänencontroller C die USN = 1 führt, fordert der Domänencontroller alle Änderungen ab USN 1 an. Gleichzeitig mit dieser Anforderung sendet Domänencontroller B seinen Aktualitätsvektor an Domänencontroller C. Dieser beinhaltet die letzte Aktualisierung von Domänencontroller A. Auf diese Weise weiß Domänencontroller C, dass Domänencontroller B über die gleichen Informationen verfügt und sendet die geänderten Informationen nicht mehr. 4.3 Replikationskontrolle Die Replikation gehorcht grundsätzlich einem Multimaster-Modell. Der KCC (Knowledge Consistency Checker) berechnet die Replikationstopologie immer dann neu, wenn sich die Anzahl der DCs auf einem Standort ändert. Standardmäßig läuft der KCC alle 15 Minuten. Grundregeln: Es werden Replikationsringe gebildet. Ab drei DCs werden jedem DC vom KCC (mind.) zwei Replikationspartner zugewiesen. Jede Änderung muss innerhalb von drei Replikationszyklen alle betroffenen DCs erreicht haben. Ist dies mit der konfigurierten Topologie nicht möglich, fügt der KCC weitere Verbindungsobjekte hinzu. 92 Mag. Christian Zahler, August 2012

5 Die Replikation erfolgt zwischen Replikationspartnern. Partner werden erzeugt, indem vom KCC sogenannte Verbindungsobjekte erzeugt werden. Diese Verbindungobjekte sind im Snap-In Active Directory-Standorte und Dienste im Container NTDS Settings sichtbar: Jedes Verbindungsobjekt ist nur für bestimmte ADDS-Partitionen zuständig. Die Replikation kann auch manuell angestoßen werden: Auch mit dem replmon-tool kann die Replikation der einzelnen ADDS-Partitionen überwacht und gegebenenfalls angestoßen werden. Mag. Christian Zahler, August

6 Sollte eine Replikation nicht möglich sein, wird eine Fehlermeldung ausgegeben: Ein On-Board-Tool von Windows Server 2008 ist die Konsolenanwendung repadmin. Mit repadmin /syncall <Domänencontroller> <ADDS-Partition> kann eine sofortige Synchronisierung mit allen Replikationspartnern erreicht werden: C:\>repadmin /syncall srv05.contoso.intern DC=contoso,DC=intern Syncing partition: DC=contoso,DC=intern CALLBACK MESSAGE: The following replication is in progress: From: c4eb399b-771b-426b-b94d-00ab1993fd26._msdcs.contoso.intern To : 3ba a-4716-b48b-5a22a25b7c19._msdcs.contoso.intern CALLBACK MESSAGE: The following replication completed successfully: From: c4eb399b-771b-426b-b94d-00ab1993fd26._msdcs.contoso.intern To : 3ba a-4716-b48b-5a22a25b7c19._msdcs.contoso.intern CALLBACK MESSAGE: The following replication is in progress: From: 00b859c4-8aee-4c5a-a2c2-2fe b._msdcs.contoso.intern To : 3ba a-4716-b48b-5a22a25b7c19._msdcs.contoso.intern CALLBACK MESSAGE: The following replication completed successfully: From: 00b859c4-8aee-4c5a-a2c2-2fe b._msdcs.contoso.intern To : 3ba a-4716-b48b-5a22a25b7c19._msdcs.contoso.intern CALLBACK MESSAGE: SyncAll Finished. SyncAll terminated with no errors. Die Option /showrepl bietet einen Überblick über durchgeführte Replikationen: 94 Mag. Christian Zahler, August 2012

7 C:\>repadmin /showrepl repadmin running command /showrepl against server SRV10.contoso.intern Wien\SRV10 DC Options: IS_GC Site Options: (none) DC object GUID: a-a6b9-474f-b255-0d9794f184c5 DC invocationid: b122-4c93-802d-cc9f52dc2f47 ==== INBOUND NEIGHBORS ====================================== DC=contoso,DC=intern Last :05:31 was successful. Wien\SRV02 via RPC DC object GUID: e570535f-2a75-45bc-a9c5-dc597f5818e1 Last :06:50 was successful. CN=Configuration,DC=contoso,DC=intern Wien\SRV06 via RPC DC object GUID: 3b74c94c-f4f3-43fe-956c-41468f898ea7 Wien\SRV02 via RPC DC object GUID: e570535f-2a75-45bc-a9c5-dc597f5818e1 CN=Schema,CN=Configuration,DC=contoso,DC=intern Wien\SRV02 via RPC DC object GUID: e570535f-2a75-45bc-a9c5-dc597f5818e1 Wien\SRV06 via RPC DC object GUID: 3b74c94c-f4f3-43fe-956c-41468f898ea7 DC=DomainDnsZones,DC=contoso,DC=intern Wien\SRV02 via RPC DC object GUID: e570535f-2a75-45bc-a9c5-dc597f5818e1 DC=ForestDnsZones,DC=contoso,DC=intern Wien\SRV02 via RPC DC object GUID: e570535f-2a75-45bc-a9c5-dc597f5818e1 Last :51:37 was successful. Wien\SRV06 via RPC DC object GUID: 3b74c94c-f4f3-43fe-956c-41468f898ea7 Last :51:37 was successful. DC=fabrikam,DC=intern Last :56:24 was successful. Wien\SRV06 via RPC DC object GUID: 3b74c94c-f4f3-43fe-956c-41468f898ea7 Last :01:09 was successful. Mag. Christian Zahler, August

8 4.4 Replikation von Löschvorgängen Zu diesem Thema muss gesagt werden, dass gelöschte AD-Objekte nicht sofort komplett entfernt werden, sondern zunächst nur als gelöscht gekennzeichnet werden und eine bestimmte Zeit lang (Tombstone-Ablaufdauer) noch im AD gehalten werden, um eine Replikation des Löschvorgangs auf alle DCs in der Gesamtstruktur zu ermöglichen. Was passiert beim Löschen eines AD-Objekts im Detail? Das Objekt wird umbenannt und in einen Container Deleted Objects verschoben. Fast alle Attribute werden gelöscht, mit Ausnahme der GUID, der SID und einiger anderer wesentlicher Attribute. Dieser Vorgang wird Tombstoning genannt; aus dem ursprünglichen Objekt ist ein Tombstone geworden (wörtlich übersetzt: Grabstein ). Tombstone-Ablaufdauer in neuen AD-Gesamtstrukturen für verschiedene Server-Betriebssysteme: Betriebssystem Windows 2000 Server Windows Server 2003 RTM Windows Server 2003 SP1 Windows Server 2003 R2 Windows Server 2003 SP2 Windows Server 2008 Windows Server 2008 R2 Standard-Tombstone- Ablaufdauer 60 Tage 60 Tage 180 Tage 60 Tage 180 Tage 180 Tage 180 Tage Nach Ablauf dieser Zeitspanne werden die Objekte tatsächlich entfernt (durch den Garbage Collection-Prozess) und sind nicht mehr wiederherstellbar. Die Tombstone-Ablaufdauer kann mit ADSIEdit.msc konfiguriert werden: Bearbeiten Sie den Attributwert tombstonelifetime des Objekts CN=Directory Service und tragen Sie die Anzahl der Tage ein: In Windows Server 2008 R2 kann über das AD-Module für Windows PowerShell die Tombstone- Ablaufdauer wie folgt gesetzt werden: Set-ADObject -Identity CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=contoso,DC=com Partition CN=Configuration,DC=contoso,DC=com tombstonelifetime = 365} 96 Mag. Christian Zahler, August 2012

9 4.5 Replikationskonflikte Es gibt mehrere Arten von Replikationskonflikten, die in Active Directory-Infrastrukturen auftreten können: Attributkonflikte: Wenn dasselbe Attribut eines Objekts auf zwei Domänencontrollern gleichzeitig in verschiedener Art und Weise geändert wird, so entsteht ein Attributkonflikt. Dieser wird gelöst, indem der global eindeutige Stempel verglichen wird. Dieser Stempel enthält die Versionsnummer des geänderten Attributs, die GUID des Domänencontrollers, auf dem die ursprüngliche Änderung durchgeführt wurde, sowie einen Zeitstempel. Das Objekt mit der höheren Versionsnummer gewinnt. Sind die Nummern gleich, so wird das Objekt beibehalten, das den späteren Zeitstempel hat. Sind auch die Zeiteinträge gleich, so wird das Objekt beibehalten, das die numerisch höhere GUID des DCs hat. Attributkonflikte werden dadurch behoben, dass Replikationsmetadaten verglichen werden. Der folgende Befehl zeigt für jedes Attribut eines gegebenen Objekts die Metadaten an. Beachten Sie die Versionsnummer (Spalte Ver), die Bezeichnung des ursprünglichen DCs (Spalte Originating DC) und den Zeitstempel der ursprünglichen Änderung (Spalte Org. Time/Date). Mag. Christian Zahler, August

10 C:\>repadmin /showobjmeta srv07 "cn=haslinger Andreas,ou=Benutzer,OU=Gmuend,DC=contoso,DC=intern" 29 entries. Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute ======= =============== ========= ============= === ========= Wien\SRV :57:58 1 objectclass Gmuend\SRV :57:58 1 cn Wien\SRV :57:58 1 sn Wien\SRV :52:37 1 usercertificate Wien\SRV :57:58 1 givenname Wien\SRV :57:58 1 instancetype Wien\SRV :57:58 1 whencreated Wien\SRV :57:58 1 displayname Gmuend\SRV :28:00 2 ntsecuritydescriptor Wien\SRV :57:58 1 name Wien\SRV :57:58 4 useraccountcontrol Wien\SRV :57:58 1 codepage Wien\SRV :57:58 1 countrycode Wien\SRV :57:58 2 dbcspwd Wien\SRV :57:58 1 logonhours Wien\SRV :57:58 2 unicodepwd Wien\SRV :57:58 2 ntpwdhistory Wien\SRV :57:58 2 pwdlastset Wien\SRV :57:58 1 primarygroupid Wien\SRV :57:58 1 supplementalcredentials Wien\SRV :57:58 1 objectsid Gmuend\SRV :28:00 1 admincount Wien\SRV :57:58 1 accountexpires Wien\SRV :57:58 2 lmpwdhistory Wien\SRV :57:58 1 samaccountname Wien\SRV :57:58 1 samaccounttype Wien\SRV :01:42 2 userprincipalname Wien\SRV :57:58 1 objectcategory Gmuend\SRV :33:20 3 lastlogontimestamp 0 entries. Type Attribute Last Mod Time Originating DC Loc.USN Org.USN Ver Distinguished Name ======= ============ ============= ============== ======= ======= === ================== RDN-Konflikt 98 Mag. Christian Zahler, August 2012