Wie man einen Microsoft ADRAP überlebt

ADRAP ist die Abkürzung für das Microsoft Services Risk Assement Program for Active Directory. Es handelt sich dabei um eine formalisierte, eingehende Prüfung einer bestehenden Active Directory Umgebung durch Microsoft mit anschließender Beurteilung des “Gesundheitszustandes” des betreffenden ADs. Diese Prüfung (ehemals “AD Health Check” genannt) wird vom Microsoft Service als Dienstleistung angeboten.

Für die Prüfung kommt ein speziell für das ADRAP zertifizierter Microsoft Premier Field Engineer (PFE) vor Ort, sammelt mit speziellen Tools Daten aus der Umgebung (nur lesend), führt mit den zuständigen Administratoren eingehende Interviews über die Arbeitsweisen und Prozesse bezüglich AD und lässt sich auch allerhand an (hoffentlich vorhandener) internen Betriebshandbüchern, Desaster-Recovery-Merkblättern etc. zeigen. Je nach Größe der Umgebung kann das Ganze auch schon mal mehrere Tage dauern.

Abschließend bekommt man einen sehr ausführlichen offiziellen Bericht, aufgeteilt in einen technischen Teil, in dem die gefundenen Schwächen und deren mögliche Beseitigung genau erläutert werden, und einem Informationsteil, in dem sich das „gehobene Management“ über den Zustand des eigenen Active Directories informieren kann, ohne sich mit technischen Details belasten zu müssen 😉 Man kann sich das Ergebnis dann in Form eines Ampelsystems vorstellen, bei dem die Risiken in den einzelnen Unterbereichen in Grün/Orange/Rot beurteilt werden. Die Ergebnisse werden dann auch vom Microsoft Engineer in einem Management-Meeting erläutert.

Alles in allem bietet sich das ADRP also als wunderbares Instrument an, in dem der Administrator den vermeintlich guten Zustand seines eigenen AD “hochoffiziell” dokumentieren kann, sei es als IT-Dienstleister gegenüber seinem Auftraggeber, sei es als Projektverantwortlicher im Rahmen einer Abnahme/Übergabe an den Betrieb oder sei es einfach aus dem hehren Ziel heraus, das Betriebsrisiko des eigenen AD zu prüfen und dabei auch Probleme und Fehler beseitigen zu können. Sehr empfehlenswert, wobei auch nicht ganz billig …

Das Problem ist jedoch folgendes: Der Microsoft Field Engineer prüft mehrere tausend einzelne Punkte in der Konfiguration und dem Zustand der AD-Umgebung, entsprechend scharf fallen auch die Anforderungen an die gelebten Prozesse oder z.B. die Vorkehrungen zur Desaster Prevention / Desaster Recovery aus. Wenn für eine aus Microsoft-Sicht ideale AD-Umgebung 100% Punkte erreichen kann, so muss man selbst froh sein, wenn man mit dem eigenen AD im ADRAP vielleicht 70-80% erreicht. Das heißt dann aber immer noch, dass im Abschlussbericht ein, zwei Themenfelder auf Rot (-> High Risk!!) stehen. Zu dumm, wenn der Microsoft Experte dem eigenen Manager dann erklärt, in welch schlimmen Zustand er das AD vorgefunden hat!!

Ein High Risk fängt man sich z.B. ein, wenn zum Zeitpunkt der Prüfung ein Testaccount Mitglied in der Built-In Gruppe der „Server-Operatoren“ Mitglied war, dessen Passwort nicht abläuft („Mist, der sollte doch nur für die Migration von vor zwei Jahren da drin sein, hab ich vergessen…„) oder wenn man vergessen hat, in einem Windows 2003 AD die maximal mögliche Kerberos -Phasenkorrektur für die System Zeit einzuschränken („Ich hätte den Registry-Parameter „MaxPosPhaseCorrection“ auf 172,800 setzen sollen? Ach ja, wie konnte ich das nur übersehen, ähem…„). Und schwupp sitzt man zusammen mit dem eigenen Chef im Abschlussmeeting und starrt ungläubig auf die erste Folie einer liebevoll gestalteten Powerpoint-Presentation, die mit den Worten beginnt: “Das Active Directory unterliegt einem SEHR HOHEN BETRIEBSRISIKO”. Dabei ist “Sehr hoch” natürlich fett gedruckt und in rot. Na super.

Das Ding ist nämlich, dass selbst kleinste Fehler, deren Beseitigung eigentlich nur ein paar Sekunden in Anspruch nehmen würde, im Testbericht trotzdem als Risiko gewertet werden. Selbst wenn der Microsoft-Engineer tatsächlich den lokalen Administrator direkt dabei unterstützt und mit ihm zusammen den Fehler beseitigt: Der Fehler wird entsprechend im Abschlussbericht aufgeführt und fließt in die Bewertung ein. Die Premier Field Engineers haben hier klare Anweisung, sich nicht vom Bitten und Betteln des Administrators erweichen zu lassen (Nach dem Motto: „Ich korrigiere die Passwort-Richtlinien sofort. Können Sie nicht so tun, als hätten Sie die erst in fünf Minuten gecheckt???? BITTE!!!„). Keine Chance. Der ADRAP-Bericht ist unbarmherzig und unbestechlich. Jedenfalls soweit man das mitbekommt. Also hilft hier nur eins: Solide Vorbereitung auf den ADRAP-Prozess.

Nachdem ich nun mehrere ADRAP-Abläufe in verschiedenen AD-Umgebungen von 500 – 50.000 Benutzern miterlebt habe, versuche ich hier eine Auflistung, wie man sich gewissenhaft auf den ADRAP vorbereitet – und die Ampeln dabei auf grün bleiben 🙂

Vorbereitende Maßnahmen für ein gutes ADRAP-Ergebnis:

Update 15. Dezember 2010: Nach Hinweisen von Meinolf Weber haben wir unten ein paar Angaben aktualisiert.

• Die ADRAP-Tools benötigen eine dedizierte Maschine, von der aus die Daten gesammelt und Tests gefahren werden. Stellt bereits im Vorfeld sicher, dass diese Maschine zu ALLEN Domänencontrollern des gesamten Forests Verbindung aufnehmen kann. LDAP ist sicherlich erforderlich, ebenso RPC (die meisten der technischen Checks benötigen Remote WMI) und andere Ports. Falls die Verbindungen zu DCs gefiltert werden, sorgt Ihr am besten dafür, dass an den Firewalls für den Zeitraum des ADRAPs alle Ports zwischen Test-Station und allen DCs offen sind. Ist ein einziger DC nicht erreichbar, bedeutet dass ein High-Risk für den gesamten Test (=>das heißt z.B. auch, dass vor dem ADRAP alle evtl. vorhandenen DC-Leichen mit MetaData Cleanup zu beseitigen sind!).
• Nun zum gewöhnlichen Handwerkszeug. Selbstverständlich solltet Ihr in der Vorbereitung auf einen ADRAP dafür sorgen, dass ALLE Ereignisanzeigen auf DCs, die mit Active Directory etwas zu tun haben, keine Warnungen und Fehler aufweisen, und zwar am besten eine ganze Woche in die Vergangenheit hinein. Checkt Eure Systeme mit den üblichen Tools und sorgt dafür, dass dabei evtl. gefundene Probleme beseitigt sind, bevor der ADRAP startet:

Check für allerlei Domänencontroller-Funktionen:

DCDIAG /c

http://technet.microsoft.com/de-de/library/cc731968(WS.10).aspx

http://www.faq-o-matic.net/2006/08/14/domaenencontroller-mit-dcdiag-pruefen/

Trustverbindungen mit externen Domänen überprüfen:

NLTEST /DOMAIN_TRUSTS

http://blogs.technet.com/deds/archive/2008/11/25/nuetzliche-optionen-von-nltest.aspx

NETDOM trust TrustingDomainName /d:TrustedDomainName /verify

http://technet.microsoft.com/en-us/library/cc737447(WS.10).aspx

DNS überprüfen:

DNSLint /d DomainName /ad

http://support.microsoft.com/kb/321045/de

Replikationstopologie überpüfen:

REPADMIN /replsummary

REPADMIN /showrepl

REPADMIN /failcache

REPADMIN /removelingeringobjects

http://technet.microsoft.com/de-de/library/cc778305(WS.10).aspx

• Nicht dass man das extra erwähnen müsste: Alle Domänencontroller werden regelmäßig und zeitnah mit Updates versorgt, am besten innerhalb einer WSUS-Infrastruktur. Alle Domänencontroller müssen einem MBSA-Ablauf (Microsoft Baseline Security Analyzer) standhalten. Es sind Vorkehrungen getroffen, dass die Antivirus-Lösung auf allen DCs stets über die neuesten Pattern-Informationen verfügen. Das ist in Eurer Umgebung doch bestimmt der Fall, nicht wahr??!!

http://technet.microsoft.com/de-de/security/cc184923.aspx
Achtet darauf, dass ein entsprechend Virenchecker für den Betrieb auf DCs freigegeben und konfiguriert ist:

http://support.microsoft.com/kb/815263/en-us

http://support.microsoft.com/kb/822158/en-us

• Wer Domänencontroller unter Windows Server 2008 R2 betreibt, sollte auch mal den Active Directory Best Practice Analyzer anwerfen und sich um alle Probleme und Anregungen kümmern, die bei dieser Überprüfung zu Tage treten:
  
• Sorgt in folgenden technischen Bereichen dafür, dass es für den Field Engineer keinen Anlass zum Stirnrunzeln gibt:
  • Selbstverständlich müssen die Passwortrichtlinien aller Domänen des Forests mindestens den Standardeinstellungen von 2003 aufwärts entsprechen. Also keine leeren oder reversiblen Passwörter erlauben, sondern komplexe Passwörter fordern und eine ca. 6-wöchige Passwort-Ablaufzeit plus History.
  • Säubert vor dem ADRAP nochmals alle hoch privilegierten Gruppen: Enterprise Admins, Schema Admins, Domain Admins, Administratoren – aber auch Account Operators, Server Operators, Backup Operators, DNS Admins etc.)! Je weniger Mitglieder, desto besser. Die Schema Admins z.B. könnten ganz leer sein, wenn’S nach Microsoft geht. Es gibt keine feste Grenze, ab wann zu viele Mitglieder bei den anderen Gruppen hier als High Risk angesehen werden; die Beurteilung liegt im Ermessen des Microsoft Engineers.
  • Überprüft selbst, ob es Benutzerkonten gibt, für die das Passwort nicht abläuft oder die überhaupt kein Passwort benötigen. Am besten mit entsprechenden LDAP-Filtern:
    DSQUERY * dc=domaene,dc=de –filter „(&(sAMAccountType=805306368) (userAccountControl:1.2.840.113556.1.4.803:=65536)) „
    DSQUERY * dc=domaene,dc=de –filter „(&(sAMAccountType=805306368) (userAccountControl:1.2.840.113556.1.4.803:= 32)) “
    Es kann solche Benutzer schon geben, z.B. als Accounts für Dienste, allerdings darf keiner dieser Accounts in den hoch privilegierten Gruppen sein (siehe oben).
  • Alle Domänen-Controller-Objekte gehören in die OU „Domain Controllers“! Basta. Es ist sowieso generell keine so glorreiche Idee, irgendeines der vom System mitgelieferten User und Gruppen aus ihren Standard-Containern „BuiltIn“ und „Users“ zu verschieben.
  • Die Größe aller Event Logs auf den DCs darf 300 MB nicht überschreiten (verbraucht sonst zu viel RAM…).
  • Eure FSMO-Rolleninhaber (Schema Master, PDC Emulator etc.) sollten möglichst nicht auf virtualisierten Maschinen laufen (egal ob auf HyperV oder ESX). Falls im Forest irgendwelche DCs da sind, die als alte Gurken eigentlich völlig überlastet sind: Tauscht sie vor dem ADRAP gegen leistungsfähigere Hardware aus, wenn das geht. Auch eine erhöhte durchschnittliche Plattenlast von einigen DCs kann Euch ein „Medium Risk“ einbringen.
  • Alle PDC-Emulatoren (und NUR diese) müssen an eine externe Zeitquelle angeschlossen werden:
    W32TM /config /syncfromflags:manual /manualpeerlist: <SNTP-Server-Adress>
    (das alte Kommando „NET TIME /setsntp:…“ sollte man ab Windows Server 2003 nicht mehr verwenden)
  • Sorgt dafür, dass auf allen DCs die so genannte Strict Replication Consistency Option für die AD-Replikation aktiviert ist:
    REPADMIN /regkey <DC> +strict
    http://technet.microsoft.com/en-us/library/cc816938%28WS.10%29.aspx
  • Alle IP-Subnetze, aus denen sich Clients am Forest authentisieren, müssen als Subnet-Objekt in „AD Sites and Services“ angelegt sein. Hinweise auf fehlende Netzwerkbereiche findet ihr auf den DCs in der Logdatei %systemroot%\debug\netlogon.log.
  • Für alle DNS-Server auf Windows-Basis gilt: Die eigene IP-Adresse oder auch die Loopback-Adresse ist stes in der Liste der DNS-Server in den TCP/IP-Einstellungen enthalten, jedoch nicht an erster Stelle.
  • Für DNS-Zonen nur <Secure Dynamic Update> erlauben und den Zonentransfer nur an die Liste der Namensserver erlauben, und diese Liste auch pflegen.
  • Solltet Ihr tatsächlich noch eine WINS-Infrastruktur betreiben (tsts…), dann dürfen auf den WINS-Servern selbst die TCP/IP-Einstellungen nur die eigene Maschine als WINS-Server eingetragen haben.
• Nun zur Vorbereitung auf das Interview, die Überprüfung der Prozesse, die Sichtung der Dokumentation etc.:
  • Regelmäßige Backups sind ein Muss, und zwar mit Verfahren, die offiziell unterstützt werden (also kein Wegschreiben von Images mit Acronis usw. oder irgendwelche VMWare-Snaptshots von laufenden DCs!). Am meisten gefällt Microsoft tatsächlich die Idee eines DC-Systemstate-Backups auf die Festplatte, diese werden dann auf Band gesichert.
  • Ganz wichtig: Konzepte zu Desaster Prevention / Desaster Recovery speziell für Eure AD-Umgebung.
    http://download.microsoft.com/documents/australia/support/Active%20Directory%20Disaster%20Recovery%20Datasheet.doc
  • Wo wir schon bei Desaster Prevention sind: Wie steht’s mit theoretischen Betrachtungen zu Active Directory Security? Administrations- und Rollenkonzepte, Konzepte zu Auditing und physikalischer Sicherheit der DCs? Fragen über Fragen…:)
  • Alle Kernkomponenten des Active Directory müssen irgendeiner Art von Monitoring unterliegen. Ob ihr hier OpenView, MOM, Tivoli oder sonst was einsetzt, ist eigentlich egal – Hauptsache es gibt ein Monitoring für AD-Dienste, Replikation, Zeitsynchronität, FRS Replikation sowie für die Erreichbarkeit von Global Catalogs und FSMOs. Auch die Ausführung der Backup-Jobs muss überwacht werden, am besten auch die Performance-Leistung der DCs, um HW-Überlastungen identifizieren zu können.
  • Ihr braucht eine aussagekräftige Doku über Eure Umgebung, am besten ein Design-Konzept zum Domänen- und OU-Design, zu der zugrundeliegenden Netzwerk-Umgebung. Abgerundet durch eine offizielle Setup-Doku für einheitliche Domänencontroller-Konfigurationen. Teil der Designdoku sollten Analysen zum Business Impact Eurer AD sein, sozusagen damit das Management versteht, wie sehr eigentlich alles vom AD abhängt…
  • Toll wären auch Papiere zur Service Level Agreements, Strategieausarbeitung, inwiefern die AD-Infrastruktur die Business-Strategie Eures Unternehmens unterstützt und auch deren Weiterentwicklung unterstützt. Formale Methoden zur Messung der Service-Qualität und Roadmaps zur Weiterentwicklung des Services … all solche Sachen. Wenn Ihr für Eurer AD einen formalen ITIL-Betrieb nachweisen könnt: Umso besser!
  • Um strategische Weiterentwicklungen und Änderungen an Eurem AD planen und testen zu können, braucht man eine Test-Umgebung, in der die echte Umgebung abgebildet ist. Man muss ja nicht gleich zum technischen Streber werden und mit einer dreistufigen (Test->Referenz->Produktion) Umgebung aufwarten, aber ganz nackt darf man hier auch nicht dastehen.
• Auch interessant zur Orientierung: Microsoft stellt seit Mitte 2009 das so genannte ADRAP Scoping Tool zum Download zur Verfügung. Es überprüft die grundlegenden Voraussetzungen für die Durchführung des ADRAPS gibt einige Infos zum Ablauf der Prüfung und spuckt einen Mini-Report aus. Wahrscheinlich will Microsoft im Verlauf der offiziellen Vorbereitung zum ADRAP, dass Ihr das Scoping Tool ausführt und dan Report an Microsoft schickt. Man kann sich das Tool jedoch auch mal ganz unverbindlich anschauen:
  http://www.microsoft.com/DOWNLOADS/details.aspx?familyid=22205827-C164-4B62-9F8D-C3CD6077BD82&displaylang=en

So, hoffentlich hat Euch die Liste nicht abgeschreckt 🙂 Prinzipiell ist ein ADRAP ein sehr feine Sache und bestätigt offiziell den Wert Eurer Arbeit als AD-Administratoren – vorausgesetzt, Ihr macht Eure Umgebung entsprechend fit! Vielleicht ist der ein oder andere AD-Admin dadurch sogar motiviert worden, einfach mal so genauer hinzuschauen und seinen eigenen kleinen Privat-ADRAP durchzuspielen…