Server in AD nicht auffindbar (Vertrauensstellung, Securechannel, UserControl)
"Die Vertrauenssstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden".
Heute morgen war der Zugriff auf meinen Fileserver in der Domäne nicht mehr möglich. Die Fehlermeldung bei Zugiff auf die Shares sowie als ich mich direkt als Domänenadmin an die Maschine per RDP Anmelden wollte war: "Die Vertrauenssstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden".
Wir hatten in der Vergangenheit schon einmal Probleme mit dem Secure-Channel und dem DC.
Dieses mal scheint das Problem jedoch ein anderes zu sein. Nach einiger Recherche hier der erste Lösungsansatz:
1) Auf dem DC über die Kommandozeile:
- netdom.exe /reset /d: Domänenname.local Servername
- leider konnte ich den Befehl nicht erfolgreich ausführen, da ich die Rückmeldung erhielt: das der Zeilkontenname nicht verfügbar sei.
- Somit löschte ich das Computerkonto aus der AD und führte den o.g. Befehl erneut aus.
- Damit funktioniert zwar der generelle Zugriff, jedoch nur für ca. 25 Minuten.
- Danach musste ich den Server neu starten, da die Drucker und einige andere Dienste nicht funktionieren.
- Nach dem Neustart: Das gleiche Problem wieder..
2) zweiter Lösungsansatz:
- Server aus der Domäne entfernt.
- Server neu gestartet
- Server wieder in die Domäne genommen
- Server neu gestartet
- Test des Zugriffes: Drucker, Freigaben und WSUS wieder da.
- Problem: Ich kann das Computerkonto in meiner AD nicht finden.
- Es ist selbst nach zweimaligem neu-einbinden in die Domäne nicht sichtbar
3) Gerade habe ich noch einmal den Ereignislog des DCs durchgeschaut und folgendes Event gefunden:
- 1925 Warnung:
Protokollname: Directory Service
Quelle: Microsoft-Windows-ActiveDirectory_DomainService
Datum: 09.12.2011 12:05:31
Ereignis-ID: 1925
Aufgabenkategorie:Konsistenzprüfung
Ebene: Warnung
Schlüsselwörter:Klassisch
Benutzer: ANONYMOUS-ANMELDUNG
Computer: DC-Name.Domäne.local
Beschreibung:
Fehler beim Herstellen einer Replikationsverknüpfung mit der folgenden schreibbaren Verzeichnispartition.
Verzeichnispartition:
DC=Domäne,DC=local
Quellverzeichnisdienst:
CN=NTDS Settings,CN=GSGB01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=Domäne,DC=local
Adresse des Quellverzeichnisdienstes:
0be56632-ca1c-415b-af7b-e2d90904f981._msdcs.Domäne.local
Standortübergreifende Übertragung (falls vorhanden):
Dieser Verzeichnisdienst kann nicht mit dem Quellverzeichnisdienst replizieren, solange das Problem nicht behoben ist.
Benutzeraktion
Überprüfen Sie, ob auf den Quellverzeichnisdienst zugegriffen werden kann und ob eine Netzwerkverbindung besteht.
Zusätzliche Daten
Fehlerwert:
8453 Der Replikationszugriff wurde verweigert.
- Eine Recherche bez. der Eventid, brachte mich auf einen KB-Artikel: http://support.microsoft.com/kb/329860/de
Die Lösungansätze dieses Artikels:
- Schritt 1: Das Computerkonto in der Domain Controllers Container verschieben:
-- Check. DC ist in der OU: Domain Controllers
- Schritt 2: Überprüfen der UserAccountControl-Eigenschaft
-- Ich habe gerade den ADSI-Editor geöffnet und die entsprechenden Attributeigenschaften offen.
-- Der Wert der hier eingetragen ist, ist: 69632 nicht wie angegeben: 532480
-- Dieser Artikel bezieht sich jedoch auf einen Server 2000 nicht 2008 R2 und somit habe ich ein wenig Angst, das mir eine solche Änderung (gerade deshalb weil ich den Hintergrund dieses Wertes nicht begreife) Schaden an meiner AD verursacht.
-- Sollte ich diesen Wert verändern, oder lieber in Ruhe lassen?
- Schritt 3: Zurücksetzen des sicheren Kanals-Kennworts
-- Mit diesem Fehler haben/hatten wir in der Vergangenheit zu kämpfen und nach dem Zurücksetzen des Secure-Channel-Kennwortes mittels Microsoft-Support dachten wir, das Problem sei behoben. Leider scheint es sich aber wieder zu zeigen.
Bevor ich nun die letzten beiden Schritte durchführe, würde ich gerne auf eine Rückmeldung der geballten Kompetenz aus dem Administrationsbereich warten, auch deshalb weil wir ja "noch" arbeiten können. Um so tiefer ich jedoch in die Recherche steige, desto mehr Angst habe ich, dass mir das Komplette AD-Konstrukt nun "um die Ohren fliegt."
Zur Hilfestellung hier noch einige Zusatzinformationen:
IBM-Server mit VMWARE ESXi
- Virtuelle Maschinen:
- Server 1: DC
- Server 2: FS, WSUS, Printserver
- Server 3: Exchange-Server
- Server 4: Terminalserver
(alle vier sind 2008 R2 Enterprise Server)
(...) Linuxmaschinen, Clients und Testsysteme
- Server 8: Sharepoint (2008 R2 Standard)
Zweitserver mit direkter Installation 2008 R2-Standard
- Fileserver für Windows-Backups (bradmin)
- zweit-DC für AD-Replikation
Vielen Dank für eure Zeit die Ihr alleine schon in das Lesen dieser Informationen steckt und möglicherweise auch Lösungsansätze oder denkanstöße..
Beste Grüße
Anaxagoras
Heute morgen war der Zugriff auf meinen Fileserver in der Domäne nicht mehr möglich. Die Fehlermeldung bei Zugiff auf die Shares sowie als ich mich direkt als Domänenadmin an die Maschine per RDP Anmelden wollte war: "Die Vertrauenssstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden".
Wir hatten in der Vergangenheit schon einmal Probleme mit dem Secure-Channel und dem DC.
Dieses mal scheint das Problem jedoch ein anderes zu sein. Nach einiger Recherche hier der erste Lösungsansatz:
1) Auf dem DC über die Kommandozeile:
- netdom.exe /reset /d: Domänenname.local Servername
- leider konnte ich den Befehl nicht erfolgreich ausführen, da ich die Rückmeldung erhielt: das der Zeilkontenname nicht verfügbar sei.
- Somit löschte ich das Computerkonto aus der AD und führte den o.g. Befehl erneut aus.
- Damit funktioniert zwar der generelle Zugriff, jedoch nur für ca. 25 Minuten.
- Danach musste ich den Server neu starten, da die Drucker und einige andere Dienste nicht funktionieren.
- Nach dem Neustart: Das gleiche Problem wieder..
2) zweiter Lösungsansatz:
- Server aus der Domäne entfernt.
- Server neu gestartet
- Server wieder in die Domäne genommen
- Server neu gestartet
- Test des Zugriffes: Drucker, Freigaben und WSUS wieder da.
- Problem: Ich kann das Computerkonto in meiner AD nicht finden.
- Es ist selbst nach zweimaligem neu-einbinden in die Domäne nicht sichtbar
3) Gerade habe ich noch einmal den Ereignislog des DCs durchgeschaut und folgendes Event gefunden:
- 1925 Warnung:
Protokollname: Directory Service
Quelle: Microsoft-Windows-ActiveDirectory_DomainService
Datum: 09.12.2011 12:05:31
Ereignis-ID: 1925
Aufgabenkategorie:Konsistenzprüfung
Ebene: Warnung
Schlüsselwörter:Klassisch
Benutzer: ANONYMOUS-ANMELDUNG
Computer: DC-Name.Domäne.local
Beschreibung:
Fehler beim Herstellen einer Replikationsverknüpfung mit der folgenden schreibbaren Verzeichnispartition.
Verzeichnispartition:
DC=Domäne,DC=local
Quellverzeichnisdienst:
CN=NTDS Settings,CN=GSGB01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=Domäne,DC=local
Adresse des Quellverzeichnisdienstes:
0be56632-ca1c-415b-af7b-e2d90904f981._msdcs.Domäne.local
Standortübergreifende Übertragung (falls vorhanden):
Dieser Verzeichnisdienst kann nicht mit dem Quellverzeichnisdienst replizieren, solange das Problem nicht behoben ist.
Benutzeraktion
Überprüfen Sie, ob auf den Quellverzeichnisdienst zugegriffen werden kann und ob eine Netzwerkverbindung besteht.
Zusätzliche Daten
Fehlerwert:
8453 Der Replikationszugriff wurde verweigert.
- Eine Recherche bez. der Eventid, brachte mich auf einen KB-Artikel: http://support.microsoft.com/kb/329860/de
Die Lösungansätze dieses Artikels:
- Schritt 1: Das Computerkonto in der Domain Controllers Container verschieben:
-- Check. DC ist in der OU: Domain Controllers
- Schritt 2: Überprüfen der UserAccountControl-Eigenschaft
-- Ich habe gerade den ADSI-Editor geöffnet und die entsprechenden Attributeigenschaften offen.
-- Der Wert der hier eingetragen ist, ist: 69632 nicht wie angegeben: 532480
-- Dieser Artikel bezieht sich jedoch auf einen Server 2000 nicht 2008 R2 und somit habe ich ein wenig Angst, das mir eine solche Änderung (gerade deshalb weil ich den Hintergrund dieses Wertes nicht begreife) Schaden an meiner AD verursacht.
-- Sollte ich diesen Wert verändern, oder lieber in Ruhe lassen?
- Schritt 3: Zurücksetzen des sicheren Kanals-Kennworts
-- Mit diesem Fehler haben/hatten wir in der Vergangenheit zu kämpfen und nach dem Zurücksetzen des Secure-Channel-Kennwortes mittels Microsoft-Support dachten wir, das Problem sei behoben. Leider scheint es sich aber wieder zu zeigen.
Bevor ich nun die letzten beiden Schritte durchführe, würde ich gerne auf eine Rückmeldung der geballten Kompetenz aus dem Administrationsbereich warten, auch deshalb weil wir ja "noch" arbeiten können. Um so tiefer ich jedoch in die Recherche steige, desto mehr Angst habe ich, dass mir das Komplette AD-Konstrukt nun "um die Ohren fliegt."
Zur Hilfestellung hier noch einige Zusatzinformationen:
IBM-Server mit VMWARE ESXi
- Virtuelle Maschinen:
- Server 1: DC
- Server 2: FS, WSUS, Printserver
- Server 3: Exchange-Server
- Server 4: Terminalserver
(alle vier sind 2008 R2 Enterprise Server)
(...) Linuxmaschinen, Clients und Testsysteme
- Server 8: Sharepoint (2008 R2 Standard)
Zweitserver mit direkter Installation 2008 R2-Standard
- Fileserver für Windows-Backups (bradmin)
- zweit-DC für AD-Replikation
Vielen Dank für eure Zeit die Ihr alleine schon in das Lesen dieser Informationen steckt und möglicherweise auch Lösungsansätze oder denkanstöße..
Beste Grüße
Anaxagoras
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 177508
Url: https://administrator.de/contentid/177508
Ausgedruckt am: 05.11.2024 um 04:11 Uhr
3 Kommentare
Neuester Kommentar
moin,
wär ja nicht mein erster Schritt....
Autsch...
Mach doch zuerst die banalen Sachen - bevor du an ADSEdit denkst...
STOP...
1) Auf dem DC über die Kommandozeile:
- netdom.exe /reset /d: Domänenname.local Servernamewär ja nicht mein erster Schritt....
- an welchem DC wäre ich denn angemeldet
- ping kreuz und quer
- Uhrzeitenvergleich
- Dienste anschauen
- nslookup
2) zweiter Lösungsansatz:
- Server aus der Domäne entfernt.Autsch...
Mach doch zuerst die banalen Sachen - bevor du an ADSEdit denkst...