Die AD Datenbank NTDS.DIT waechst immer weiter wenn Credential Roaming aktiviert ist

Hallo hier ist mal wieder Andy, heute zum Thema Credential Roaming. Für die, die nicht wissen was Credential Romaing ist: Credential Roaming ist eine Active Directory und Group Policy Erweiterung zum Speichern von Zertifikaten und alles was mit dem  MyStore Speicher zu tun hat.

Wer sich schon mal mit dem Thema Credential Roaming https://technet.microsoft.com/de-de/library/cc773373(WS.10).aspx befasst hat weiß, dass er zuerst sein AD Schema anpassen muss.

Sobald Credential Roaming mit den Administrativen Vorlagen aktualisiert wird, siehe https://technet.microsoft.com/de-de/library/cc759556(WS.10).aspx , kann der Spass beginnen. Meldet sich ein Benutzer mit aktivierter Group Policy an, werden die Zertifikate im Active Directory gespeichert.

Was passiert beim Speichern der Zertifikatsschlüssel? Die Schlüssel liegen auf dem Client als Datei im Zertifikatsspeicher. Diese Dateien werden bei der Abmeldung in einem sogenannten BLOB (Binary Large OBject) im Active Directory gespeichert.

Um den Wildwuchs von Servergespeicherten Zertifikaten in den Griff zu bekommen, gibt es eine Administrative Vorlag die 3 wesentliche Einstellungen besitzt:

• Maximum tombstone credentials lifetime in days: Hiermit können Sie definieren, wie lange servergespeicherte Anmeldeinformationen für ein Zertifikat oder einen Schlüssel, das bzw. der lokal gelöscht wurde, in Active Directory verbleiben.
• Maximum number of roaming credentials per user: Hiermit können Sie die maximale Anzahl der Zertifikate und Schlüssel definieren, die mit servergespeicherten Anmeldeinformationen verwendet werden können.
• Maximum size (in bytes) of a roaming credential: Hiermit können Sie das Speichern von Anmeldeinformationen, die eine definierte Größe überschreiten, auf dem Server einschränken.

Referenz hierzu: https://technet.microsoft.com/de-de/library/cc759556(WS.10).aspx

Soweit so gut, eine Active Directory Datenbank NTDS wächst natürlich etwas, wenn plötzlich die Zertifikatsinformationen im Active Directory gespeichert werden. Je nach der Anzahl der Benutzer und der Einstellungen für Credential Roaming kann dieses “etwas mehr Platz” größer oder kleiner ausfallen. Nach einer gewissen Zeit, sollte sich der Wert jedoch einpendeln.

Wir beobachten aber immer wieder, dass die Active Directory Datenbank ständig wächst obwohl Credential Roaming schon eine Zeitlang aktiv war und sich das Wachstum der Datenbank hätte eigentlich einpendeln sollen.

Was ist passiert? Warum wächst die NTDS.DIT ständig weiter, ohne dass die Anwender ständige neue Zertifikate anfordern?
Wenn man sich die Zertifikate der Benutzer betrachtet haben die sich scheinbar sein Tagen/Wochen/Monaten nicht geändert?

Eine Untersuchung dieses Phänomens zeigt ein banales aber grundlegendes Problem. Hierzu müssen mach ich aber nochmal einen kurze Ausflug, was passiert bei Credential Roaming eigentlich?

Meldet sich ein Benutzer im Active Directory an, werden die Zertifikatsdaten aus dem Active Directory BLOB Objekt in das %UserProfile%\AppData\Roaming\Microsoft\SystemCertificates\My\Certificates kopiert.

Beim Abmelden vergleicht Windows ob sich die Schlüsseldateien im Zertifikatsstore geändert haben. Haben die Dateien in irgendeiner Art und Weise verändert, werden die aktualisierten Schlüsseldateien im Active Directory aktualisiert. Durch die Tombstone Funktion bleiben die bisherigen Schlüsseldateien jedoch im Active Directory erhalten (wenn jedoch als gelöscht markiert).

Ab hier beginnt der Alptraum eines jeden Active Directory Administrators. Ich habe bis jetzt mehrere Softwareprodukte (Desktop Programm, Virenscanner, etc.)  gefunden, die die Datei Informationen von den Schlüsseldateien verändern ohne die Inhalte der Dateien zu ändern. Manche Produkte verändern die Timestamps von Dateien.

Dies hat zur Folge wenn sich der Benutzer von dem System abmeldet, werden die Schlüsseldateien in Active Directory aktualisiert (und das obwohl sich an den Schlüsseln sich eigentlich nichts geändert hat außer dem Dateidatum).

Wie kann man als Admin rausfinden, welche Programm die Dateien verändert?
Ok - ich gebe zu, das ist einfacher gesagt als getan...

Im ersten Schritt versuchen wir mal rauszubekommen welche Benutzer betroffen sind. Hier möchte ich auf den Blog von Herbert verweisen „Wer hat von meinem Tellerchen gegessen…?“ https://blogs.technet.com/b/deds/archive/2008/09/30/wer-hat-von-meinem-tellerchen-gegessen-wer-hat-meine-datenbank-geaendert.aspx . Herbert beschreibt sehr gut, wie nachverfolgt werden kann wann welche Daten im AD aktualisiert worden sind.

Hier das Vorgehen für unsern Fall im Schnelldurchgang:

Mit dem Programm LDP.EXE eine Verbindung zum RootDSE herstellen und die höchste vergebene USN raussuchen (highest committedUSN):

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

In unserem Beispiel ist die highestCommitedUSN 175389104, jetzt können wir und mal die letzten 10.000 Änderungen ausgeben lassen. Das machen wir am besten mit:

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

Die Datei Domain-NC-last-1000-110220.txt enthält jetzt die letzten 10.000 Änderungen.  In dieser Datei die die letzten 10.000 Änderungen enthält, suchen die die Benutzerobjekte raus die sich geändert haben.

Jetzt muss festgestellt werden, was an den Benutzerobjekten zuletzt geändert wurde. Hierzu bemühen wir das Repadmin Tool:

repadmin /showobjmeta * “CN=MyUser,OU=Users, ,DC=contoso,DC=com”

In dieser Ausgabe suchen wir nach

ABSENT msPKIDPAPIMasterKeys …
PRESENT msPKIDPAPIMasterKeys …
ABSENT msPKIAccountCredentials …
PRESENT msPKIAccountCredentials…

Sind diese Daten vorhanden und mit einem relativ aktuellen Datum versehen, ist dies ein Kandidat, bei dem die Credential Roaming Daten verändert wurden. Der nächste Schritt ist herauszufinden an welcher Workstation hat sich der Benutzer zum angegebenen Zeitpunkt abgemeldet bei der diese Änderung in Active Directory geschrieben wurde.

In diesem Fall befragen wir entweder den Benutzer oder die Security Ereignisprotokolle der Domain Controller von welchen Maschinen aus der Logon im AD erfolgt ist. Nach dem wir eine List der Maschinen haben, an der sich der Benutzer interaktiv angemeldet hat, durchsuchen wir die Ereignisprotokolle nach der Abmeldung des Benutzers. Hier sollten wir auf einen passenden Zeitpunkt stoßen,  der mit unserer Repadmin Ausgabe übereinstimmt.

Im nächsten Schritt ist festzustellen ob es sich um eine gewünschte Aktualisierung handelt, weil der Benutzer ein neues Zertifikat angefordert hat oder ob es sich um unser Problem handelt. Hierzu überprüfen wir im Zertifikats Snap-In die installierten Zertifikate ob aktuelle Zertifikate installiert worden sind.

Alternativ um die Anwender nicht zu erschrecken, können wir auch den Repadmin Befehl am darauffolgenden Tag wiederholen. Sind aktuelle Zeitstempel in der Ausgabe vorhanden ist es einer unserer Kandidaten.

Handelt es sich bei der Änderung des Zertifikatsspeichers um eine gewollte Änderung, müssen wir wieder zu unserer Liste mit den letzten geänderten Active Directory Objekten zurück und mit dem nächsten Benutzer weiter machen.

Haben wir einen entsprechenden Kandidaten gefunden können wir mit der eigentliche Suche beginnen. Mit dem Process Monitor (https://technet.microsoft.com/de-de/sysinternals/bb896645 ) von  Mark Russinovich erstellen wir einen Filter  für das Profil Verzeichnis des Benutzers auf der Benutzer Workstation. Wenn wir Glück haben handelt es sich bei der Workstation um einen Terminal Server, andernfalls aktivieren wir das Bootlogging im Options Menu. Jetzt soll sich der Benutzer anmelden und möglichst „normal“ arbeiten.

Meldet sich der Benutzer ab, kontrollieren wir ob sich die Credential Roaming Attribute geändert haben. Ist dies nicht der Fall, hat der Anwender die Software nicht gestartet, es handelt sich um eine andere Workstation oder er hat eine bestimmte Funktion nicht ausgeführt. Es hilft alles nichts wir starten wieder einen ProcMon Trace und warten einen Arbeitstag ab.

Haben sich die Active Directory Daten geändert, sollten wir die Änderungen im ProcMon Trace ausfindig machen können und damit auch den Prozess der die Zertifikatsdateien geändert hat.

ProcMon Eintrag im Detail:

Leider ist der Prozess nicht zu vereinfachen, aber ich werde eine zukünftigen  Blog ein Script erstellen, das zumindest die ersten Schritte automatisiert. Aber leider habe ich noch keine Möglichkeit gefunden die ProcMon Analyse zu automatisieren.

Ich hoffe für jeden Administrator, dass er nicht in dieses Problem läuft, es ist leider ein Alptraum, da die Ursache schwer zu ermitteln ist.

Andy