Wer hat von meinem Tellerchen gegessen? Wer hat meine Datenbank geändert?

Update 17.12.2008: Verbesserte Anleitung und Erklärung zu USNs und Meta-Daten. 

Hallo Zusammen!

Ich bin hier ein neuer Blogger, mein Name ist Herbert und schreibe nun auch im Aktiven Verzeichnis Blog.

Heute geht es um Fragen, die sich wohl schon viele gestellt haben:

• Was replizieren meine DCs den ganzen Tag?
• Warum ist meine AD Datenbank in der letzten Woche um 300MB angewachsen?

Beide Probleme können so schwerwiegend sein, dass der Betrieb der Domain in Gefahr geraten kann. Einige Beispiele in diesem Bereich aus unserer Wissensdatenbank:

312403 Distributed Link Tracking on Windows-based domain controllers
https://support.microsoft.com/default.aspx?scid=kb;EN-US;312403

318774 Removing duplicate and unwanted proxy addresses in Exchange
https://support.microsoft.com/default.aspx?scid=kb;EN-US;318774

940262 The Active Directory database size increases unexpectedly because a Windows Server 2003-based DNS server inappropriately creates several SerialNo objects
https://support.microsoft.com/default.aspx?scid=kb;EN-US;940262

Die Frage lässt sich meistens damit beantworten, was sich in der letzten Zeit in der AD-Datenbank geändert hat. Active Directory weist jeder Änderung eine "Update Sequence Number" (USN) zu, die nächste Änderung bekommt die nächst höhere USN. Die USN ist spezifisch für diesen Domain Controller und wird für lokal ausgeführte ("originating") als auch replizierte Änderungen vergeben. Also wird eine USN auch für Änderung in einem Namenskontext im GC vergeben. Die USN ist ein 64 Bit Wert, der dürfte eine ganze Weile vorhalten.

Anhand dieser USN kann man nun die letzten Änderungen an der Datenbank identifizieren. Jeder Active Directory Server (auch ADAM und LDS) hat auf seinem RootDSE Objekt ein Attribut, das die letzte geschriebene USN anzeigt, highestCommittedUSN, hier aus der Ausgabe in LDP:

...

12> supportedLDAPPolicies: MaxPoolThreads; MaxDatagramRecv; MaxReceiveBuffer; InitRecvTimeout; MaxConnections; MaxConnIdleTime; MaxPageSize; MaxQueryDuration; MaxTempTableSize; MaxResultSetSize; MaxNotificationPerConn; MaxValRange;

1> highestCommittedUSN: 175389104;

4> supportedSASLMechanisms: GSSAPI; GSS-SPNEGO; EXTERNAL; DIGEST-MD5;

...

Basierend auf dieser Zahl kann man sich nun mit einer LDAP Query die letzten geänderten Objekte anzeigen lassen, zum Beispiel für die letzten 10000 Änderungen. Ich nehme hier LDIFDE:

Ldifde /d dc=contoso,dc=com /s contoso-DC1 /r "(usnchanged>=175379104)" /f domain-NC-last-10000-080919.txt

Die Datei enthält nun die geänderten Objekte. Man kann schon sehen, ob es bestimmte Schwerpunkte nach Objekten gibt. Wenn das Attribut "whenCreated" nicht darauf hinweist, dass die meisten Objekte neu sind, wird es nötig sein, zu den Objekten stichprobenartig die Replikations-Metadaten zu holen. Aus den geänderten Attributen ergeben sich weitere Erkenntnisse. Es kann zum Beispiel sein, dass eine Provisioning-Lösung ein Attribut mit immer den gleichen Werten überschreibt. Dann wächst die Datenbank nicht stark an, aber es gibt erhöhten Replikationsverkehr. Oder man sieht, dass die ganzen Änderungen gegen einen bestimmten Domain Controller stattfinden. Auch daraus können sich wichtige Erkenntnisse ergeben.

Die Meta-Daten kann man mit "repadmin /showobjmeta <DC Name> <Objekt-DN>" holen. Ein wichtiger Hinweis auf exzessive geänderte Attribute ergibt sich aus der Version und letztem Änderungsdatum:

Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute

======= =============== ========= ============= === =========

...

175389437 HQ\contoso-DC1 175389437 2008-09-16 18:12:46 2 name

...

Die Ausgabe zeigt die lokale USN ganz links. Rechts davon steht der Name, USN und Zeitstempel des Ursprungs der Änderung. Wenn die Version (hier "2") sehr hoch ist, deutet das auf exzessive Änderungen für das Attribut hin. Es kann durchaus sein, dass das Attribut in der aktuellen LDIF-Ausgabe fehlt, aber trotzdem einen aktuellen Zeitstempel hat. Es wird dann eventuell immer wieder gelöscht und wieder hinzu gefügt.

In den Replikations-Metadaten sollte man zusätzlich auch auf Link Values achten, die mit ABSENT und PRESENT markiert sind:

Type Attribute Last Mod Time Originating DC Loc.USN Org.USN Ver

======= ============ ============= ================= ======= ======= ===

Distinguished Name

=============================

ABSENT member 2008-09-19 15:14:01 HQ\contoso-DC1 175384020 175384020 2

CN=test-user1,OU=Test-OU,DC=contoso,DC=com

PRESENT member 2008-09-16 18:22:29 HQ\contoso-DC1 175379684 175379684 1

CN=test-user2,OU=Test-OU,DC=contoso,DC=com

Hinweis: Hohe USN-Werte verzerren die Tabelle Viele ABSENT Werte und/oder hohe Versionsnummern deuten auf hohe Aktivitäten bei verlinkten Attributen hin. ABSENT bedeutet, dass das Objekt einmal verlinkt war und nun funktioniert wie ein Tombstone bei Objekten. Es sorgt also bei der Replikation dafür, dass der Eintrag, hier aus der Mitgliedsliste einer Gruppe, entfernt wird.

Einen besonderen Fokus verdienen Attribute, die sehr viele Daten aufnehmen können. Das betrifft oft binäre Attribute, wie die Security Deskriptoren für Active Directory und Exchange Maiboxen, oder Attribute welche Zertifikate speichern. LDIFDE gibt jedoch per Default den ntSecurityDescriptor nicht aus. Wenn das Attribut in den Metadaten eine hohe Versionsnummer und aktuelles Änderungsdatum hat, kann man mit DSACLS den Inhalt ausgeben und auf Auffälligkeiten untersuchen. Meist enthält nämlich die discretionary ACL viele Einträge. Für ntSecurityDescriptor gibt es seit Windows Server 2003 einen single instance storage, die Datenbanken sind deswegen geschrumpft und meist ist dieses Attribut nicht mehr der Grund für den Datenbankzuwachs (wohl aber für erhöhten Replikationsverkehr).

Ausgehend von diesen Informationen kennt man den Problemverursacher schon, oder es ergeben sich Hinweise zur Applikation, die das Attribut verwendet. Als weiteren Schritt kann man Auditing auf die betroffenen Objekte und Attribute aktivieren, eventuell muss dazu das Attribut erst im ACL Editor sichtbar machen:

296490 How to modify the filtered properties of an object
https://support.microsoft.com/default.aspx?scid=kb;EN-US;296490

Was aber tun, wenn sich immer noch kein stimmiges Bild ergibt?

Eine Idee wäre, die Abfrage zu wiederholen und dabei die USN hochzuzählen, um die neuesten Änderungen zu sehen. Eventuell werden die problematischen Änderungen nur zu bestimmten Zeiten durchgeführt oder repliziert (zum Beispiel aus Zweigstellen, die nur alle paar Stunden einmal replizieren).

Es gibt vielleicht weitere Namenskontexte mit exzessiven Änderungen, wie Configuration oder die DNS Partitionen ForestDnsZones und DomainDnsZones, und natürlich bei GlobalCatalogs die anderen Domains des Forests. Es ist jedoch zu hoffen, dass den Admins dieser Domains diese exzessiven Änderungen schon aufgefallen sind. Im Global Catalog kann man so suchen:

Ldifde /d "" /s contoso-DC1 /t 3268 /r "(usnchanged>=175379104)" /f GC-last-10000-080919.txt

Hinweis: Nicht vergessen, dass man hier nur Änderungen zu Attributen sieht, die auch im Global Catalog präsent sind.

Und zuletzt gibt es noch die Möglichkeit, dass die geänderten Objekte unauffällig sind, das Problem sich aber in einer großen Anzahl bereits gelöschter Objekte manifestiert. Auch ein gelöschtes Objekt belegt noch Platz in der Datenbank für den "Grabstein", und ständiges Anlegen und Löschen von Objekten sorgt ebenfalls für Replikationsverkehr. Diese Objekte bekommt man angezeigt, wenn man LDIFDE den Parameter „/x“ mitgibt:

Ldifde /d dc=contoso,dc=com /s contoso-DC1 /x /r "(usnchanged>=175379104)" /f domain-NC-last-10000-deleted-080919.txt

Wenn die Größe der Datenbank zum Problem wird, muss man nach dem Löschen der Objekte die Tombstone Lifetime abwarten, bevor eine Offline Defragmentation Wirkung zeigt. Wir raten davon ab, die Tombstone Lifetime dafür zu verkürzen. Mit Replikations-Quarantäne und Strict Replication Mode handelt man sich bei kleineren Ausfällen schon Domain Controller ein, um die man sich kümmern muss.

Ich wünsche viel Spaß beim Untersuchen der AD Datenbank nach Änderungen. Ich bin schon gespannt, welche überraschenden Änderungen berichtet werden.

Comments

• Anonymous
  January 01, 2003
  The comment has been removed
• Anonymous
  November 24, 2010
  aus meinem tellerchen