6
Clients verlieren Verbindung zur Domäne
Hallo zusammen,
ich habe hier ein kleines Netzwerk mit einem DC und 18 Clients. Der Server hat nun das Problem, dass die Clients die Verbindung verlieren. Am 2012 R2 wurde abgesehen von Updates nichts gemacht. Im Syslog habe ich immer folgende Einträge:
Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "pc07$" empfangen. Der verwendete Zielname war cifs/PC14.GLASERSAXERKELLER.local. 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 (GLASERSAXERKELLER.LOCAL) von der Clientdomäne (GLASERSAXERKELLER.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.
Natürlich habe ich erst mal google gefragt. DCDIAG ergibt leider auch keinen Fehler:
Ich bin leider etwas mit meinem Latein am Ende. Hat eventuell jemand einen Anhaltspunkt? Im DHCP habe ich auch keine doppelten Einträge.
ich habe hier ein kleines Netzwerk mit einem DC und 18 Clients. Der Server hat nun das Problem, dass die Clients die Verbindung verlieren. Am 2012 R2 wurde abgesehen von Updates nichts gemacht. Im Syslog habe ich immer folgende Einträge:
Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "pc07$" empfangen. Der verwendete Zielname war cifs/PC14.GLASERSAXERKELLER.local. 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 (GLASERSAXERKELLER.LOCAL) von der Clientdomäne (GLASERSAXERKELLER.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.
Natürlich habe ich erst mal google gefragt. DCDIAG ergibt leider auch keinen Fehler:
Verzeichnisserverdiagnose
Anfangssetup wird ausgeführt:
Der Homeserver wird gesucht...
Homeserver = SRVDC
* Identifizierte AD-Gesamtstruktur.
Sammeln der Ausgangsinformationen abgeschlossen.
Erforderliche Anfangstests werden ausgeführt.
Server wird getestet: Default-First-Site-Name\SRVDC
Starting test: Connectivity
......................... SRVDC hat den Test Connectivity bestanden.
Primärtests werden ausgeführt.
Server wird getestet: Default-First-Site-Name\SRVDC
Starting test: Advertising
......................... SRVDC hat den Test Advertising bestanden.
Starting test: FrsEvent
......................... SRVDC hat den Test FrsEvent bestanden.
Starting test: DFSREvent
Für den Zeitraum der letzten 24 Stunden seit Freigabe des SYSVOL sind
Warnungen oder Fehlerereignisse vorhanden. Fehler bei der
SYSVOL-Replikation können Probleme mit der Gruppenrichtlinie zur Folge
haben.
......................... Der Test DFSREvent für SRVDC ist
fehlgeschlagen.
Starting test: SysVolCheck
......................... SRVDC hat den Test SysVolCheck bestanden.
Starting test: KccEvent
......................... SRVDC hat den Test KccEvent bestanden.
Starting test: KnowsOfRoleHolders
......................... SRVDC hat den Test KnowsOfRoleHolders
bestanden.
Starting test: MachineAccount
......................... SRVDC hat den Test MachineAccount bestanden.
Starting test: NCSecDesc
......................... SRVDC hat den Test NCSecDesc bestanden.
Starting test: NetLogons
......................... SRVDC hat den Test NetLogons bestanden.
Starting test: ObjectsReplicated
......................... SRVDC hat den Test ObjectsReplicated
bestanden.
Starting test: Replications
......................... SRVDC hat den Test Replications bestanden.
Starting test: RidManager
......................... SRVDC hat den Test RidManager bestanden.
Starting test: Services
......................... SRVDC hat den Test Services bestanden.
Starting test: SystemLog
Warnung. Ereignis-ID: 0x0000008E
Erstellungszeitpunkt: 05/08/2018 11:54:07
Ereigniszeichenfolge:
Der Zeitdienst wird nicht mehr als Zeitquelle angekündigt, da die lokale Systemuhr nicht synchronisiert ist.
......................... SRVDC hat den Test SystemLog bestanden.
Starting test: VerifyReferences
......................... SRVDC hat den Test VerifyReferences
bestanden.
Partitionstests werden ausgeführt auf: ForestDnsZones
Starting test: CheckSDRefDom
......................... ForestDnsZones hat den Test CheckSDRefDom
bestanden.
Starting test: CrossRefValidation
......................... ForestDnsZones hat den Test
CrossRefValidation bestanden.
Partitionstests werden ausgeführt auf: DomainDnsZones
Starting test: CheckSDRefDom
......................... DomainDnsZones hat den Test CheckSDRefDom
bestanden.
Starting test: CrossRefValidation
......................... DomainDnsZones hat den Test
CrossRefValidation bestanden.
Partitionstests werden ausgeführt auf: Schema
Starting test: CheckSDRefDom
......................... Schema hat den Test CheckSDRefDom bestanden.
Starting test: CrossRefValidation
......................... Schema hat den Test CrossRefValidation
bestanden.
Partitionstests werden ausgeführt auf: Configuration
Starting test: CheckSDRefDom
......................... Configuration hat den Test CheckSDRefDom
bestanden.
Starting test: CrossRefValidation
......................... Configuration hat den Test
CrossRefValidation bestanden.
Partitionstests werden ausgeführt auf: GLASERSAXERKELLER
Starting test: CheckSDRefDom
......................... GLASERSAXERKELLER hat den Test CheckSDRefDom
bestanden.
Starting test: CrossRefValidation
......................... GLASERSAXERKELLER hat den Test
CrossRefValidation bestanden.
Unternehmenstests werden ausgeführt auf: GLASERSAXERKELLER.local
Starting test: LocatorCheck
......................... GLASERSAXERKELLER.local hat den Test
LocatorCheck bestanden.
Starting test: Intersite
......................... GLASERSAXERKELLER.local hat den Test
Intersite bestanden.Ich bin leider etwas mit meinem Latein am Ende. Hat eventuell jemand einen Anhaltspunkt? Im DHCP habe ich auch keine doppelten Einträge.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 373359
Url: https://administrator.de/forum/clients-verlieren-verbindung-zur-domaene-373359.html
Ausgedruckt am: 22.04.2025 um 13:04 Uhr
6 Kommentare
Neuester Kommentar
Hallo,
Endlich deinen ellenlangen unnutzer Text geschafft durch zu tickern. Bitte lasse soetwas sein.
http://devel.itsolution2.de/wordpress/2012/07/15/493/
Gruß,
Peter
Endlich deinen ellenlangen unnutzer Text geschafft durch zu tickern. Bitte lasse soetwas sein.
Im Syslog habe ich immer folgende Einträge:
In Windows gibt es keine Syslog Server und eher keine Syslogmeldungen. Da gibt es Ereignissprotokolle. Und dieses haben alle eine Event ID im Text. Die ist wichtig sowie die Eventquelle.Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server
Schon mal danach in dein Internet gesucht?http://devel.itsolution2.de/wordpress/2012/07/15/493/
Ich bin leider etwas mit meinem Latein am Ende.
Das English schon als Latein bezeichnet wird Gruß,
Peter
Moin,
unabhängig von deinem Problem würde ich den Firmen bzw. Domänennamen unkenntlich machen...
Viele Grüße,
MOS
unabhängig von deinem Problem würde ich den Firmen bzw. Domänennamen unkenntlich machen...
Viele Grüße,
MOS
Zitat von @MOS6581:
Moin,
unabhängig von deinem Problem würde ich den Firmen bzw. Domänennamen unkenntlich machen...
Viele Grüße,
MOS
Moin,
unabhängig von deinem Problem würde ich den Firmen bzw. Domänennamen unkenntlich machen...
Viele Grüße,
MOS
Und im Anschluss die Uhrzeit des DC prüfen
1
Mahlzeit,
zuerst mal die Uhrzeit prüfen. Der DC sollte unbedingt der Zeitserver für die Clients sein. Selbst kann er sich ja die richtige Zeit von einem Online-Zeitserver holen (bspw. de.pool.ntp.org).
Dann DNS prüfen. Sind die Einstellungen beim Client korrekt.
Findest du per nslookup den Server und andere Geräte?
Schau mal hier rein: Googlen kann helfen
zuerst mal die Uhrzeit prüfen. Der DC sollte unbedingt der Zeitserver für die Clients sein. Selbst kann er sich ja die richtige Zeit von einem Online-Zeitserver holen (bspw. de.pool.ntp.org).
Dann DNS prüfen. Sind die Einstellungen beim Client korrekt.
Findest du per nslookup den Server und andere Geräte?
im DHCP habe ich auch keine doppelten Einträge.
Nicht im DHCP suchen, sondern im DNS.Schau mal hier rein: Googlen kann helfen
Moin,
lg,
Slainte
... abgesehen von Updates nichts gemacht. ...
Das war bisher heute der beste Spruch unabhängig von deinem Problem würde ich den Firmen bzw. Domänennamen unkenntlich machen...
Ob so ein Forenpost in der Lage ist den Aktivenkurs nachträglich zu beeinflussen? ::Plg,
Slainte
Hallo zusammen,
Oh doch. Das ist ein ganz fataler Fehler. Bei Kerberos-Fehlfunktionen immer als erstes prüfen, ob die Uhren der beteiligten Rechner synchron sind, da Kerberos bei einer Abweichung von mehr als fünf Minuten nicht mehr funktioniert.
hth
Erik
Natürlich habe ich erst mal google gefragt. DCDIAG ergibt leider auch keinen Fehler:
Verzeichnisserverdiagnose
> Ereigniszeichenfolge:
>
> Der Zeitdienst wird nicht mehr als Zeitquelle angekündigt, da die lokale Systemuhr nicht synchronisiert ist.Oh doch. Das ist ein ganz fataler Fehler. Bei Kerberos-Fehlfunktionen immer als erstes prüfen, ob die Uhren der beteiligten Rechner synchron sind, da Kerberos bei einer Abweichung von mehr als fünf Minuten nicht mehr funktioniert.
hth
Erik
