​

Eine Geschichte, so alt wie die Zeit selbst...

Wenn ich das Zimmer meiner Jungs betrete, frage ich mich meistens, ob es hier einen nuklearen Anschlag gegeben hat. Die meisten Assets sind noch warm, vermutlich vom radioaktiven Zerfall. Bei dem Anblick wird mein Kern auch gleich ein wenig instabil. Mittlerweile steht mir dieselbe Enttäuschung ins Gesicht geschrieben, wenn man mich wieder mal zu einem neuen Active Directory Security Audit ruft. Die CIOs schauen mir in meine trüben Augen und versuchen mich davon zu überzeugen, dass es "eh nicht so schlimm" ist – genauso wie meine Kinder.

Jetzt mal ohne Witz. Ein Großteil aller ADs die ich bis jetzt begutachtet habe, waren schlecht organisiert, unordentlich, hatten viele verwaiste Objekte und waren generell auch sehr unsicher. Wenn man Business Applications genauso vernachlässigen würde wie Active Directory, wären sie schon seit Jahren nicht mehr benutzbar.

Aber warum ist das so?

Die Robustheit von Active Directory ist unübertroffen

Wenn wir ins Jahr 2000 zurückgehen, als Active Directory seine Anfänge hat, dann sehen wir nicht nur Plateauschuhe und die Backstreet Boys, sondern auch sehr viel instabile Software-Lösungen. Böse Zungen behaupten, dass Microsoft dem niemals entwachsen ist, aber mittlerweile machen sie da einen wirklich guten Job.

Damit Active Directory stabil läuft, braucht es nur zwei Windows Server, die als Domain Controller (DCs) installiert sind und ein halbwegs vernünftiges Netzwerk, das die beiden miteinander verbindet – nicht mehr und nicht weniger. Es funktioniert praktisch immer, egal, was man dem AD antut.

Was macht es so robust?

• Selbstständige Replikation zwischen den DCs
• Ab 2 DCs ist es hochverfügbar
• Hat eine kompakte Datenbank
• Ist sehr ressourcenschonend
• Nutzt Standard-Protokolle: SMB, DNS, LDAP, RPC, DFS, Kerberos
• Ist kompatibel mit allen gängigen Betriebssystemen

Woher kommt dann der Müll?

Hier sind ein paar Beispiele, die ich meistens als Ursache identifizieren konnte:

• Manuelle Änderungen durch Admins an Usern, Gruppen, Computern
• Veränderung des Umfelds (Anwendungen, Personal, Firmen-Struktur)
• Nicht vorhandene Cleanup-Prozesse
• Mangelhaftes Wissen und Erfahrung

Was für Auswirkungen habe ich dadurch?

Die Auswirkungen sind auf jeden Fall nicht nur kosmetischer Natur, sondern können das Business auch tatsächlich negativ beeinflussen. Hier sind ein paar Beispiele:

1) Security

• Vergessene und nicht deaktivierte Benutzer
• Übermäßig freizügige Berechtigungen
• Unbeabsichtigte Vergabe von Rechten

2) Compliance

• Kein durchgängiges Rechte und Rollen-Konzept
• Zentrale Audits sind nicht möglich
• Nicht gepflegte Verantwortlichkeiten

3) Change

• Erschwert Migrationen
• Behindert Automatisierung
• Vermehrte Downtime bei Umsystemen

4) Business

• Erhöhte Betriebskosten
• Steigernder Pflegebedarf bei Schnittstellen (Geschäftsprozesse)
• Kann eine Hürde bei M&A, oder Carve-Outs sein

Wie erkenne ich ein unaufgeräumtes AD?

Man merkt es am einfachsten an der Gleichmäßigkeit der Objekte und daran, dass die Namenskonventionen eingehalten werden. Zum Beispiel das Land bei den User-Attributen. Steht hier überall "DE", oder manchmal auch "Deutschland", "GER", oder auch nichts drinnen? Sind die Daten unterschiedlich, dann werden sie in der Regel nicht automatisiert gepflegt.

Die Struktur der Organizational Units, also die Ordner, in denen die Objekte aufbewahrt werden, ist auch sehr wichtig. Darauf kannst du Gruppenrichtlinien und Scripts anwenden. Wenn du sehr oft die Suche brauchst, um Server oder User zu finden, dann liegt viel im Argen. Klar, eine Stichwortsuche ist oft schneller als die Navigation durch die OUs, aber als Admin sollte man trotzdem wissen, wo sich welche Objekte befinden. Ich habe schon Architekturen gesehen, bei denen alles in einer einzigen OU war – über 30.000 Objekte. Es gab aber auch welche, bei denen die Server über hunderte OU-Bäume verstreut waren.

Was kann ich dagegen tun?

#1 Erkenntnis

Der erste Schritt ist die Erkenntnis, dass man vor einem Problem steht. Nicht etwa, um es philosophisch zu betrachten, sondern um Zeit, Budget und Ressourcen zu organisieren. Das ist ein wichtiger, aber auch schwieriger Schritt.

#2 Objekt-Verwaltung

Jetzt muss ich mir überlegen, wie ich meine Objekte am besten erstelle, verwalte und pflege. Ein Objekt im AD sollte genauso einem normalen Life-Cycle unterliegen, wie andere Assets. Es wird erstellt, verwaltet, deaktiviert und gelöscht.

Egal, wofür man sich entscheidet – eine Identity-Management-Lösung, ein Orchestrierungs-Tool oder nur ein paar PowerShell-Skripte, die am ITSM-Tool hängen – wichtig ist, dass jegliche Interaktion mit standardisierten Objekten automatisiert geschieht. Ich mache mich sonst vom Ordnungsempfinden einzelner Personen abhängig. Viele ADs in Firmen sind älter als 15-20 Jahre, sie überdauern also oft die Mitarbeiter, von denen sie administriert werden.

#3 Architektur-Planung

Wenn ich weiß, welche Tools meine Objekte verwalten, kann ich mich für eine Architektur entscheiden. Die wird im Wesentlichen durch die Firmenstruktur vorgegeben. Bin ich ein Unternehmen mit etlichen eigenständigen Gesellschaften oder nach Ländern oder Regionen organisiert, oder steuere ich alles aus der Zentrale? Das sind Faktoren, die ich bei meiner Architektur berücksichtigen muss.

Normalerweise empfehle ich einen Single-Domain-Forest statt mehrerer Domains. Das vereinfacht die Verwaltung der Objekte ungemein. Auch wenn ich mehrere Gesellschaften habe, kann ich die Berechtigungen genauso an andere Personen delegieren und muss aber nur eine einzige Domain schützen.

Es ist sehr wichtig, dass du die Architektur immer automatisiert erstellst. Wenn das Unternehmen in fünf Jahren in ein weiteres Land expandiert, ist es unmöglich alles identisch von Hand anzulegen.

#4 Single Source of Truth

Damit die Objekte auch in die automatisierte Umgebung passen, musst du manchmal auch die Quellen aufräumen. Wenn die Namen und Abteilungen aus der HR-Datenbank falsch geliefert werden, kannst du nicht erwarten, dass auch dein AD gepflegt ist.

Du solltest für jeden Objekt-Typ, also für interne/externe Mitarbeiter, Client-PCs, Laptops, Server und Service-Accounts, alle gemanagten Attribute in einer Liste dokumentieren. Dort erfasst du deine gewünschte Namenskonvention, die Quelle und wer dafür verantwortlich ist.

#5 Objekt-Bereinigung

Hier trennt sich die Spreu vom Weizen. Fang mit einzelnen, unwichtigen Attributen an und arbeite dich dann langsam zum Kern vor. Adressen, Kostenstellen, Manager, usw. Wenn du ein Attribut vollständig bereinigt hast, kannst du es bereits nur noch von deinem "Tool" beschreiben lassen.

Profi-Tipp 1: Wenn du mit unverbesserlichen und sturköpfigen Admins zu tun hast, die vielleicht sogar in anderen Ländern sitzen, kannst du ihnen auch die Berechtigung nur für dieses eine gemanagte Attribut entziehen. Verwende dazu die Einstellung "Deny: Write to Attribute xyz".

Profi-Tipp 2: Falls du das Problem hast, dass Admins Objekte immer noch manuell erstellen, nimm einfach ein unscheinbares und unbenutztes Attribut und lass von deinem "Tool" eine 0 reinschreiben. So siehst du gleich, welche AD-Objekte automatisch erstellt wurden und welche manuell.

Erwarte nicht, dass dieser Prozess schnell voran geht. Das kann durchaus ein paar Jahre dauern. Wichtig ist, dass du dranbleibst und nicht aufhörst.

#6 Architektur-Migration

Du kannst die Migration auch parallel zur Bereinigung machen. Du kannst bereinigte Objekte schon in die neue Architektur verschieben oder neue gleich dort erstellen.

Achtung!

Du hast vermutlich viele Schnittstellen, die aus deinem AD lesen, oder auch dahin schreiben können. Ich hatte schon Business-Applications, die ihre User anhand der OU berechtigt haben. Wenn du sie verschiebst, verlieren sie den Zugriff.

Außerdem können Scripts Abweichungen haben. Wenn du zum Beispiel die Abfrage "Gib mir alle Benutzer des Standortes Berlin" einsetzt, werden alle User in der alten OU "Berlin" abgefragt, aber die neue OU wird hier nicht berücksichtigt. Du solltest dazu deine AD-Admins interviewen und nachfragen, welche Schnittstellen sie kennen. Dann sprich mit den Verantwortlichen darüber. Es kann auch nicht schaden, eine Runde in den Fachbereichen zu drehen. HR liefert bestimmt die Namen der User, die Finanz eventuell die Kostenstellen und die IT die Servernamen.

Auch hier kann der Prozess mehrere Jahre dauern. Pass nur auf, dass es nicht zu einer Bürde wird. Es ist nämlich enorm viel Aufwand zwei Strukturen parallel zu betreiben und die Fehleranfälligkeit ist sehr hoch.

#7 Audit

Wenn du fertig bist, dann solltest du unbedingt ein komplettes externes Audit durchführen. Bei so einer Migration ist man immer betriebsblind und übersieht so einiges. Nutze auch die Gelegenheit und überprüfe auch die Security. Delegierte Berechtigungen auf OUs und Rechte auf einzelnen Objekten sind da ein heißer Tipp von mir.

Fazit

Aufräumen ist echt anstrengend, aber es lohnt sich. Nicht nur, dass der Papa, der Chef oder man selbst stolz sein kann, sondern auch um eine stabile und sichere Umgebung zu haben.

Anhaltende Ordnung kann man sich nicht kaufen, schon gar nicht im Active Directory, man muss sie sich selbst machen!

​