Active Directory Stresstest mit „ADTest“

Autor: olc, MCSEboard.de

 

Ab und an kommt ein Active Directory Administrator in die Verlegenheit seine AD Umgebung oder auch nur einen bestimmten Domänencontroller einem Belastungstest zu unterziehen. Dies kann beispielsweise dann sinnvoll sein, wenn die Leistungsfähigkeit einer Hardware für bestimmte Anforderungen getestet werden soll, wenn man Fehler eingrenzen will, die nur unter Last auftreten, oder auch wenn man die internen Prozesse einer Active Directory Umgebung nachvollziehen möchte, um sie besser zu verstehen.

Für diese Zwecke bietet Microsoft das Tool „ADTest“ zum kostenlosen Download an [1]. Mittels ADTest kann man verschiedene Stresstests gegen einen DC oder seine Active Directory Umgebung fahren, dazu zählen beispielsweise:

  • LDAP Suchabfragen an die Active Directory Umgebung
  • Simulation von interaktiven Anmeldungen
  • Simulation von Batch-Anmeldungen
  • Hinzufügen von Attributwerten auf bestehende Objekte bzw. Veränderungen der Objekte

Weiterhin kann ADTest auch eigene Strukturen von OUs, Benutzern und Gruppen erzeugen, so daß z.B. in einer Testumgebung auch genügend Objekte zum Test bereitstehen. Diese Option sollte man natürlich in einer Produktionsumgebung nur mit Bedacht wählen…
Das automatisierte Anlegen der Objekte ermöglicht beispielsweise auch, die Replikation innerhalb einer Umgebung zu testen. Alles in allem kann ADTest also für viele verschiedene Test-Szenarien eingesetzt werden, dem Einfallsreichtum sind nur funktionelle Grenzen gesetzt. ;-)

Welche Tests möglich sind, verrät die ADTest Hilfedatei „adtest.mht“, die nach einer Standardinstallation von ADTest im Installationsverzeichnis „%PROGRAMFILES%\Windows Ressource Kits\Tools\“ zu finden ist. Die Hilfedatei ist ein sehr guter Startpunkt zum Einlesen in die Möglichkeiten von ADTest; es sind einige interessante Informationen darin zu finden.

Im den ersten Abschnitten der Hilfedatei finden sich einige Hinweise zur Anordnung von Testkomponenten (Clients, Server und Netzwerk), die man sich bestenfalls vor der Anwendung von ADTest einmal genau anschaut, um optimale Testergebnisse zu erreichen.

Die dann folgenden Abschnitte zur Vorbereitung der Testumgebung sollten jedoch nach Möglichkeit zwar gelesen, aber in der Ausführung „übersprungen“ werden – der Erfahrung nach geht beim Setzen der in der Hilfedatei genannten Einstellungen mehr kaputt als es Ergebnisse bringt. Im Normalfall klappt die Anwendung von ADTest bzw. deren Tests auch ohne die genannten Anpassungen der Umgebung, in dem man bei den Tests beispielsweise Benutzernamen und Kennwörter eines Benutzers mit Domänenadministrator-Rechten mit angibt. Ein paar Beispiele dazu folgen später in diesem HowTo.

Möchte man jedoch Benutzer anlegen, müssen einige der vorbereitenden Maßnahmen getroffen werden, so z.B. das Ändern der Default Domain Policy in Bezug auf die Kennwortrichtlinien. Da im Normalfall ADTest neue Benutzer ohne Kennwort anlegt, dürfen die Komplexitätseinstellungen für Kennwörter als auch die minimale Kennwortlänge nicht gesetzt sein. Führt man ADTest in einer Produktionsumgebung aus, in der keine Benutzer anzulegen sind, müssen diese Einstellungen nicht geändert werden.

HINWEIS: Das Ändern von Policies (GPOs) kann neben Funktionsstörungen auch schwerwiegende Sicherheitslücken aufreißen. Daher ist genau zu überlegen und ggf. auch genauestens zu notieren, welche Änderungen man für die Tests an der AD Umgebung gemacht hat.

Im Abschnitt „Loading AD with a Predefined Structure” der Hilfedatei werden dann einige Kommandozeilen angegeben, mit denen man seine Teststruktur in der Testumgebung anlagen kann. Möchte man Tests gegen seine Produktionsumgebung fahren, ist das nicht notwendig und je nach Anforderung auch nicht unbedingt zu empfehlen.

Die auf einem der Test DCs ausgeführte Kommandozeile:

C:\Programme\Windows Resource Kits\Tools>adtest –r newroot –root 0 –t 20 –sf –o C:\newroot.log –user Administrator –password Kennwort

legt beispielsweise eine neue OU-Teststruktur an. Der Parameter „-r newroot“ gibt an, daß der in der Datei „adtest.ats“ definierte Test „newroot“ ausgeführt werden soll.

Diese Test-Struktur wird mit den folgenden, oben aufgeführten Kommandozeilenparametern eingerichtet:

  • die OU-Nummerierung beginnt mit „0“ („-root 0“)
  • es werden 20 gleichzeitige Threads verwendet („-t 20“)
  • die Laufzeitdaten des Tests werden auf dem Bildschirm („-sf“) als auch in der Datei C:\newroot.log („-o C:\newroot.log“) ausgegeben

Abb. 1

Hat man, wie oben angesprochen, die vorbereitenden Maßnahmen nicht komplett durchgeführt (z.B. keinen ADTest Benutzer angelegt) ist es notwendig, Benutzername und Kennwort eines Benutzers mit in der Kommandozeile anzugeben, der die benötigten Rechte hat.

So muß zum Anlegen der OU-Struktur oder auch von Benutzern und Gruppen ein entsprechendes Recht delegiert sein. Am einfachsten ist es, einen Domänen-Admin Account zu nutzen  (sieht man einmal von etwaigen Sicherheitsbedenken ab…). Sollte das kein Problem darstellen, kann man mit den Parametern „user Administrator“ und „–password Kennwort“ den entsprechenden Benutzer und sei n Kennwort mit übergeben. Benutzername und Kennwort sind selbstverständlich anzupassen. ;-)

Nach dem Ausführen der oben angeführten Kommandozeile sieht die angelegte OU-Struktur beispielhaft wie im linken Beispiel (Abbildung 1) aus.

Abb. 2

Legt man nun beispielsweise Benutzer für die Struktur an, steigt die Systembelastung leicht auf 100%, wie auch schon bei der OU-Erstellung. Die zuständigen Prozesse für diese Aktion zeigen sich z.B. bei einem Blick in den Taskmanager (siehe Abbildung 2):

C:\Programme\Windows Resource Kits\Tools>adtest -r user -root 10 -t 20 -user Administrator -password Kennwort

Es können an dieser Stelle also schon Lastmessungen durchgeführt werden bzw. der Replikations- oder Netzwerktraffic überwacht werden.
Weitere Beispiele in der Hilfedatei zeigen das Ändern der Kennwörter der angelegten Testbenutzer oder auch das Hinzufügen der Testbenutzer in die angelegten Gruppen.

HINWEIS: Bei einigen Tests habe ich ab und an Probleme beim Anlegen von Benutzern festgestellt. Es wurden schlichtweg keine Benutzer angelegt, ein Capture mit ADInsight zeigte beim Versuch Benutzer anzulegen das Ergebnis „nResult – UNWILLING_TO_PERFORM“. Dies kann auf verschiedene Fehler hinweisen, unter anderem auf ein Problem mit dem Setzen von Kennwörtern.
Der Fehler konnte in all diesen Fällen mit dem Auskommentieren der beiden Zeilen:

  ATTR userPassword:$PassWord
  ATTR unicodePwd:$PassWord

aus der Datei “adtest.ats” innerhalb der Sektion „User.ats Section“ , Funktion “user”, behoben werden. Funktionelle Einschränkungen gab es danach keine, auch nicht beim nachträglichen Setzen von Kennwörtern über den Test „initpwd“.

Der nächste Schritt könnte das Anlegen von Gruppen oder das Zuweisen von Kennwörtern sein – je nach Anforderung sind diese Schritte notwendig oder auch nicht.

Im Anhang 2 der Hilfedatei „Appendix 2: Preconfigured Stress Tests“ finden sich diverse vorgefertigte Tests, die gegen eine Active Directory Umgebung gefahren werden können. Die Tests sind jedoch auch erweiterbar bzw. kann man auch neue Tests definieren, indem man die Datei „adtest.ats“ bearbeitet und ggf. modifiziert.

Möchte man in seiner Testumgebung oder aber in seiner Produktionsumgebung zum Beispiel einen Test fahren, wie sich die Systeme bei interaktiven Logons verhalten, kann folgende Kommandozeile genutzt werden:

C:\Programme\Windows Resource Kits\Tools>adtest -run inter -t 20 -user Administrator -password Kennwort

Eine Suchabfrage an die Active Directory kann etwa wie folgt aufgerufen werden:

C:\Programme\Windows Resource Kits\Tools>adtest -run L6 -t 20 user Administrator -password Kennwort

Die Tests können bei Bedarf über die Tastenkombination <CTRL> + <C> abgebrochen werden.

Weitere Parameter sind in der Hilfedatei aufgeführt. Ebenfalls finden sich einige Erklärungen zu dem Output, der durch ADTest generiert wird.

Möchte man diese Streßdaten auswerten, kann man verschiedene Wege gehen. Je nachdem, welchen Fokus man legen möchte oder muß, kann z.B. mit „Perfmon“ ein bestimmter oder mehrere NTDS Counter überprüft werden oder etwa CPU, RAM, HDD oder NIC überwacht werden.

Weiterhin bietet der „Server Performance Advisor“ (SPA), den Microsoft ebenfalls kostenlos zum Download anbietet [2], viele interessante und vor allen Dingen übersichtliche Auswertungsmöglichkeiten.

Führt man den Stresstest von einem Remote Client aus, kann man ggf. auch den Netzwerktraffic überwachen und auswerten, z.B. mit „Wireshark“ [3] oder dem „Netmon“ [4].

Wer Hardcore-Informationen zu internen Active Directory Prozessen während der Tests sucht, wird mit „ADInsight“ [5] fündig.

Alles in allem bietet einem Microsofts ADTest eine Menge Test-Möglichkeiten. Wofür man diese nutzt bzw. wie man die dabei anfallenden Daten auswertet, bleibt einem selbst überlassen. Gerade das macht dieses Tool zu einem interessanten Werkzeug, da man nicht auf festen Wegen Daten vorgelegt bekommt, sondern nur das Mittel zu Erzeugung dieser Daten in der Hand hält. Alles weitere bleibt einem selbst überlassen.

© MCSEboard.de, olc