9
Vertrauensstellung konnte nicht hergestellt werden
Hallo zusammen,
vermutlich seit ich auf Hyper-V als Hypervisor setze, habe ich bei einigen Workstations (Windows 10) und Servern (Server 2012R2) sporadisch folgende Fehlermeldung beim Anmelden:
Was diese Fehlermeldung aussagt ist mir bekannt, allerdings kann ich das beim besten Willen nicht nachvollziehen.
- Die Uhrzeit wird korrekt zwischen DC und Client synchronisiert
- Netzwerkverbindung ist stabil
- Der DC (SBS) ist ebenfalls virtualisiert
- Das Problem tritt absolut sporadisch auf. Habe es noch nicht reproduzieren können
- Die DNS Server funktionieren problemlos
- Reset-ComputerMachinePasswort bringt zum Teil kurzzeitig Besserung (manchmal bis zum nächsten Neustart, manchmal für x Wochen)
- Passende Ereignislogs habe ich noch nicht ausfindig machen können. Immer nur Folgefehler weil die Verbindung nicht mehr steht.
An was könnte es noch haken?
vermutlich seit ich auf Hyper-V als Hypervisor setze, habe ich bei einigen Workstations (Windows 10) und Servern (Server 2012R2) sporadisch folgende Fehlermeldung beim Anmelden:
Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden.Was diese Fehlermeldung aussagt ist mir bekannt, allerdings kann ich das beim besten Willen nicht nachvollziehen.
- Die Uhrzeit wird korrekt zwischen DC und Client synchronisiert
- Netzwerkverbindung ist stabil
- Der DC (SBS) ist ebenfalls virtualisiert
- Das Problem tritt absolut sporadisch auf. Habe es noch nicht reproduzieren können
- Die DNS Server funktionieren problemlos
- Reset-ComputerMachinePasswort bringt zum Teil kurzzeitig Besserung (manchmal bis zum nächsten Neustart, manchmal für x Wochen)
- Passende Ereignislogs habe ich noch nicht ausfindig machen können. Immer nur Folgefehler weil die Verbindung nicht mehr steht.
An was könnte es noch haken?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 391050
Url: https://administrator.de/contentid/391050
Ausgedruckt am: 21.11.2024 um 19:11 Uhr
9 Kommentare
Neuester Kommentar
Hallo Androxin,
Interne und externe Domaene zufällig gleich? Split DNS nicht richtig konfiguriert?
DNS Settings auf den Clients geprüft?
Die sollten alle auf den SBS zeigen und keine externen DNS Server enthalten...
Vielleicht hilft dass ja schon
Gruß
Interne und externe Domaene zufällig gleich? Split DNS nicht richtig konfiguriert?
DNS Settings auf den Clients geprüft?
Die sollten alle auf den SBS zeigen und keine externen DNS Server enthalten...
Vielleicht hilft dass ja schon
Gruß
Guten morgen,
einmal mit den Blechen aus der Domain raus, und wieder rein... dann sollte der spuk weg sein!
Frank
einmal mit den Blechen aus der Domain raus, und wieder rein... dann sollte der spuk weg sein!
Frank
Hi,
E.
Zitat von @Vision2015:
einmal mit den Blechen aus der Domain raus, und wieder rein... dann sollte der spuk weg sein!
Das hat TO doch mit Reset-ComputerMachinePasswort praktisch schon versucht.einmal mit den Blechen aus der Domain raus, und wieder rein... dann sollte der spuk weg sein!
E.
Zitat von @sleaper:
Interne und externe Domaene zufällig gleich? Split DNS nicht richtig konfiguriert?
Das hat nichts mit Domänen-Vertrauensstellungen zu tun, sondern mit jener zwischen Domäne und Mitglied.Interne und externe Domaene zufällig gleich? Split DNS nicht richtig konfiguriert?
Die betreffenden Workstations sind also auch virtualisiert?
Betrifft das alle VM oder nur manche? Und hast Du noch Bleche? Falls ja, sind davon auch welche betroffen?
Betrifft das alle VM oder nur manche? Und hast Du noch Bleche? Falls ja, sind davon auch welche betroffen?
- Passende Ereignislogs habe ich noch nicht ausfindig machen können. Immer nur Folgefehler weil die Verbindung nicht mehr steht.
Die würde ich auch auf den DC's suchen. Und zwar immer dann, wenn Du einen konkreten Fall hast. Dann jeweils im Sichrheits-Log der DC's und des Member nachsehen.
Hallo,
2 PC's mit dem selben Namen?
2 PC's mit dem selben Namen?
Guten Morgen zusammen,
vielen Dank für die vielen Rückmeldungen. Ich versuche das mal zu sortieren:
vielen Dank für die vielen Rückmeldungen. Ich versuche das mal zu sortieren:
- Mit dem DNS scheint alles in Ordnung zu sein. Zumindest hatte ich damit noch nie Probleme. Es sind keine externen DNS Server hinterlegt.
- Hab auch schon Workstations aus der Domäne entfernt und wieder hinzugefügt. Ebenfalls nur temporäre Besserung wie bei Reset-ComputerMachinePassword.
- Ich habe einen betroffenen Computer sogar mal aus der Domäne genommen, "gesysprepped" und wieder hinzugefügt. Auch hier nur temporäre Besserung.
- Es betrifft alle Arten von Systemen: Windows 10 auf Blech und als VM, Windows Server 2012R2 als VM, Windows Server 2016 als Hyper-V Blech.
- Es gibt definitiv keine Computer mit den selben Namen und kopierte VMs wurden stets einem sysprep unterzogen bevor sie der Domäne hinzugefügt wurden
- Ich werde mal Versuchen die Ereignislogs auseinander zu nehmen. Vielleicht finde ich ja etwas auf dem DC.
Hallo zusammen,
ich habe jetzt tatsächlich eine Fehlermeldung ausgraben können, die ansatzweise in die richtige Richtung gehen könnte, zumindest konnte ich mich ca. 30 Minuten später nicht an dem Windows Server 2012R2 anmelden:
Kann mir das jemand deuten?
Nachtrag: Test-ComputerSecureChannel zeigt TRUE an. Ich hätte jetzt erwartet, dass da FALSE rauskommt?!
ich habe jetzt tatsächlich eine Fehlermeldung ausgraben können, die ansatzweise in die richtige Richtung gehen könnte, zumindest konnte ich mich ca. 30 Minuten später nicht an dem Windows Server 2012R2 anmelden:
Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "srv-lab-01$" empfangen. Der verwendete Zielname war SRV-LAB-01$. Dies deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token nicht entschlüsseln konnte. Dies kann auftreten, wenn der Ziel-Serverprinzipalname (SPN) nicht bei dem Konto registriert ist, das der Zieldienst verwendet. Stellen Sie sicher, dass der Ziel-SPN nur bei dem Konto registriert ist, das vom Server verwendet wird. Dieser Fehler kann auch auftreten, wenn das Kennwort für das Zieldienstkonto nicht mit dem Kennwort übereinstimmt, das im Kerberos-KDC (Key Distribution Center) für den Zieldienst konfiguriert ist. Stellen Sie sicher, dass der Dienst auf dem Server und im KDC beide für die Verwendung des gleichen Kennworts konfiguriert sind. Wenn der Servername nicht vollqualifiziert ist und sich die Zieldomäne (TESTLAB.LOCAL) von der Clientdomäne (TESTLAB.LOCAL) unterscheidet, prüfen Sie, ob sich in diesen beiden Domänen Serverkonten mit gleichem Namen befinden, oder verwenden Sie den vollqualifizierten Namen, um den Server zu identifizieren. Kann mir das jemand deuten?
Nachtrag: Test-ComputerSecureChannel zeigt TRUE an. Ich hätte jetzt erwartet, dass da FALSE rauskommt?!
Moin zusammen,
Problem gelöst.
Es war mal wieder ganz einfach:
Da die gesamte betroffene Umgebung Teil einer Test-Infrastruktur ist, wurde dort natürlich auch getestet. Übersehen habe ich, dass jemand zum Spielen einen zweiten DC aufgesetzt hat. *facepalm
Und dieser hatte natürlich Probleme bei der Replikation.
Die betroffenen Clients haben sich daher fröhlich mal mit dem einen, mal mit dem anderen DC verbunden. "Reset-ComputerMachinePasswort" hat dann zwar wunderbar auf den SBS eingewirkt, der andere DC hat davon aber nichts mitbekommen. Bei einem der folgenden Anmeldeversuche an dem zweiten DC, kam es deshalb wieder zu dem beschriebenen Fehler.
Die Lösung war natürlich entsprechend einfach: Den zweiten DC rausschmeißen/herabstufen und die Metadaten auf dem SBS bereinigen.
Problem gelöst.
Es war mal wieder ganz einfach:
Da die gesamte betroffene Umgebung Teil einer Test-Infrastruktur ist, wurde dort natürlich auch getestet. Übersehen habe ich, dass jemand zum Spielen einen zweiten DC aufgesetzt hat. *facepalm
Und dieser hatte natürlich Probleme bei der Replikation.
Die betroffenen Clients haben sich daher fröhlich mal mit dem einen, mal mit dem anderen DC verbunden. "Reset-ComputerMachinePasswort" hat dann zwar wunderbar auf den SBS eingewirkt, der andere DC hat davon aber nichts mitbekommen. Bei einem der folgenden Anmeldeversuche an dem zweiten DC, kam es deshalb wieder zu dem beschriebenen Fehler.
Die Lösung war natürlich entsprechend einfach: Den zweiten DC rausschmeißen/herabstufen und die Metadaten auf dem SBS bereinigen.
