Client hat temporär Zugriffsprobleme auf Server im AD

[M4rt1n 0]

Hallo,

 

erstmal die Vorgeschichte, es gab vor 4 Wochen einen Wechsel des DCs von 2012 auf 2022. Mittlerweile gibt es 2 DCs (beide Server 2022) die nach Best Practice konfiguriert sind.

 

Zum aktuellen Problem: bei einem Client im AD fangen ca. 1-2 Stunden nach dem Hochfahren Zugriffsprobleme auf den Server an. Das äußert sich z.B. darin dass beim öffnen einer pptx Datei Powerpoint startet und in dem Infofenster steht: "Kontaktaufnahme \\server\freigabe\datei" Dann dauert es länger als normal und Word/Excel/PPT stürzen dann auch manchmal ab. Der Client wurde letzte Woche erneut in die Domäne aufgenommen (ohne Besserung).

 

In der Ereignissanzeige kann ich sehen dass in den ersten 1-2 Stunden alles OK ist, dann kommen folgende Einträge, die sich später auch wiederholen:

 

Das Sicherheitssystem hat einen Authentifizierungsfehler für den Server NT Authority\SYSTEM festgestellt. Der Fehlercode des Authentifizierungsprotokolls Kerberos lautete "Für die Authentifizierung war keine Autorität erreichbar.
 (0x80090311)".
 
 
 Fehler bei der Verarbeitung der Gruppenrichtlinie. Es wurde versucht, neue Gruppenrichtlinieneinstellungen für diesen Benutzer oder Computer abzurufen. Den Fehlercode und eine Beschreibung finden Sie auf der Registerkarte "Details". Dieser Vorgang wird automatisch beim nächsten Aktualisierungszyklus wiederholt. Computer, die der Domäne beigetreten sind, müssen über eine geeignete Namensauflösung sowie über eine Netzwerkverbindung zu einem Domänencontroller zum Ermitteln von neuen Gruppenrichtlinienobjekten und -einstellungen verfügen. Wenn die Gruppenrichtlinie erfolgreich ist, wird ein Ereignis protokolliert.
 
 Die Gruppenrichtlinieneinstellungen für den Benutzer wurden erfolgreich verarbeitet. Es wurden keine Änderungen seit der letzten erfolgreichen Gruppenrichtlinienverarbeitung erkannt.
 
 Das Sicherheitssystem hat einen Authentifizierungsfehler für den Server cifs/serverhostname festgestellt. Der Fehlercode des Authentifizierungsprotokolls Kerberos lautete "Für die Authentifizierung war keine Autorität erreichbar.
 
 

 

Es scheint ein Problem mit WinRM / Kerberos zu geben.

 

Ich habe auf den Clients folgendes ausgeführt:

 

  winrm s winrm/config/client '@{TrustedHosts="serverhostname"}'
WSManFault/let'{rseHss"F-C.eiin0ln}
    Message = Der Client kann keine Verbindung mit dem in der Anforderung angegebenen Ziel herstellen. Stellen Sie sicher, dass der Dienst auf dem Ziel ausgef³hrt wird und die Anforderungen akzeptiert. Lesen Sie die Protokolle und die Dokumentation f³r den WS-Verwaltungsdienst, der auf dem Ziel ausgef³hrt wird. Hierbei handelt es sich meistens um IIS oder WinRM. Wenn das Ziel der WinRM-Dienst ist, f³hren Sie den folgenden Befehl auf dem Ziel aus, um den WinRM-Dienst zu analysieren und zu konfigurieren: "winrm quickconfig".

Fehlernummer:  -2144108526 0x80338012
Der Client kann keine Verbindung mit dem in der Anforderung angegebenen Ziel herstellen. Stellen Sie sicher, dass der Dienst auf dem Ziel ausgef³hrt wird und die Anforderungen akzeptiert. Lesen Sie die Protokolle und die Dokumentation f³r den WS-Verwaltungsdienst, der auf dem Ziel ausgef³hrt wird. Hierbei handelt es sich meistens um IIS oder WinRM. Wenn das Ziel der WinRM-Dienst ist, f³hren Sie den folgenden Befehl auf dem Ziel aus, um den WinRM-Dienst zu analysieren und zu konfigurieren: "wi



winrm enumerate winrm/config/listener
ir nmrt ir/ofi/lstnr
WSManFault
    Message = Der Client kann keine Verbindung mit dem in der Anforderung angegebenen Ziel herstellen. Stellen Sie sicher, dass der Dienst auf dem Ziel ausgef³hrt wird und die Anforderungen akzeptiert. Lesen Sie die Protokolle und die Dokumentation f³r den WS-Verwaltungsdienst, der auf dem Ziel ausgef³hrt wird. Hierbei handelt es sich meistens um IIS oder WinRM. Wenn das Ziel der WinRM-Dienst ist, f³hren Sie den folgenden Befehl auf dem Ziel aus, um den WinRM-Dienst zu analysieren und zu konfigurieren: "winrm quickconfig".

Fehlernummer:  -2144108526 0x80338012
Der Client kann keine Verbindung mit dem in der Anforderung angegebenen Ziel herstellen. Stellen Sie sicher, dass der Dienst auf dem Ziel ausgef³hrt wird und die Anforderungen akzeptiert. Lesen Sie die Protokolle und die Dokumentation f³r den WS-Verwaltungsdienst, der auf dem Ziel ausgef³hrt wird. Hierbei handelt es sich meistens um IIS oder WinRM. Wenn das Ziel der WinRM-Dienst ist, f³hren Sie den folgenden Befehl auf dem Ziel aus, um den WinRM-Dienst zu analysieren und zu konfigurieren: "wi

 

Get-ChildItem -Path WSMan:\localhost\Client\Auth
Get-ChildItem: Cannot find path 'localhost\Client\Auth' because it does not exist.

 

Auch merkwürdig, wenn ich auf dem Client "net time" unter einer Admin CMD shell ausführe, kommt "Zugriff verweigert".

 

 

Auf dem Server scheint alles OK zu sein (Firewall Port ist offen):

 

Get-ChildItem -Path WSMan:\localhost\Service\Auth                                                                                                                                                                       
   WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Service\Auth

Type            Name                           SourceOfValue   Value
----            ----                           -------------   -----
System.String   Basic                                          false
System.String   Kerberos                                       true
System.String   Negotiate                                      true
System.String   Certificate                                    false
System.String   CredSSP                                        false
System.String   CbtHardeningLevel                              Relaxed

 

winrm enumerate winrm/config/listener
Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, 192.168.30.1, ::1

Habt ihr eine Idee was das Problem ist?

bearbeitet 1. März von M4rt1n

[cj_berlin 1.138]

Scheint DNS zu sein.

[M4rt1n 0]

Da konnte ich aber keine Fehler feststellen, nur dass Reverse Lookup von Clients, die im VPN sind, funktioniert nicht. Der Fehler trat aber auch auf als der betroffene Client im Büro war.

 

nslookup DC-Hostname
Server:  DC-Hostname.LocalDomain
Address:  192.168.30.1

Name:    DC-Hostname.LocalDomain
Address:  192.168.30.1



nslookup host-10
Server:  DC-Hostname.LocalDomain
Address:  192.168.30.1

Name:    host-10.LocalDomain
Address:  10.99.0.26



nslookup 10.99.0.26
Server:  DC-Hostname.LocalDomain
Address:  192.168.30.1

*** 10.99.0.26 wurde von DC-Hostname.LocalDomain nicht gefunden: Non-existent domain.


nslookup host-01
Server:  DC-Hostname.LocalDomain
Address:  192.168.30.1

Name:    host-01.LocalDomain
Address:  192.168.30.159



nslookup 192.168.30.159
Server:  DC-Hostname.LocalDomain
Address:  192.168.30.1

Name:    host-01.LocalDomain
Address:  192.168.30.159

 

Unter Server-Manager -> DNS -> Best practices analyser steht u.a.

 

DC-Hostname Warnung DNS: Stammhinweisserver 198.32.64.12 muss auf NS-Abfragen für die Stammzone reagieren.
DC-Hostname Warnung DNS: Stammhinweisserver 128.63.2.53 muss auf NS-Abfragen für die Stammzone reagieren.
DC-Hostname Warnung DNS: Stammhinweisserver 128.9.0.107 muss auf NS-Abfragen für die Stammzone reagieren.

 

 

Ich habe die betroffenen Server nach der Liste der iana.org aktualisiert, jetzt mal schauen...

bearbeitet 1. März von M4rt1n

[Nobbyaushb 1.359]

OT/ Ein DC bekommt nie die IP .1 oder .255

/OT off

Hast du bei den Stammservern mal die IP-Adressen geprüft?

Wir leider oft vergessen - geht natürlich nur, wenn der DC im Internet fragen darf...

[M4rt1n 0]

vor 2 Minuten schrieb Nobbyaushb:

OT/ Ein DC bekommt nie die IP .1 oder .255

/OT off

Hast du bei den Stammservern mal die IP-Adressen geprüft?

Wir leider oft vergessen - geht natürlich nur, wenn der DC im Internet fragen darf...

Ja, die voreingestellten aus der Liste vom BPA konnten nicht aufgelöst werden, die korrigierten funktionieren jetzt.

[M4rt1n 0]

Daran hat's nicht gelegenen, allerdings tritt der Fehler nicht auf wenn ich direkt auf den Server zugreife und nicht über den DFS Namen. Werde das mal überprüfen und ggf. alles wieder auf Servernamen umstellen.

[Nobbyaushb 1.359]

Von DFS war im ersten Post auch nicht die Rede…

[M4rt1n 0]

Ja das stimmt, also in dem Infofenster stand immer: "Kontaktaufnahme \\DFS-Share\Ordner"

 

Auf dem DC gibt es im Ereignisprotokoll keine Hinweise dass mit dem DFS Share etwas nicht stimmt. An Dokumentenvorlagen, die auf einen alten Server verweisen, kann es auch nicht liegen, da sich der Hostname bisher nicht geändert hat.

bearbeitet 1. März von M4rt1n

[daabm 1.185]

Bin bei @cj_berlin

 

# for hex 0x80090311 / decimal -2146893039 :
  SEC_E_NO_AUTHENTICATING_AUTHORITY                             winerror.h     
# No authority could be contacted for authentication.
 

 

Da klappt was mit DNS nicht. Oder die NW-Verbindung von dem Client hat ein Problem.