Windows Server 2025 / Windows-Client zur Active Directory-Domäne hinzufügen

Für den Beitritt von CLIENT1 zu einer Active Directory-Domäne (AD) benötigen Sie eine unterstützte Windows-Edition, funktionierendes internes DNS, Erreichbarkeit der Domäne und Rechte zum Erstellen oder Wiederverwenden des Computerkontos. Verwenden Sie DC1 als DNS-Server, lassen Sie CLIENT1 ad.example.test beitreten und starten Sie nach bestätigtem Erfolg neu. Prüfen Sie die Domänenmitgliedschaft des Computers getrennt von der Identität der angemeldeten Person.

Bereiten Sie DNS und Beitrittsberechtigungen vor

Verwenden Sie eine Edition mit Unterstützung für AD-Domänenbeitritt, beispielsweise Windows 11 Pro oder Enterprise. Windows Home unterstützt diesen Beitritt nicht. Ein Beitritt oder eine Registrierung bei Microsoft Entra ID ist ein anderer Vorgang. AD und DNS auf DC1 müssen im gemeinsamen isolierten Netz funktionieren; Grundlage ist die Übung zum Erstellen der ersten Domäne. Für den Beitritt benötigen Sie lokale Administratorrechte auf CLIENT1 und zusätzlich passende Berechtigungen in AD.

• Legen Sie den endgültigen Rechnernamen CLIENT1 fest und prüfen Sie vor dem Beitritt die lokale Administratoranmeldung. Halten Sie die VM-Konsole erreichbar.
• Verwenden Sie am Laboradapter DNS 172.24.50.10. Kontrollieren Sie bei DHCP die tatsächlich empfangenen Optionen und den vorgesehenen automatischen oder manuellen Bezug. Ein zusätzlicher öffentlicher DNS ersetzt den internen AD-DNS nicht.
• Prüfen Sie Datum, Uhrzeit, gemeinsames virtuelles Netz und Kommunikation mit DC1. Schalten Sie die Firewall nicht ab, um ein Problem mit Regeln oder deren Geltungsbereich zu verdecken.
• Bereiten Sie ein Konto mit den passenden Rechten zum Erstellen des Computerobjekts am Ziel oder zum Wiederverwenden des bestehenden Objekts vor. Lokale Administratorrechte und AD-Rechte sind getrennte Voraussetzungen.

Resolve-DnsName '_ldap._tcp.dc._msdcs.ad.example.test' -Type SRV -Server 172.24.50.10
nltest /dsgetdc:ad.example.test

Die SRV-Antwort sollte im Labor den erwarteten Dienst am Controller angeben, beispielsweise dc1.ad.example.test. Nltest sollte einen Controller für ad.example.test finden. Ein vorhandener SRV-Eintrag beweist nicht, dass sämtliche Beitrittsverbindungen funktionieren. Antwortet die erste Abfrage, die zweite aber nicht, kontrollieren Sie auch den auf CLIENT1 eingetragenen DNS-Server. Eine erfolgreiche Suche erteilt weder Beitrittsrechte noch bestätigt sie ein Kennwort.

Führen Sie beide Abfragen vor der Kennworteingabe auf CLIENT1 aus. Die erste fragt ausdrücklich DNS 172.24.50.10 ab; die zweite sucht anhand der Clientkonfiguration einen Domänencontroller. Scheitert die Suche, prüfen Sie Adapter, DNS, Netzwerkverbindung und Uhrzeit, statt wiederholt Kennwörter einzugeben. Die Berechtigungen für den Domänenbeitritt unterscheiden das Erstellen eines neuen von der Wiederverwendung eines vorhandenen Computerkontos. Delegieren Sie nur die benötigten Rechte im vorgesehenen Container oder in der Organisationseinheit (OU), ohne Alltagskonten dafür zu Domänenadministratoren zu machen.

Lassen Sie CLIENT1 über die Systemeigenschaften beitreten

1. Starten Sie auf CLIENT1 sysdm.cpl und wählen Sie Computername → Ändern. Prüfen Sie Zielcomputer und lokale Administratorrechte.
2. Wählen Sie unter Mitglied von die Option Domäne, geben Sie ad.example.test als DNS-Domänennamen ein und bestätigen Sie mit OK.
3. Geben Sie bei der Abfrage ein berechtigtes Domänenkonto ein, etwa AD\BerechtigterName mit dem tatsächlichen Namen. Das lokale CLIENT1-Kennwort allein berechtigt nicht zum Erstellen oder Wiederverwenden eines AD-Objekts.
4. Prüfen Sie die Erfolgsmeldung. Brechen Sie bei einer Fehlermeldung weitere Schritte ab und notieren Sie diese. Nach erfolgreichem Beitritt speichern Sie Ihre Arbeit und starten wie angefordert neu.
5. Wählen Sie nach dem Neustart Anderer Benutzer und melden Sie sich mit AD\Benutzername oder Benutzername@ad.example.test an. Ersetzen Sie Benutzername durch ein wirklich vorhandenes Domänenkonto und behalten Sie die lokalen Administratorzugangsdaten.

Die offizielle Anleitung zum Domänenbeitritt beschreibt den Vorgang. Falls der normale Laborbenutzer noch nicht angelegt ist, prüfen Sie zunächst Beitritt und Verwaltung mit einem vorhandenen berechtigten Konto. Die Anmeldung des Standardbenutzers testen Sie später, sobald sein Konto existiert. Verwenden Sie ein Konto aus Domain Admins nicht als alltägliche Arbeitsidentität.

CLIENT1\Benutzer und AD\Benutzer sind verschiedene Identitäten, auch wenn der sichtbare Benutzername übereinstimmt. Bei der ersten Domänenanmeldung wird das bisherige lokale Profil nicht automatisch übernommen; ein anderer Desktop oder andere Einstellungen sind deshalb möglich. Sichern Sie die Daten und planen Sie eine Übernahme mit geeigneten Berechtigungen. Löschen Sie nicht den bisherigen Profilordner, um den Profilwechsel vermeintlich zu beheben.

Verwenden Sie alternativ PowerShell

Alternativ zum Dialog öffnen Sie Windows PowerShell auf CLIENT1 als Administrator, sofern der Computer noch nicht beigetreten ist. Führen Sie den Block zeilenweise aus: Get-Credential fragt ein berechtigtes Domänenkonto und dessen Kennwort interaktiv ab; Add-Computer führt den Beitritt aus und liefert mit -PassThru -Verbose überprüfbare Ergebnisse. Starten Sie Restart-Computer erst nach bestätigtem Beitrittserfolg und gespeichertem Arbeitsstand. Ein Fehler von Add-Computer verhindert nicht automatisch, dass eine anschließend eingefügte Neustartzeile ausgeführt wird. Einzelheiten stehen in der Referenz zu Add-Computer:

$joinCredential = Get-Credential
Add-Computer -DomainName 'ad.example.test' -Credential $joinCredential -PassThru -Verbose
Restart-Computer

Ein Neustart macht aus einem fehlgeschlagenen Beitritt keinen erfolgreichen. Halten Sie bei Fehlern die Meldung fest und beheben Sie die Ursache vor einem erneuten Versuch. Nach demselben Prinzip kann FS1 als Mitgliedsserver beitreten: Seine statische IP 172.24.50.20 bleibt erhalten, als DNS verwendet er den funktionierenden Domänen-DNS 172.24.50.10. Ein Mitgliedsbeitritt installiert keine AD DS-Rolle und stuft FS1 nicht zum Domänencontroller herauf.

Prüfen Sie Mitgliedschaft und Sitzungsidentität getrennt

Get-CimInstance Win32_ComputerSystem | Select-Object Name,Domain,PartOfDomain
whoami
$env:LOGONSERVER
Test-ComputerSecureChannel -Verbose

Führen Sie diese Prüfungen nach dem Neustart auf CLIENT1 aus; öffnen Sie Windows PowerShell für die Diagnose mit Administratorrechten. PartOfDomain soll True, Domain ad.example.test und Name CLIENT1 anzeigen. Whoami zeigt dagegen die aktuelle Sitzung: AD\Benutzer ist eine Domänenidentität, CLIENT1\Benutzer bleibt lokal, selbst wenn der Computer beigetreten ist. LOGONSERVER liefert Sitzungskontext und beweist für sich allein weder fehlerfreies DNS noch funktionierende Authentifizierung oder einen intakten sicheren Kanal.

Test-ComputerSecureChannel -Verbose soll True liefern, wenn der sichere Kanal zwischen diesem Mitgliedscomputer und seiner Domäne funktioniert. Ohne -Repair prüft der Befehl nur und repariert nichts. Bei False oder einem Fehler prüfen Sie DNS, Erreichbarkeit und Computerkonto, bevor Sie eine Reparatur oder einen Austritt erwägen. Laut Referenz zu Test-ComputerSecureChannel gilt der Test für Clients und Mitgliedsserver. Auf DC1 als Domänencontroller kann er irreführende Fehler liefern und ersetzt dort keine DC-Diagnose.

Öffnen Sie auf DC1 Server-Manager → Tools → Active Directory-Benutzer und -Computer und suchen Sie das Computerobjekt CLIENT1. Ohne Vorabbereitstellung oder Umleitung wird es üblicherweise im Standardcontainer Computers angelegt; dieser Container ist keine OU. Bei einem vorbereiteten Konto prüfen Sie dessen tatsächlichen Ablageort. Für spätere Richtlinienübungen verschieben Sie das Objekt in die Labor-OU Workstations. Benutzer- und Computerobjekt haben unabhängige Speicherorte: Das Verschieben eines Objekts verschiebt das andere nicht.

Beachten Sie Kontowiederverwendung und Domänenaustritt

Schutzmechanismen können die Wiederverwendung eines bestehenden Computerkontos blockieren. Prüfen Sie Eigentümer, delegierte Rechte, Rechnername und den Status des bisherigen Geräts, bevor Sie das Objekt ändern. KB5020276 zur Absicherung des Domänenbeitritts beschreibt die Eigentümerprüfung und unterstützte Vorgehensweisen. Der Fehler 0xaac kann eine blockierte Wiederverwendung anzeigen und bedeutet nicht einfach ein falsches Kennwort. Untersuchen Sie auf CLIENT1 C:\Windows\debug\NetSetup.log zum genauen Zeitpunkt des Versuchs; ergänzend hilft die Anleitung zu Netzwerkfehlern beim Domänenbeitritt. Deaktivieren Sie keine Schutzprüfungen, vertrauen Sie nicht pauschal allen Konten und löschen Sie kein noch verwendetes Computerkonto, um den Beitritt zu erzwingen.

Lassen Sie CLIENT1 für die weiteren Übungen in der Domäne. Für eine gezielte Austrittsübung prüfen Sie zuerst, dass ein funktionsfähiges lokales Administratorkonto mit bekannten Zugangsdaten verfügbar ist. Öffnen Sie sysdm.cpl → Computername → Ändern, wählen Sie Arbeitsgruppe und tragen Sie den vorgesehenen Arbeitsgruppennamen ein. Autorisieren Sie den Vorgang bei Aufforderung und starten Sie nach bestätigtem Ergebnis neu. Melden Sie sich mit dem tatsächlichen lokalen Konto an, beispielsweise CLIENT1\LokalerName. Profildaten und Bereinigung des AD-Computerobjekts erfordern eigene Entscheidungen. Dokumentieren Sie Beitritt, Standardbenutzeranmeldung, DNS und sicheren Kanal jeweils mit eigenem Ergebnis und Zeitpunkt.