Stellen Sie sich vor: Ihr Team arbeitet reibungslos in der Azure Cloud, Ihre virtuellen Maschinen sind nahtlos in Ihre Domäne integriert, und die Authentifizierung läuft wie geschmiert. Plötzlich taucht er auf – ein unerwarteter Stolperstein: der AADDS113 error. Diese Fehlermeldung kann einen Moment der Panik auslösen, besonders wenn Ihre gesamte Infrastruktur von einem funktionierenden Azure AD Domain Services (AADDS) abhängt. Doch keine Sorge: Wie die meisten technischen Herausforderungen lässt sich auch dieser Fehler verstehen und beheben. In diesem umfassenden Leitfaden erfahren Sie, was der AADDS113-Fehler bedeutet, welche Ursachen er haben kann und wie Sie Ihre Managed Domain Schritt für Schritt wieder auf Kurs bringen.
Was ist Azure AD Domain Services (AADDS)?
Bevor wir uns dem Fehler widmen, kurz zur Erinnerung: Azure AD Domain Services ist ein Cloud-basierter Dienst, der verwaltete Domänendienste bereitstellt, wie sie normalerweise von einer lokalen Windows Server Active Directory-Domäne angeboten werden. Dies umfasst Domänenbeitritt, Gruppenrichtlinien, LDAP, Kerberos/NTLM-Authentifizierung, und mehr. AADDS ermöglicht es Ihnen, Ihre virtuellen Maschinen und Anwendungen in Azure nahtlos in eine Domäne zu integrieren, ohne selbst Domänencontroller bereitstellen, patchen oder verwalten zu müssen. Es synchronisiert Benutzer, Gruppen und Passwort-Hashes von Ihrem Azure AD (und optional von einem lokalen AD via Azure AD Connect) in eine dedizierte, von Microsoft verwaltete Domäne. Kurz gesagt, AADDS ist das Rückgrat vieler Cloud-Infrastrukturen, die traditionelle Domänenfunktionen benötigen.
Der AADDS113 Fehler – Ein genauerer Blick
Der AADDS113-Fehler ist eine generische Meldung, die darauf hinweist, dass Azure AD Domain Services Probleme hat, auf Ihre virtuellen Netzwerke (VNets) und andere Netzwerkressourcen zuzugreifen oder diese zu verwalten. Im Klartext: Ihre Managed Domain ist aus irgendeinem Grund nicht mehr vollständig erreichbar oder funktionsfähig. Dies kann sich in verschiedenen Symptomen äußern:
- Virtuelle Maschinen können der Domäne nicht beitreten.
- Benutzer können sich nicht an Domänen-gebundenen Ressourcen authentifizieren.
- Anwendungen, die LDAP oder Kerberos benötigen, funktionieren nicht mehr.
- Die Domänensynchronisierung scheint nicht mehr zu funktionieren.
- Im Azure-Portal wird der AADDS-Dienst als „unhealthy” oder mit Warnungen angezeigt.
Die Ursache des AADDS113-Fehlers liegt fast immer in der Netzwerkkonfiguration oder den Berechtigungen, die den AADDS-Dienst betreffen. Da AADDS in einem von Ihnen ausgewählten VNet bereitgestellt wird und seine Domänencontroller als Dienst in diesem VNet existieren, ist eine korrekte Netzwerkverbindung absolut entscheidend für seine Funktion.
Häufige Ursachen und Diagnosen
Um den AADDS113-Fehler zu beheben, müssen wir die potenziellen Ursachen systematisch durchgehen. Hier sind die häufigsten Schuldigen:
1. Netzwerk-Sicherheitsgruppen (NSGs)
Die häufigste Ursache für den AADDS113-Fehler sind falsch konfigurierte oder neu hinzugefügte Netzwerk-Sicherheitsgruppen (NSGs). AADDS benötigt bestimmte Ports, um in Ihrem VNet zu kommunizieren. Wenn diese Ports durch NSG-Regeln blockiert werden, kann der Dienst nicht funktionieren. Wichtige Ports, die offen sein müssen, sind unter anderem:
- Port 389 (LDAP) und Port 636 (LDAPS): Für die Kommunikation mit Domänencontrollern.
- Port 88 (Kerberos) und Port 464 (Kerberos Password Change): Für die Authentifizierung.
- Port 53 (DNS): Für die Domänennamenauflösung.
- Port 445 (SMB): Für Dateifreigaben und Gruppenrichtlinien.
- Port 3268 (Global Catalog LDAP) und Port 3269 (Global Catalog LDAPS): Für den Globalen Katalog.
- Verschiedene dynamische Ports (Ephemeral Ports): Für RPC-Kommunikation.
- Management Ports (z.B. 5986 für PowerShell Remoting über WinRM): Für interne AADDS-Verwaltung.
AADDS erstellt eine eigene NSG (die „AADDS-Netzwerk-Sicherheitsgruppe”) und fügt sie dem Subnetz hinzu, in dem AADDS aktiviert ist. Diese NSG enthält die erforderlichen Regeln. Wenn Sie jedoch *zusätzliche* NSGs an das Subnetz oder die Netzwerkschnittstellen der AADDS-Domänencontroller anwenden, können diese die Standardregeln überschreiben oder blockieren.
2. DNS-Konfiguration im VNet
Damit Clients in Ihrem VNet die AADDS-Domänencontroller finden können, müssen die DNS-Servereinstellungen des VNets korrekt konfiguriert sein. Die DNS-Server des VNets müssen auf die IP-Adressen der AADDS-Domänencontroller zeigen. Wenn diese Einstellungen geändert oder überschrieben werden (z.B. durch eine eigene DNS-Serverliste), können Clients die Domänencontroller nicht auflösen, was zu Authentifizierungs- und Domänenbeitrittsproblemen führt.
3. Benutzerdefinierte Routingtabellen (UDRs)
Benutzerdefinierte Routingtabellen (UDRs), die auf das Subnetz angewendet werden, in dem AADDS bereitgestellt ist, können den Netzwerkverkehr umleiten und so die Kommunikation von AADDS zu den internen Azure-Diensten oder zu seinen eigenen Komponenten stören. AADDS benötigt eine direkte und ungehinderte Kommunikation innerhalb des Subnetzes und zu Azure-Infrastrukturdiensten. Jegliche UDR, die den Standard-Routingpfad ändert, kann Probleme verursachen.
4. VNet-Peering oder ExpressRoute/VPN-Verbindungen
Wenn Ihre AADDS-Domäne über VNet-Peering mit anderen VNets oder über ExpressRoute/VPN Gateway mit Ihrem lokalen Netzwerk verbunden ist, stellen Sie sicher, dass der Netzwerkverkehr zwischen diesen Netzwerken und dem AADDS-Subnetz korrekt geroutet wird und keine Firewalls oder NSGs diesen Verkehr blockieren.
5. Berechtigungen des AADDS-Dienstprinzipals
AADDS verwendet einen Dienstprinzipal, um Operationen in Ihrem Azure-Abonnement auszuführen, wie das Erstellen von Netzwerkschnittstellen, Hinzufügen von DNS-Servern zum VNet oder Verwalten von NSG-Regeln. Wenn die Berechtigungen für diesen Dienstprinzipal entfernt oder eingeschränkt wurden, kann AADDS seine Aufgaben nicht erfüllen, was ebenfalls zum AADDS113-Fehler führen kann.
6. Azure AD Connect und Passwort-Hash-Synchronisation
Obwohl es nicht direkt eine Netzwerkursache ist, hängt AADDS von Azure AD Connect ab, um Benutzer, Gruppen und vor allem Passwort-Hashes von Ihrem lokalen Active Directory zu Azure AD und dann zu AADDS zu synchronisieren. Wenn die Passwort-Hash-Synchronisation ausfällt, können sich Benutzer nicht an der Managed Domain anmelden, was zu Fehlern führen kann, die fälschlicherweise als AADDS113 interpretiert werden könnten oder den Dienst zusätzlich beeinträchtigen.
Schritt-für-Schritt-Anleitung zur Fehlerbehebung
Lassen Sie uns nun die Ärmel hochkrempeln und den AADDS113-Fehler systematisch beheben.
Schritt 1: Überprüfen des Azure-Portals
Dies ist immer der erste Schritt. Das Azure-Portal ist Ihre zentrale Anlaufstelle für den Status von AADDS.
- Navigieren Sie zu Ihrem Azure AD Domain Services-Dienst.
- Überprüfen Sie den Status der Managed Domain. Ist er „Running”, „Needs configuration”, „Unhealthy” oder „Warning”?
- Schauen Sie in den Health Status-Bereich. Hier werden oft spezifische Warnungen oder Fehler mit Empfehlungen angezeigt, z.B. „AADDS113: Es wurden Netzwerkprobleme erkannt, die die Kommunikation mit der Domäne beeinträchtigen.”
- Klicken Sie auf alle relevanten Warnungen, um detailliertere Informationen und potenzielle Lösungsansätze zu erhalten.
- Prüfen Sie auch unter Ressourcenintegrität im linken Menü nach weiteren Hinweisen auf Probleme.
Schritt 2: Netzwerkkonfiguration validieren (Der häufigste Fehler!)
Da NSGs und DNS die häufigsten Ursachen sind, konzentrieren wir uns hierauf.
- Überprüfen der NSGs:
- Gehen Sie zu dem Subnetz, in dem AADDS bereitgestellt ist.
- Prüfen Sie die dem Subnetz zugeordnete NSG. Suchen Sie nach der von AADDS erstellten NSG (oft benannt wie „aadds--nsg”).
- Stellen Sie sicher, dass keine *zusätzliche* NSG an das Subnetz angehängt ist, die die von AADDS benötigten Ports blockiert.
- Wenn Sie eine benutzerdefinierte NSG anwenden müssen, stellen Sie sicher, dass alle oben genannten Ports (389, 636, 88, 464, 53, 445, 3268, 3269, 5986, etc.) für den eingehenden und ausgehenden Verkehr zum und vom AADDS-Subnetz geöffnet sind. Idealerweise sollte die Standard-AADDS-NSG nicht verändert oder durch eine andere NSG überlagert werden, die restriktiver ist.
- Wenn die AADDS-NSG fehlt oder beschädigt wurde, können Sie unter Umständen versuchen, sie über das AADDS-Portal „zurückzusetzen” (dies ist oft eine Option, wenn der Gesundheitscheck Probleme meldet).
- Überprüfen der VNet DNS-Einstellungen:
- Navigieren Sie zu Ihrem Virtual Network, in dem AADDS bereitgestellt ist.
- Klicken Sie auf DNS-Server im linken Menü.
- Stellen Sie sicher, dass „Benutzerdefiniert” ausgewählt ist und die hier aufgeführten IP-Adressen die IP-Adressen der AADDS-Domänencontroller sind. Diese werden Ihnen im Übersichts-Blatt Ihres AADDS-Dienstes angezeigt.
- Wenn hier andere DNS-Server konfiguriert sind, ändern Sie sie zu den AADDS-IPs und speichern Sie. Denken Sie daran, dass Änderungen an den VNet-DNS-Einstellungen eine Neustart von VMs im VNet erfordern können, um die neuen Einstellungen zu übernehmen.
- Überprüfen von UDRs:
- Gehen Sie zu Ihrem AADDS-Subnetz und überprüfen Sie, ob Routingtabellen zugeordnet sind.
- Wenn ja, überprüfen Sie die Regeln in dieser Routingtabelle. Stellen Sie sicher, dass keine Routen den Standard-Internetverkehr oder den Verkehr zu den Azure-Infrastrukturdiensten (z.B. 168.63.129.16) umleiten, der für AADDS notwendig ist. Im Zweifelsfall entfernen Sie die UDR testweise (in einer Testumgebung) oder fügen Sie eine spezifische Route hinzu, die den AADDS-Verkehr nicht beeinflusst.
Schritt 3: Testen der DNS-Auflösung und Netzwerkkonnektivität
Starten Sie eine VM im selben VNet/Subnetz wie AADDS (oder einem über Peering verbundenen VNet) und führen Sie folgende Tests durch:
- Ping und Telnet/Test-NetConnection: Versuchen Sie, die AADDS-Domänencontroller-IPs anzu-pingen (wenn ICMP in Ihrer NSG erlaubt ist). Wichtiger ist, die Konnektivität auf den relevanten Ports zu testen:
Test-NetConnection -ComputerName <AADDS-DC-IP> -Port 389
Wiederholen Sie dies für Ports 636, 88, 464, 53, 445. Alle sollten erfolgreich sein. - nslookup:
nslookup <AADDS-Domänenname>
Dies sollte die IP-Adressen Ihrer AADDS-Domänencontroller zurückgeben.
nslookup <AADDS-DC-IP> <AADDS-DC-IP>
Dies testet die DNS-Auflösung direkt über einen der AADDS-DCs.
Wenn diese Tests fehlschlagen, haben Sie immer noch ein Netzwerk- oder DNS-Problem, das behoben werden muss.
Schritt 4: Überprüfen der Synchronisation
Wenn die Netzwerkprüfung erfolgreich war, aber Benutzer sich immer noch nicht anmelden können, könnte es an der Synchronisation liegen.
- Azure AD Connect Status: Wenn Sie einen hybriden Aufbau haben, überprüfen Sie den Status Ihres Azure AD Connect-Servers. Stellen Sie sicher, dass er läuft, keine Synchronisationsfehler meldet und die Passwort-Hash-Synchronisation aktiviert ist und funktioniert.
- AADDS Password Hash Synchronization: Im AADDS-Portal gibt es keine direkte Schaltfläche zum manuellen Auslösen der Passwort-Hash-Synchronisation. Diese geschieht automatisch. Stellen Sie sicher, dass Benutzer, die sich anmelden sollen, mindestens einmal ihr Passwort *geändert* haben, nachdem AADDS aktiviert wurde. Nur dann werden die Hashes nach AADDS synchronisiert.
Schritt 5: Überprüfen der AADDS Security Group
AADDS erstellt eine Sicherheitsgruppe namens „AAD DC Administrators”. Benutzer in dieser Gruppe haben erweiterte Berechtigungen auf der Managed Domain. Stellen Sie sicher, dass die korrekten Benutzer in dieser Gruppe sind und dass die Gruppe nicht beschädigt wurde.
Schritt 6: Letzte Schritte und Kontaktaufnahme mit dem Support
- Neustart von VMs: Nachdem Sie Netzwerk- oder DNS-Änderungen vorgenommen haben, starten Sie die betroffenen VMs neu, damit sie die neuen DNS-Einstellungen abrufen.
- AADDS-Dienst neu starten/reparieren: Es gibt keine direkte Schaltfläche im Portal, um den AADDS-Dienst „neu zu starten”. Allerdings kann das Azure-Portal bei hartnäckigen Problemen manchmal die Option anbieten, den Dienst zu „reparieren” oder eine „Gesundheitsprüfung” auszulösen, was interne Prozesse neu starten kann. Nutzen Sie diese Optionen, wenn sie angeboten werden.
- Azure Support kontaktieren: Wenn alle oben genannten Schritte den AADDS113-Fehler nicht beheben konnten und der Dienst weiterhin „unhealthy” anzeigt, ist es an der Zeit, den Azure Support zu kontaktieren. Halten Sie alle gesammelten Informationen (Fehlermeldungen, durchgeführte Tests, NSG-Regeln, DNS-Einstellungen) bereit, um den Prozess zu beschleunigen.
Best Practices zur Vermeidung des AADDS113-Fehlers
Vorbeugen ist besser als Heilen. Mit diesen Best Practices minimieren Sie das Risiko des AADDS113-Fehlers:
- Dokumentation: Dokumentieren Sie Ihre Netzwerkkonfiguration, insbesondere NSG-Regeln, UDRs und DNS-Einstellungen im AADDS-Subnetz.
- Dediziertes Subnetz: Stellen Sie AADDS immer in einem dedizierten Subnetz bereit, um Interferenzen mit anderen Ressourcen zu vermeiden.
- Keine unnötigen Änderungen: Vermeiden Sie es, die vom AADDS-Dienst selbst verwaltete NSG oder die VNet-DNS-Einstellungen direkt zu ändern. Lassen Sie AADDS diese Komponenten verwalten.
- Überwachung: Richten Sie Azure Monitor-Warnungen für den AADDS-Dienststatus ein, um proaktiv über Probleme informiert zu werden.
- Change Management: Implementieren Sie ein strenges Change Management für alle Netzwerkänderungen in VNets, die AADDS hosten oder mit ihm verbunden sind.
- Tests: Testen Sie wichtige Netzwerkänderungen zuerst in einer Nicht-Produktionsumgebung.
Fazit
Der AADDS113-Fehler mag auf den ersten Blick entmutigend wirken, ist aber in den allermeisten Fällen auf eine Fehlkonfiguration im Netzwerk zurückzuführen. Mit einem systematischen Ansatz zur Fehlerbehebung, der sich auf NSGs, DNS-Einstellungen und Routing konzentriert, können Sie Ihre Managed Domain in Azure AD Domain Services schnell wieder auf Kurs bringen. Indem Sie die Ursachen verstehen und bewährte Verfahren anwenden, können Sie die Stabilität und Verfügbarkeit Ihrer Cloud-Infrastruktur gewährleisten und den Stolperstein AADDS113 in Zukunft vermeiden.