Verzeichnisse ohne Plan? Warum Identitäten Strategie brauchen

Verzeichnisse ohne Plan?

Wer heute als Administrator:in in einer Microsoft-Umgebung arbeitet, trifft fast zwangsläufig auf gewachsene Verzeichnisstrukturen: Active Directory, hybride Szenarien, Entra ID. Was nach System klingt, ist oft das Ergebnis vieler Jahre technischer Evolution – oder auch: technischer Improvisation.

Junge Kolleg:innen, die neu in die Welt der Verzeichnisdienste eintauchen, übernehmen meist die Pflege und Verwaltung gewachsener Strukturen – ohne an deren Planung oder Einführung beteiligt gewesen zu sein.
Das Wissen über Entstehung, Aufbauprinzipien und strategische Hintergründe dieser Umgebungen ist häufig nur noch bruchstückhaft vorhanden. Vieles davon ist im Laufe der Jahre einfach verloren gegangen – und wurde seither kaum hinterfragt.
Die Haltung: „Es läuft – wir wissen nicht genau warum, aber ändern möchten wir daran lieber nichts“, ist dabei keine Seltenheit.

Das ist nicht nur aus historischer Perspektive bedauerlich, sondern wirkt sich heute konkret auf Koexistenz- und Migrationsszenarien aus:

• Warum ist der alte Domänencontroller eigentlich noch da?
• Wieso funktioniert die Gruppenrichtlinie nicht wie erwartet?
• Was genau repliziert Entra ID Connect eigentlich – und was nicht?
• Kann man GPOs nicht einfach in Intune übernehmen?

Fragen wie diese zeigen: Wer die historischen Grundlagen und den technischen Wandel von Microsofts Verzeichnisdiensten nicht kennt, läuft Gefahr, Fehlentscheidungen zu treffen – sei es bei der Anbindung von Cloud-Diensten, beim Umgestalten bestehender Umgebungen oder beim Delegieren von Rechten.

Dieser Beitrag soll daher nicht nur Wissen vermitteln, sondern Orientierung geben. Er führt durch die Geschichte von NT Directory Service, über die Einführung von Active Directory bis hin zu Entra ID – mit technischen Einblicken, strategischen Ausblicken und praktischen Empfehlungen für alle, die Microsofts Identitätsdienste heute verstehen und morgen gestalten wollen.

Was war vor NT 3.1? – Die Zeit vor dem Verzeichnis

Bevor Active Directory mit Windows 2000 den Standard für zentrale Verzeichnisdienste setzte, gab es in Microsoft-Netzwerken vor allem eines: keine zentrale Identität. Die frühen Jahre waren geprägt von Workgroup-Setups, lokalen Benutzerkonten und punktuellen Freigaben – jedes Gerät war für sich allein verantwortlich. Netzwerkadministration bedeutete: wiederholen, dokumentieren, kontrollieren – auf jedem einzelnen System.

MS-DOS, IBM und der Beginn von Microsofts Plattformstrategie

Microsofts Weg in die Unternehmensnetze begann weit vor Windows NT – nämlich mit der Lizenzierung und Weiterentwicklung von QDOS (Quick and Dirty Operating System), später als 86-DOS bekannt. Dieses Betriebssystem wurde 1981 von Microsoft erworben, weiterentwickelt und unter dem Namen MS-DOS zur Grundlage des IBM-PCs (PC-DOS 1.0). Die IBM-PC-Kompatibilität und das aggressive Lizenzmodell sorgten dafür, dass MS-DOS schnell zum De-facto-Standard wurde – trotz starker Konkurrenz wie CP/M-86.

Mit Windows 3.x folgte ab 1990 erstmals eine kommerziell erfolgreiche grafische Oberfläche. Sie setzte auf MS-DOS als Unterbau auf, war jedoch funktional begrenzt. Erst mit Windows NT bot Microsoft ein eigenständiges, netzwerkfähiges Betriebssystem, das auf Multitasking, NTFS, Rechtemodellen und einer durchdachten Architektur aufbaute.

IBM OS/2, Microsoft NT und der Mythos New Technology

Ursprünglich war Windows NT als Nachfolger von OS/2 2.0 gedacht – eingebettet in ein gemeinsames Entwicklungsprojekt von IBM und Microsoft, das 1985 initiiert wurde. Als sich die Wege beide Unternehmen aus Unstimmigkeiten trennten, setzte Microsoft ab 1990 die Arbeit eigenständig fort und veröffentlichte schließlich Windows NT 3.1 im Jahr 1993.

Die Versionsnummer 3.1 war dabei kein Zufall: Sie sollte die Verwandtschaft zur damals bereits erfolgreichen Windows-Version 3.1 signalisieren und zugleich den Eindruck erwecken, NT sei eine technisch gereifte Plattform – nicht bloß ein Neuanfang. Gleichzeitig distanzierte man sich damit elegant von IBMs OS/2 2.x-Linie.

Der Begriff NT wurde von Microsoft offiziell zunächst als New Technology kommuniziert – so z.B. in Marketingmaterialien und Produktvideos der frühen 1990er Jahre. Doch hinter der Bezeichnung steckt deutlich mehr als nur ein PR-Kürzel.

Die Ursprünge des Kürzels NT

Es existieren mehrere plausible Erklärungsansätze zur Namensherkunft:

• Technisch: Der ursprüngliche Zielprozessor für das System war der Intel i860, Codename N-Ten – daraus leitet sich das NT
• Entwicklungshistorisch: Das Projekt startete als NT OS/2, also als Weiterführung der OS/2-Linie unter neuer Architektur.
• Persönlich/ironisch: Ein verbreitetes Entwickler-Wortspiel bezieht sich auf VMS, das von Dave Cutler bei Digital Equipment Corporation (DEC) entworfen wurde. Der Witz: „WNT ist VMS + 1“ – V+1=W, M+1=N, S+1=T.

Cutler selbst war federführend bei der Entwicklung von VMS – und wurde später von Microsoft abgeworben, um eine robuste, skalierbare und sichere Betriebssystemarchitektur zu entwerfen. Viele Konzepte aus VMS fanden ihren Weg in Windows NT – darunter etwa der Objektmanager, der Schedulers-Ansatz oder der Kernel-Modus-Schutz.

In einem Q&A im Jahr 1998 sagte Bill Gates, das Akronym NT „habe früher einmal für ‚New Technology‘ gestanden“, trage heute aber keine konkrete Bedeutung mehr. Mit Windows 2000 verschwand der Begriff schrittweise aus der Produktbezeichnung – die technische Basis (NT-Kernel) blieb jedoch bis heute erhalten.

NT Directory Service – Das Fundament vor dem Verzeichnis

Mit Windows NT 3.1 führte Microsoft eine der ersten echten Unternehmensplattformen ein, die Netzwerkbetrieb, Sicherheit und Benutzerverwaltung in einem professionellen Betriebssystem vereinte. Der darin enthaltene NT Directory Service (häufig nur als NT-Domäne bezeichnet) war Microsofts erster Versuch, zentrale Identitäten in Netzwerken zu etablieren – ein großer Schritt im Vergleich zu den losen dezentralen Workgroup-Setups der MS-DOS-Zeit.

Das Konzept basierte auf einem klaren Rollenmodell:

• Primary Domain Controller (PDC): verwaltete alle Benutzerkonten und Gruppen zentral
• Backup Domain Controller (BDC): hielt eine schreibgeschützte Kopie aller Daten vor, übernahm ebenfalls Authentifizierungsfunktionen und konnte im Notfall die primäre Funktion übernehmen
• Security Account Manager (SAM): enthielt die lokale Kontodatenbank von Servern und Workstations, wurde jedoch nicht repliziert

Vorteile des NT-Domänenmodells

• Einfache Integration in Windows-Netzwerke durch NetBIOS
• Gruppenbasierte Rechtevergabe auf Ressourcen
• Unterstützung für Roaming Profiles und Logon Scripts
• Zentrale Anmeldung für Benutzer:innen im Netzwerk

Doch der Ansatz war von Anfang an begrenzt:

• Eingeschränkte Skalierbarkeit bei zunehmender Komplexität
• Kein echtes Verzeichnismodell: Die SAM war flach, nicht hierarchisch
• Kein LDAP, kein DNS-basiertes Konzept, kein Schemabegriff
• Keine Multi-Master-Replikation: Nur der PDC konnte Änderungen schreiben
• Replikation auf BDCs nur manuell oder zeitgesteuert

In größeren Netzwerken führte das schnell zu Verwaltungsaufwand, Redundanzproblemen und Sicherheitslücken. Dennoch bildete der NT Directory Service die Basis, auf der Microsoft später Active Directory entwickelte – mit denselben Zielen, aber auf einer deutlich robusteren technischen Grundlage.

Die Geburt von Active Directory – Architektur und Prinzipien

Mit der Veröffentlichung von Windows 2000 Server im Februar 2000 führte Microsoft das ein, worauf viele Administrator:innen jahrelang gewartet hatten: Active Directory Services (ADS; kurz: Active Directory, AD) – ein skalierbares, flexibles und verzeichnisbasiertes Identitätsmanagementsystem, das die Limitierungen des NT-Domänenmodells hinter sich ließ.

Der technologische Sprung war für die damalige Zeit immens:

• DNS-Integration: Namensauflösung wurde Bestandteil der Infrastruktur
• Flexible Rollenverteilung mit FSMO (Flexible Single Master Operations)
• Gruppenrichtlinienobjekte (GPOs): zentrale Verwaltung von Konfigurationen
• Hierarchische Objekte: Benutzer, Gruppen, Computer, Container, OUs
• LDAP-basiertes Verzeichnismodell: Strukturiert, durchsuchbar, standardisiert
• Multi-Master-Replikation: Jeder Domänencontroller konnte Änderungen entgegennehmen

Inspiration: Novell NetWare als Vorreiter

Es wäre jedoch einseitig, Active Directory nur als Weiterentwicklung des NT Directory Service zu betrachten. Tatsächlich spielte Novell NetWare eine entscheidende Rolle in Microsofts strategischer und technischer Ausrichtung.

Bereits in den 1990er Jahren hatte Novell mit dem NetWare Directory Services (NDS) ein echtes, X.500-inspiriertes Verzeichnisdienstsystem etabliert – mit verteilter Replikation, granularen Zugriffsrechten, Skalierbarkeit und einem klaren Objekthierarchiemodell. NDS war nicht nur technisch überlegen, sondern in vielen Großunternehmen weit verbreitet.

Microsoft erkannte früh, dass ein einfaches NT-Upgrade nicht reichen würde, um Novell in die Schranken zu weisen. Active Directory wurde daher strategisch als Antwort auf NDS entwickelt – mit vielen ähnlichen Konzepten, aber eingebettet in die Windows-Welt, mit besserer Integration in Clients und Administrationswerkzeuge wie die Microsoft Management Console (MMC).

Die erfolgreiche Einführung von Active Directory war damit nicht nur ein technologischer Fortschritt, sondern auch ein Wendepunkt im Wettbewerb: Während Novell an Marktanteilen verlor, setzte sich Microsofts Directory-Service-Ansatz zügig als Standard durch – auch weil Active Directory mit DNS, Kerberos und LDAP auf offene Standards setzte, ohne deren Komplexität unmittelbar auf die Administrator:innen abzuwälzen.

Entwurf einer klassischen AD-Infrastruktur

Mit der Einführung von Active Directory in Windows 2000 begann für viele Unternehmen der Aufbau einer dauerhaften, hierarchischen Verzeichnisstruktur, die in Teilen bis heute existiert. Dabei entstanden nicht nur technisch belastbare, sondern auch historisch gewachsene Konstruktionen – mit allen Chancen und Herausforderungen, die damit einhergehen.

Ein durchdachter Entwurf umfasst typischerweise folgende Komponenten:

Domänen und Gesamtstrukturen – Von NetBIOS zu DNS

In der NT-Welt existierten Domänen weitgehend isoliert nebeneinander. Sie trugen NetBIOS-Namen, hatten keinen funktionalen oder logischen Zusammenhang und konnten lediglich über manuell eingerichtete Vertrauensstellungen (Trusts) miteinander verbunden werden. So konnten beispielsweise Domänen mit den Namen FIRMA, SUB und CORP im gleichen Netzwerk existieren – ohne dass sich daraus ein strukturierter Zusammenhang ergab. Die Vertrauensstellungen stellten Beziehungen her, doch diese ergaben sich nicht aus der Namenskonstruktion, sondern mussten explizit definiert werden.

Mit der Einführung von Active Directory änderte sich dieses Bild grundlegend. Die Umstellung auf TCP/IP als Protokollbasis und die Verwendung von DNS-Namensräumen zur Domänenbenennung erlaubten es erstmals, logische Zusammenhänge direkt in der Namensgebung zu reflektieren.

Vom Namen zur Struktur

Nehmen wir das Beispiel der NT-Domänen FIRMA, SUB und CORP. Benennen wir diese im Active Directory stattdessen als:

• firma.de
• sub.firma.de
• corp.com

…so ergibt sich plötzlich eine logisch abbildbare Struktur: Die Domänen firma.de und sub.firma.de teilen sich denselben DNS-Namensstamm und lassen sich zu einer gemeinsamen Domänenstruktur (Tree) zusammenfassen. Diese Beziehung ist nicht nachträglich entstanden, sondern wurde bereits bei der Erstellung der übergeordneten Domäne firma.de konzeptionell angelegt.

Wichtig ist: Die Domäne sub.firma.de konnte nur im Bewusstsein der vorher existierenden Domäne firma.de erstellt werden. Das bedeutet: Die Struktur wächst von oben nach unten, nicht durch späteren Zusammenschluss. Man spricht in diesem Fall von einer hierarchischen Domänenstruktur, deren Stammdomäne firma.de ist.

Die Domäne corp.com hingegen passt nicht in den DNS-Namensraum firma.de – sie gehört zu einem eigenen Namensraum und kann daher nicht in dieselbe Domänenstruktur integriert werden. Wird corp.com dennoch im Kontext der bereits bestehenden Struktur bereitgestellt, entsteht eine neue, separate Domänenstruktur. Auch hier ist die Reihenfolge bedeutsam, in der der einzelnen Domänenstrukturen zur Gesamtstruktur hinzugefügt werden. Der Name der ersten Domänenstruktur definiert gleichsam auch den Namen der Gesamtstruktur.

In diesem Kontext ergibt sich eine Gesamtstruktur mit dem Namen ‚firma.de‘, die aus zwei Domänenstrukturen besteht:

• Die Domänenstruktur firma.de, bestehend aus der Stammdomäne firma.de und der untergeordneten Domäne sub.firma.de
• Die eigenständige Domänenstruktur corp.com, die ausschließlich aus ihrer Stammdomäne corp.com besteht

Entscheidend dabei: Die erste erstellte Domäne definiert nicht nur die Domänenstruktur, sondern auch den Namen der Gesamtstruktur. Die Architektur wächst sukzessive, von oben nach unten, nicht durch nachträgliche Verknüpfung.

Die Rolle der Gesamtstruktur (Forest)

Was in der Praxis oft als Forest bezeichnet wird, ist technisch betrachtet der Zusammenschluss mehrerer Domänenstrukturen, die ein gemeinsames Schema und einen globalen Katalog (Global Catalog, GC) teilen. Die erste erstellte Domäne definiert dabei nicht nur ihre eigene Domänenstruktur, sondern auch den Namen und Ursprung der Gesamtstruktur.

Die Installation des ersten Domänencontrollers legt also fest:

• die erste Domäne
• die zugehörige Domänenstruktur (Tree)
• und die Gesamtstruktur (Forest)

Alles, was danach folgt, ist Erweiterung:

• Weitere Domänencontroller erweitern die Domäne
• Weitere Domänen erweitern die Domänenstruktur
• Weitere Domänenstrukturen erweitern die Gesamtstruktur

Zusammengefasst:

Begriff	Bedeutung
Domäne	Administrative Sicherheitseinheit mit eigener Benutzerverwaltung
Domänenstruktur (Tree)	Hierarchische Sammlung von Domänen mit gemeinsamem DNS-Namensraum
Gesamtstruktur (Forest)	Sammlung mehrerer Domänenstrukturen mit gemeinsamem Schema und GC

Standorte und Replikation – Trennung von Logik und Physis

Während Active Directory auf Domänen-, Domänenstruktur- und Gesamtstrukturebene eine logische Ordnung der Identitäten und Ressourcen bietet, sieht die Realität in Netzwerken oft anders aus: Es gibt physische Standorte, getrennte IP-Subnetze und unterschiedliche Bandbreiten – Faktoren, die in der reinen logischen Struktur nicht abgebildet werden können.

Früher: Logik oder Physis – ein Kompromiss

In der NT-Domänenwelt existierte keine Trennung zwischen logischer und physischer Ordnung. Wer zwei geografisch getrennte Standorte hatte, stand oft vor einem Dilemma:

• Eine gemeinsame Domäne wäre organisatorisch sinnvoll – aber die Netzwerkverbindung war zu instabil oder langsam.
• Zwei Domänen hätten die Kommunikation entkoppelt – aber bedeuteten doppelten Verwaltungsaufwand und komplexe Vertrauensstellungen.

Viele Administrator:innen entschieden sich notgedrungen für mehrere NT-Domänen, obwohl sie fachlich nicht erforderlich gewesen wären. Die Domänenstruktur wurde also aus Netzwerktopologie-Gründen aufgeweicht, was zu Inkonsistenz und Mehraufwand führte.

Heute: Logik und Physis – mit Active Directory Standorten

Mit Active Directory wurde dieses Problem auf elegante Weise gelöst: Durch die Einführung von Standorten (Sites) lassen sich physische Netzwerkaspekte entkoppelt von der logischen AD-Struktur modellieren.

Ein Standort in Active Directory repräsentiert ein oder mehrere IP-Subnetze, die typischerweise einem physischen Standort zugeordnet sind (z.B. Rechenzentrum, Dortmund oder NRW). Durch diese Abbildung ergeben sich zahlreiche Vorteile:

• Abbildung realer Netzwerkverhältnisse innerhalb der logischen AD-Welt
• Definition von Standortverknüpfungen (Site Links) zur gezielten Steuerung von Datenflüssen
• Domänencontroller-Auswahl durch den Client basierend auf Standortzugehörigkeit
• Replikationssteuerung zwischen Standorten: Zeitpläne, bevorzugte Pfade, Bandbreitenoptimierung

Das bedeutet konkret: Es ist möglich – und ausdrücklich empfehlenswert – eine einzelne Domäne über mehrere Standorte hinweg zu betreiben, ohne die logische Struktur aufzugeben. Die Kommunikation zwischen den Domänencontrollern lässt sich dabei präzise steuern – über Zeitpläne, Standortverknüpfungen und Replikationskosten.

Und: Diese Architektur hat bedeutende Auswirkungen auf die Gesamtkomplexität.
Wer auf separate Domänen verzichtet, reduziert auch die Anzahl der Domänencontroller, Trusts und Verwaltungsgrenzen, die bereitgestellt, abgesichert und langfristig gepflegt werden müssen.

Replikation? Kommt noch.

Wie genau die Replikation zwischen Domänencontrollern im Active Directory funktioniert, wie der Knowledge Consistency Checker (KCC) arbeitet und wie man Standorttopologien optimiert, wird in einem separaten Abschnitt dieses Beitrags vertieft behandelt.

Für den Moment genügt: Standorte sind die Brücke zwischen physikalischem Netzwerk und logischer Verzeichnisstruktur – sie machen Active Directory skalierbar, effizient und netzwerkfreundlich.

Delegierung und Rollentrennung – Verantwortung gezielt steuern

Eine der großen Stärken von Active Directory liegt in der Fähigkeit, Verwaltungsaufgaben gezielt zu delegieren, ohne gleich die komplette Kontrolle abzugeben. Gerade in mittelgroßen bis großen Umgebungen ist das ein unverzichtbares Werkzeug, um skalierbare, sichere und wartbare Strukturen zu etablieren.

Trotzdem wird diese Möglichkeit in vielen Organisationen nur unzureichend genutzt – entweder aus Unsicherheit, wegen fehlender Konzepte oder weil „es ja irgendwie läuft“.

Warum Delegierung wichtig ist

Mit wachsender Größe einer IT-Umgebung steigt auch der Bedarf, bestimmte Aufgaben nicht zentral, sondern dezentral ausführen zu lassen – etwa:

• Aufnahme neuer Benutzer:innen durch die Personalabteilung
• Passwortzurücksetzung durch den Helpdesk
• Pflege von Gruppenmitgliedschaften durch Fachbereiche
• Verwaltung von Computerkonten durch lokale IT

Ohne Delegation muss all das durch die Domänen-Administration oder zentrale Administration erfolgen – was nicht nur ineffizient ist, sondern auch ein Sicherheitsrisiko darstellt.

Die Werkzeuge der Delegierung

Active Directory erlaubt eine präzise Steuerung von Berechtigungen auf OU-Ebene:

• Über den Delegation of Control Wizard in der Schnittstelle Active Directory Benutzer und Computer lassen sich typisierte Aufgaben delegieren
• Alternativ können über die erweiterten Sicherheitseinstellungen individuelle ACLs auf Objekte oder Container gesetzt werden
• Die Vererbung von Berechtigungen ermöglicht granulare Zugriffskontrolle mit minimalem Aufwand

Ein gutes Delegierungsmodell ist:

• funktional getrennt (z.B. Benutzerverwaltung ≠ Gruppensteuerung)
• rollenbasiert (nicht personenbezogen, sondern an Funktion gekoppelt)
• nachvollziehbar dokumentiert (wer darf was, wo, warum?)

Typische Fehler in der Praxis

1. Alles oder nichts: Helpdesk-Mitarbeitende erhalten domänenadministrative Rechte, „weil es einfacher ist“.
2. Keine Trennung von Benutzer:innen und Administration: Administrator:innen nutzen produktive Benutzerkonten zum Arbeiten.
3. Fehlende Kontrolle über Delegationen: Einmal eingerichtete Berechtigungen werden nie wieder überprüft.
4. OU-Design folgt keiner Rollentrennung: Wenn alle Benutzer:innen in einer OU liegen, ist selektive Rechtevergabe kaum möglich.

Rollentrennung auch in der Administration

Gute Delegierung ist ohne Rollentrennung nicht denkbar. Dazu gehören:

• Trennung von produktiver und administrativer Identität (z.B. Benutzerkonto vs. Administratives Konto)
• Aufteilung der Verwaltungsaufgaben (z.B. GPO-Verwaltung ≠ Benutzerverwaltung ≠ Serververwaltung)
• Einsatz von Schutzmechanismen wie Protected Users, Admin Tiering und PAW (Privileged Access Workstations)

Diese Grundprinzipien sind nicht nur Best Practices – sie werden zunehmend von Sicherheitsstandards und Compliance-Vorgaben gefordert (z.B. BSI IT-Grundschutz, NIS2, ISO 27001).

Administrative Werkzeuge – von der MMC zur webbasierten Steuerung

Mit dem Wachstum von Active Directory wuchs auch der Werkzeugkasten, um es zu verwalten. Die administrativen Schnittstellen haben sich dabei stetig weiterentwickelt – von klassischen MMC-Snap-Ins bis hin zu modernen, webbasierten Verwaltungsportalen. Ein chronologischer Überblick zeigt, wie sich Funktionalität und Bedienbarkeit verbessert haben:

Ab Windows 2000

• Active Directory Benutzer und Computer (dsa.msc)
  Zentrale MMC-Konsole für Benutzer-, Gruppen- und Objektverwaltung.
• Active Directory Standorte und Dienste
  Verwaltung von Standorten, Subnetzen und Replikationstopologien.
• Active Directory Domänen und Vertrauensstellungen
  Einrichtung und Pflege von Domänenbeziehungen und Trusts.

Diese Werkzeuge bildeten das Grundgerüst der AD-Verwaltung – funktional, aber teilweise sperrig in der Bedienung.

Ab Windows Server 2003

• Gruppenrichtlinienverwaltungs-Konsole (GPMC)
  Endlich: eine zentrale Oberfläche zur Erstellung, Verknüpfung und Verwaltung von GPOs. Die vorherige GPO-Verwaltung unter Windows 2000 – eingebettet in Active Directory Benutzer und Computer – war fragmentiert und wenig intuitiv.

Ab Windows Server 2008 R2

• Windows PowerShell mit Active Directory Modul
  Mächtige Kommandozeilensteuerung für Automatisierung, Massenoperationen und Scripting. Zuvor standen nur eingeschränkte Kommandozeilentools (z.B. dsadd, dsmod) an der Eingabeaufforderung zur Verfügung.

Ab Windows Server 2012

• Active Directory Verwaltungscenter (ADAC)
  GUI mit modernerem Design, verbesserter Aufgabensteuerung, dynamischen Filtern und Integration von Granularen Kennwortrichtlinien sowie der Active Directory Papierkorb.

Modern

• Windows Admin Center (WAC)
  Webbasierte Verwaltungsoberfläche für hybride Infrastrukturen.
  Unterstützt zentrale Verwaltung von AD-Diensten, DNS, DHCP, Dateiservern und Azure-Anbindung. Ideal für Cloud-nahe Szenarien und rollenbasierte Administration.

Erweiterte Werkzeuge

• ADSI Edit
  Direkter Zugriff auf das AD-Schema – mächtig, aber risikobehaftet.
• LDP.exe
  LDAP-Explorer zur Analyse und Fehlerdiagnose auf Protokollebene.
• Repadmin, DCDiag, Netdom
  CLI-Werkzeuge zur Replikationsanalyse, Diagnose und Domänensteuerung.

Ein Werkzeugkasten, kein Ersatzkoffer

Trotz aller Fortschritte und Modernisierungen gilt: Kein einzelnes Tool deckt heute alle Verwaltungsszenarien vollständig ab. Viele Funktionen sind nur über bestimmte Oberflächen zugänglich – etwa:

• erweiterte Gruppenrichtlinienverknüpfungen in der GPMC
• hybride Authentifizierungsflüsse via Entra ID Connect oder Entra Admin Center
• moderne Geräteverwaltung über das Intune-Portal
• Schemaänderungen über ADSI Edit

In der Praxis bedeutet das:
Der administrative Alltag ist ein Mix. Zwischen MMC und Webportal, zwischen PowerShell und GUI, zwischen On-Prem und Cloud – und oft auch zwischen alt und neu.

DNS und Active Directory – Warum Namensauflösung das Fundament ist

Active Directory ist kein Insel-System – es ist ein verzeichnisbasierter Dienst, der vollständig auf DNS-Namensauflösung angewiesen ist. Ohne korrekt konfiguriertes DNS kann kein Client einen Domänencontroller finden, keine Anmeldung erfolgen und keine Replikation funktionieren. DNS ist im Active Directory also nicht optional, sondern Voraussetzung.

Der Grundsatz: Kein AD ohne DNS

Jede AD-Domäne ist zugleich ein DNS-Namensraum. Wird z.B. die Domäne firma.de eingerichtet, so entstehen entsprechende DNS-Zonen wie:

• firma.de (Primärzone für Ressourcen und Hostnamen)
• _msdcs.firma.de (Service-Locator-Zone mit SRV-Einträgen)

Wenn ein Client aus der Domäne sub.firma.de einen Domänencontroller sucht, stellt er DNS-Anfragen wie:

_ldap._tcp.dc._msdcs.sub.firma.de → Antwort: DC03.sub.firma.de

Fehlen diese SRV-Records, weiß der Client schlicht nicht, wohin er sich wenden muss – weder für Authentifizierung noch für Gruppenrichtlinien oder Replikation.

Interner DNS auf Domänencontrollern – keine Kür, sondern Pflicht

Ein häufiger Fehler in Praxisumgebungen: Clients oder sogar Domänencontroller verwenden externe DNS-Server wie 8.8.8.8 oder 1.1.1.1 – in der Annahme, dies würde „schneller funktionieren“. In Wirklichkeit unterbrechen solche Konstellationen die interne Namensauflösung. Ergebnis: Die Domäne firma.de funktioniert nicht zuverlässig, weil DNS-Abfragen nicht korrekt aufgelöst werden können.

Microsoft empfiehlt daher:

• Alle Clients verweisen ausschließlich auf interne DNS-Server
• Die DCs tragen sich selbst als DNS-Server ein (z.B. 127.0.0.1)
• Die Zonen (z.B. firma.de, sub.firma.de) werden AD-integriert repliziert
• Jeder Domänencontroller betreibt gleichzeitig einen DNS-Server
• Weiterleitungen ins Internet erfolgen gezielt über DNS-Forwarder

Nur so können Clients aus corp.com Domänencontroller in firma.de oder sub.firma.de finden – sofern entsprechende Trusts und Delegierungen eingerichtet sind.

Besonderheiten in Domänenstrukturen

Angenommen, in einer AD-Umgebung existieren:

• firma.de als Stammdomäne
• sub.firma.de als untergeordnete Domäne
• corp.com als eigenständige Domänenstruktur in einem separaten Forest

Dann müssen DNS-Zonen korrekt gepflegt und ggf. Zonendelegierungen zwischen firma.de und sub.firma.de eingerichtet sein. Für die Kommunikation zwischen corp.com und firma.de ist zusätzlich Zonenweiterleitung oder Bedingte Weiterleitung nötig – abhängig vom Vertrauensmodell zwischen den Forests.

Fazit

Active Directory ohne korrekt konfiguriertes DNS ist wie ein GPS-System ohne Satellitenempfang: Die Technik ist da, aber sie weiß nicht, wohin sie soll.
Deshalb gilt: Wer eine Domäne erfolgreich betreiben möchte, sollte DNS nicht als Nebensache betrachten, sondern als das, was es im AD ist: Die Grundlage von allem.

Die Cloud kommt – Von Azure AD zu Entra ID

Mit der zunehmenden Verlagerung von Anwendungen und Infrastruktur in die Cloud veränderte sich auch die Art und Weise, wie Identitäten verwaltet werden. Microsoft erkannte früh, dass die klassische Domänenstruktur an ihre Grenzen stößt – insbesondere bei mobilen Nutzer:innen, standortunabhängigen Diensten und externen Kommunikationsverbindungen.

Der Ursprung: Business Productivity Online Suite (BPOS)

Bevor Microsoft 2011 Office 365 einführte, bot es ab 2008 mit der Business Productivity Online Suite (BPOS) erstmals zentrale Standarddienste aus der Cloud an:

• Exchange Online
• SharePoint Online
• Office Communications Online (später Lync, heute Microsoft Teams)
• Live Meeting

Die Identitäten wurden in einem separaten, Microsoft-gehosteten Verzeichnisdienst verwaltet – nicht im lokalen Active Directory. Schnell wurde klar: Es braucht einen eigenen, Cloud-nativen Identitätsdienst, der unabhängig von On-Premise-Strukturen funktioniert, aber auch mit ihnen verbunden werden kann.

Aus diesem Ansatz entstand Azure Active Directory (Azure AD) – später umbenannt in Microsoft Entra ID.

Architekturunterschiede: Kein AD in der Cloud

Ein häufiges Missverständnis: Azure AD sei einfach Active Directory aus der Cloud. Tatsächlich sind die technischen Grundlagen fundamental verschieden:

Merkmal	Active Directory (AD)	Entra ID (vormals Azure AD)
Protokollbasis	LDAP, Kerberos	OAuth 2.0, OpenID Connect, SAML
Startjahr	1999/2000 (Windows 2000 Server)	2010 (öffentlich verfügbar)
Steuerung von Clients	GPOs, Login Scripts, Logon Server	Conditional Access, Intune, MDM
Technologie-Ursprung	NT-Entwicklung / LDAP/Kerberos	BPOS / Webtechnologien (OAuth/SAML)
Verzeichnisstruktur	Hierarchisch mit OUs und Gruppen	Flach, attributgesteuert
Zielarchitektur	Unternehmensnetzwerke, On-Prem	Cloud-native, global, föderiert

Azure AD (heute Entra ID) war also von Anfang an ein anderes System, mit anderen Anforderungen und Funktionen – ein Dienst, der aus Cloudszenarien heraus konzipiert wurde, nicht aus der klassischen Windows-Serverwelt heraus.

Funktionen und Fokus von Entra ID

Entra ID ist heute der zentrale Identitäts-Backbone für Microsoft 365 und zahlreiche Drittanbieter-Clouds. Im Leistungsumfang:

• Conditional Access und Risk-Based Policies
• Multi-Faktor-Authentifizierung (MFA) und passwortlose Anmeldung
• Plattformunabhängigkeit (auch für macOS, Android, iOS, Linux)
• Single Sign-On (SSO) für tausende SaaS-Apps

Aber: Entra ID ersetzt kein klassisches AD – zumindest nicht in traditionellen Netzwerken. Es ergänzt die lokale Welt – und übernimmt dort die Aufgaben, wo klassische Mechanismen (z.B. GPOs oder LDAP) nicht mehr greifen.

Hinweis: Viele der erweiterten Sicherheits- und Governance-Funktionen (z.B. Conditional Access, Identity Protection, Access Reviews) sind lizenzpflichtig und erst ab den Lizenzstufen P1 oder P2 verfügbar.

Hybride Szenarien – Wenn On-Premise und Cloud kooperieren

Die Realität vieler Unternehmen ist heute nicht entweder oder, sondern sowohl als auch: Active Directory bleibt für viele interne Prozesse unverzichtbar – etwa für lokale File- und Print-Services, klassische Anwendungen oder Geräteanmeldung. Gleichzeitig werden Cloud-Dienste wie Microsoft 365, Azure-basierte Applikationen oder Webdienste von Drittanbietern genutzt. Die Identität der Benutzer:innen muss deshalb übergreifend funktionieren.

Entra ID Connect – die Brücke zwischen zwei Welten

Microsoft stellt mit Entra ID Connect (vormals Azure AD Connect) ein zentrales Werkzeug bereit, um lokale Identitäten aus dem Active Directory mit der Cloud zu synchronisieren. Typischerweise werden folgende Elemente übertragen:

• Benutzer
• Gruppen
• Kontakte
• Attribute wie Telefonnummer, Position, Abteilung
• Optional: Passwort-Hashes zur Cloud-Anmeldung

Der lokale AD-Benutzer ‚Max Mustermann‘ wird damit im Entra ID-Mandanten sichtbar – mit einer synchronisierten Cloud-Identität.

Hinweis: Standardmäßig findet keine bidirektionale Synchronisation statt.
Änderungen in der Cloud wirken nicht zurück ins lokale Active Directory.

Authentifizierungsmodelle in hybriden Szenarien

Entra ID Connect ist nur ein Baustein – entscheidend ist, wo und wie sich Benutzer:innen authentifizieren:

Modell	Beschreibung
Federation (AD FS)	Anfragen werden an AD FS weitergeleitet, z.B. via SAML; benötigt eigene Serverinfrastruktur
Pass-through Authentication (PTA)	Benutzer meldet sich in der Cloud an, Authentifizierung erfolgt On-Premise
Password Hash Sync (PHS)	Lokale Passwörter (als Hash) werden sicher in die Cloud synchronisiert

PHS ist in der Praxis am einfachsten umzusetzen und genügt in vielen Fällen – auch mit MFA und Conditional Access kombinierbar.

PTA eignet sich für Unternehmen, die Passwörter nicht in die Cloud übertragen wollen.

AD FS gilt heute als Legacy-Ansatz und wird zunehmend abgelöst – v.a. durch Conditional Access Policies und moderne Authentifizierungsmethoden.

Herausforderungen in hybriden Umgebungen

Hybride Modelle bieten Flexibilität, erfordern aber klare Architekturüberlegungen:

• Benutzer:innen erwarten SSO – unabhängig vom System, Gerät oder Standort
• Administrationsgrenzen müssen neu gedacht werden – z.B. wer verwaltet welche Gruppe: On-Prem oder Cloud?
• Schatten-IT kann entstehen, wenn Benutzer:innen cloudbasierte Self-Service-Portale nutzen, ohne Rückbindung ans AD
• Sicherheitskonzepte müssen identitätsbasiert gedacht werden (z.B. Zero Trust)

Microsoft spricht in diesem Zusammenhang oft vom Identitätsparadoxon:
Je mehr Kontrolle man durch zentrale Identitäten gewinnt, desto größer wird die Herausforderung, diese sicher, konsistent und nachvollziehbar über Systemgrenzen hinweg zu verwalten.

Cloud Sync – die schlanke Alternative?

Neben Entra ID Connect bietet Microsoft mit Entra Cloud Sync eine cloudbasierte Synchronisationslösung an, die insbesondere für moderne, leichtgewichtige oder mehrere Gesamtstrukturen umfassende Szenarien geeignet ist. Cloud Sync benötigt keine lokale SQL-Datenbank und wird über Microsoft automatisiert verwaltet. Microsoft empfiehlt Cloud Sync vor allem dann, wenn keine komplexen Writeback-Funktionen (z.B. Passwortzurückschreibung) oder Exchange-Hybrid-Konfigurationen erforderlich sind.

Cloud Sync nutzt einen Entra ID Provisioning Agent, der im Gegensatz zu Entra ID Connect leichtgewichtig ist und nicht auf eine SQL Server-Instanz oder umfangreiche lokale Infrastruktur angewiesen ist. Der Agent wird auf einem beliebigen Server (auch Domain Controller) installiert und kommuniziert ausschließlich outbound mit der Cloud.

Entra ID Connect oder Cloud Sync? – Microsofts Strategie für hybride Identitäten

Während Entra ID Connect das etablierte Werkzeug für die Synchronisation von lokalen Identitäten mit der Cloud ist, stellt Microsoft mit Entra Cloud Sync eine modernere, cloudbasierte Alternative zur Verfügung. Beide Lösungen ermöglichen die Synchronisierung von Benutzer- und Gruppenobjekten, als auch von Attributen, unterscheiden sich jedoch deutlich im Architekturansatz und den Einsatzszenarien.

Unterschiede auf einen Blick

Hinweis: Cloud Sync unterstützt derzeit keine Writeback-Funktionen (z.B. Kennwortrückschreibung), die bei Entra ID Connect mit PHS oder PTA möglich sind.

Microsofts Präferenz – klare Richtung für die Zukunft

Microsoft signalisiert deutlich, dass Cloud Sync die langfristige strategische Richtung ist – insbesondere für neue Umgebungen, die sich cloudzentriert entwickeln. Für komplexe bestehende Strukturen mit Kennwort-Writeback oder hybriden Exchange-Umgebungen bleibt Entra ID Connect vorerst unverzichtbar. In vielen neuen Szenarien empfiehlt Microsoft jedoch:

• Cloud Sync, wenn keine Writeback-Funktionalität benötigt wird
• Entra ID Connect, wenn Exchange-Hybrid oder spezifische Legacy-Kompatibilität erforderlich ist

Von GPOs zu Intune – Compliance gestern und heute

Wer in klassischen Windows-Umgebungen aufgewachsen ist, kennt sie: die Gruppenrichtlinienobjekte (Group Policy Objects, GPOs). Über sie lassen sich seit Windows 2000 nahezu alle Aspekte eines Windows-Systems zentral steuern – von Benutzeroberfläche und Softwareinstallation bis zu Sicherheitseinstellungen und Skriptausführung. In On-Premises-Netzen mit Active Directory sind GPOs nach wie vor das zentrale Werkzeug zur Durchsetzung von Compliance- und Konfigurationsvorgaben.

Doch mit der Cloud – und vor allem mit Entra ID – endet der Geltungsbereich klassischer GPOs.

GPOs: Mächtig, aber lokal gebunden

GPOs benötigen:

• eine AD-Domäne zur Anbindung
• Netzwerkverbindung zum Domänencontroller
• ein SYSVOL-Replikationssystem
• klassische Windows-Clients, die GPO-fähig sind

Diese Anforderungen sind in modernen, mobilen und heterogenen Umgebungen oft nicht mehr gegeben. Geräte, die außerhalb des Firmennetzwerks betrieben oder gar nicht domänengebunden sind (z.B. BYOD oder Cloud-Only-Geräte), lassen sich mit GPOs nicht steuern.

Intune & Co – Cloud-native Geräteverwaltung

Mit Microsoft Intune (heute Teil von Microsoft Endpoint Manager) bietet Microsoft eine cloudbasierte Alternative zur GPO-Welt.

Intune ermöglicht:

• App-Verteilung (inkl. Office, Edge, Line-of-Business-Anwendungen)
• Compliance-Regeln in Verbindung mit Conditional Access
• Gerätekonfiguration und -richtlinien (auch für macOS, iOS, Android)
• Reporting und Überwachung von Compliance-Status
• Self-Service-Portale für App-Installationen und Gerätesichtbarkeit
• Sicherheitsrichtlinien (Passwortvorgaben, Verschlüsselung, Updateverhalten)
• Zuweisung von Richtlinien und Anwendungen an Benutzer:innen und Geräte

Intune funktioniert dabei unabhängig von klassischem AD – die Zuweisung erfolgt über Entra ID. Geräte lassen sich dabei:

• registrieren (Entra ID Registered)
• verbinden (Entra ID Joined)
• oder hybrid anbinden (Hybrid Entra ID Joined)

Vorteil: Auch Geräte außerhalb des Netzwerks lassen sich so verwalten – über das Internet, ohne VPN, zentral über das Intune-Portal.

GPO vs. Intune – kein 1:1-Ersatz

Wichtig: Intune ersetzt GPOs nicht vollständig, vor allem nicht in komplexen Umgebungen mit Legacy-Systemen. Aber es bietet moderne Ansätze für:

Bereich	GPO	Intune
Feingranularität	Sehr detailliert (Registry-Ebene)	Eher Policy-Set-basiert (noch wachsend)
Gerätebindung	Domänenbeitritt notwendig	Entra ID Join oder Registrierung
Offlinefähigkeit	Ja (bei AD-Anbindung)	Ja, mit Cloud-Sync beim nächsten Kontakt
Plattformen	Windows	Windows, macOS, iOS, Android
Verteilung	SYSVOL + Replikation	Cloud-Push via Endpoint Manager

Viele Unternehmen setzen heute auf Co-Management – also eine Kombination aus GPOs für lokale Systeme und Intune für mobile oder cloudnative Geräte.

Wohin geht die Reise? Microsofts Identitätsstrategie im Wandel

Active Directory ist seit über zwei Jahrzehnten ein Fundament der IT-Infrastruktur – und wird es in vielen Organisationen auch noch einige Jahre bleiben. Doch Microsoft hat den strategischen Kurs längst angepasst: Cloud-First, Identität als Sicherheitsanker und automatisiertes Policy-Management bilden die neuen Leitlinien.

Wer den Wandel gestalten möchte, sollte die Richtung verstehen, in die Microsoft denkt – und wie sich lokale und Cloud-basierte Systeme dabei ergänzen oder ablösen.

On-Premise lebt – aber mit verändertem Fokus

Microsoft hat sich nie explizit von Active Directory verabschiedet – im Gegenteil: Domänencontroller, DNS und DHCP sind nach wie vor integraler Bestandteil vieler Netzwerke. Doch der Fokus liegt zunehmend auf hybrider Nutzbarkeit und Managementfähigkeit aus der Cloud.

Mit dem Erscheinen von Windows Server 2025 unterstreicht Microsoft, dass On-Premise-Komponenten auch weiterhin eine (zeitlich begrenzte) strategische Relevanz besitzen. Laut offizieller Lifecycle-Information gelten folgende Zeiträume:

• Mainstream Support bis Mai 2031
• Extended Support bis Mai 2036

Damit ist klar: Klassische AD-Infrastrukturen können – bei technischer Pflege – mindestens bis 2036 weiterbetrieben werden. Unternehmen mit Langfristplanung erhalten ein stabiles Zeitfenster, um Hybridstrategien zu etablieren oder Alternativen zu evaluieren.

Doch ein Warnsignal bleibt: Nicht alle On-Premise-Serverprodukte erhalten klassische Nachfolgeversionen. Microsoft hat stattdessen bei mehreren Produkten ein neues Abo-basiertes Subscription-Modell (SE) eingeführt – darunter:

• Exchange Server Subscription Edition (SE)
• SharePoint Server SE
• Skype for Business Server SE

Diese Servervarianten sind nur noch im Rahmen aktiver Software Assurance oder über spezielle Volumenlizenzprogramme verfügbar und werden in einem kontinuierlichen Update-Modell weiterentwickelt – nicht mehr in klassischen Releasezyklen. Die Lizenzform signalisiert deutlich: On-Prem lebt weiter – aber nur, wenn es kontrolliert, abonniert und aus der Cloud heraus gesteuert wird.

Querverweis: Weitere Details dazu und zur strategischen Ausrichtung dieser Produktlinie finden sich auch in meinem Beitrag:
Exchange Server SE und Skype for Business SE – Microsofts On-Premises-Neustart im Abo-Modell

Windows Admin Center (WAC) – Brücke zwischen Welten

Mit dem Windows Admin Center (WAC) bietet Microsoft ein modernes Werkzeug zur Verwaltung lokaler Serverrollen – browserbasiert, modular und Cloud-integrierbar. Es erlaubt u.a.:

• Einfache Delegation und rollenbasierte Zugriffskonzepte
• Erweiterung über Module, z.  für Hyper-V, Storage, Failover Clustering
• Integration von Azure Arc zur Steuerung lokaler Ressourcen über Azure
• Verwaltung von Active Directory, DNS, DHCP, Zertifikaten, Updates u.v.m.

WAC ist damit mehr als nur ein moderner Ersatz für die MMC – es ist der zukünftige Managementhub für hybride Umgebungen, in dem lokale und Cloud-nahe Dienste zunehmend unter einheitlicher Oberfläche zusammenwachsen.

Besonders in Kombination mit Azure Arc wird WAC zum Werkzeug für Arc-aktivierte Server: On-Premises- oder Edge-Systeme lassen sich so aus der Cloud heraus verwalten, patchen, überwachen und in Richtlinien einbinden – ganz wie native Azure-Ressourcen.

Microsoft treibt diese Entwicklung aktiv voran: Das Windows Admin Center ist mittlerweile auch in Azure als gehosteter Dienst verfügbar – und wird dort voraussichtlich weiter ausgebaut.
Die Verwaltung klassischer Windows-Serverinfrastrukturen verlagert sich damit zunehmend in die Cloud – bei Bedarf auch ohne Migration der eigentlichen Systeme.

Strategische Trends im Identitätsmanagement

Microsofts Vision ist klar: Identität ist der neue Perimeter. Daraus ergeben sich mehrere Trends:

• Automation first: Wiederkehrende Prozesse (Zugriffsanfragen, Onboarding, Offboarding) werden automatisiert
• Cloud-native Governance: Rollen, Rechte und Zugriffe werden zentral modelliert und automatisch durchgesetzt
• Passwordless by default: Passwörter gelten als Risikofaktor – ersetzt durch FIDO2, biometrische Verfahren, Authenticator
• Verteilte Identitäten: Föderierte oder externe Benutzer:innen werden als gleichberechtigt behandelt – z.B. via B2B-Konnektivität
• Zero Trust: Kein implizites Vertrauen – jede Verbindung, jedes Gerät, jede Aktion muss überprüfbar und autorisiert sein

Microsoft Entra (als Gesamtkonstrukt von Entra ID, Permissions Management und Verified ID) ist dabei das Identitäts-Framework der Zukunft – offen, modular, API-basiert und Cloud-first.

Die Rolle der Administration von morgen

Die Administration wird sich ebenfalls wandeln:

• Mehr Architektur und Konzept – weniger Konfiguration
• Plattformdenken statt Systemsilos
• Verständnis für Compliance, Datenschutz, regulatorische Anforderungen
• Weg vom Handbetrieb, hin zur Richtliniensteuerung
• Zusammenarbeit mit Security und Governance-Teams

Wer heute in Active Directory fit ist, bringt die besten Voraussetzungen mit – aber sollte den eigenen Werkzeugkoffer um Cloud-Identität, Conditional Access, Intune und Zero Trust-Prinzipien erweitern.

Fazit – Verzeichnisdienste verstehen heißt Identitäten gestalten

Active Directory war – und ist – mehr als nur ein technisches Mittel zur Benutzerverwaltung. Es ist ein architekturprägendes Fundament für Zugriffssteuerung, Rollenverteilung und Infrastrukturdesign. Doch mit der zunehmenden Verlagerung von Diensten in die Cloud hat sich das Spielfeld verändert.

Was früher mit NT-Domänen und logon.bat begann, ist heute ein komplexes Zusammenspiel aus hybriden Identitäten, plattformübergreifenden Richtlinien und automatisierten Zugriffssteuerungen geworden. Dabei steht eines fest:

Identität ist heute der Schlüssel zu allem – zu Ressourcen, zu Sicherheit, zu Zusammenarbeit. Wer Identitäten steuern kann, steuert Zugänge, Risiken und Compliance.

Empfehlungen für die Praxis

Für Administrator:innen bedeutet das:

• Bestehende AD-Strukturen hinterfragen – sind sie logisch, sicher und erweiterbar?
• Cloud-Identität und Entra ID verstehen und nutzen, statt sich auf lokale Konten zu verlassen
• Hybride Szenarien bewusst gestalten, statt sie nur technisch umzusetzen
• On-Premise-Zukunft realistisch planen – inklusive Migration, Co-Management oder Ausstiegsstrategie
• Rollenbasierte Delegation, moderne Richtlinien (Intune), und Zero Trust-Konzepte etablieren

Und zuletzt: Rollenbewusstsein

Wer heute Verzeichnisdienste betreut, ist nicht mehr nur Administrator:in, sondern auch:

• Compliance-Garant:in
• Identitätsarchitekt:in
• Risikomanager:in
• Vermittler:in zwischen Bedürfnissen von Benutzer:innen und Sicherheitszielen des Unternehmens

Diese Verantwortung ist hoch – aber auch eine Chance: Mit fundiertem Wissen, Weitsicht und der richtigen Strategie können wir die Identitäten von heute sicher in die Arbeitswelten von morgen führen.

Denn Verzeichnisdienste zu verwalten heißt längst nicht mehr nur, Konten zu pflegen – es bedeutet, digitale Identität verantwortungsvoll zu gestalten. Zwischen Sicherheit und Benutzerfreundlichkeit, Kontrolle und Vertrauen, Technik und Strategie braucht es Menschen, die nicht nur Rechte vergeben, sondern Verhältnisse verstehen.

Wer die Identität schützt, schützt nicht nur Systeme – sondern auch das Vertrauen in Zusammenarbeit. Und das beginnt bei uns.