M4rt1n 1 Geschrieben 1. März Melden Teilen Geschrieben 1. März (bearbeitet) 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 Zitieren Link zu diesem Kommentar
cj_berlin 1.329 Geschrieben 1. März Melden Teilen Geschrieben 1. März Scheint DNS zu sein. Zitieren Link zu diesem Kommentar
M4rt1n 1 Geschrieben 1. März Autor Melden Teilen Geschrieben 1. März (bearbeitet) 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 Zitieren Link zu diesem Kommentar
Nobbyaushb 1.475 Geschrieben 1. März Melden Teilen Geschrieben 1. März 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... Zitieren Link zu diesem Kommentar
M4rt1n 1 Geschrieben 1. März Autor Melden Teilen Geschrieben 1. März 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. Zitieren Link zu diesem Kommentar
M4rt1n 1 Geschrieben 1. März Autor Melden Teilen Geschrieben 1. März 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. Zitieren Link zu diesem Kommentar
Nobbyaushb 1.475 Geschrieben 1. März Melden Teilen Geschrieben 1. März Von DFS war im ersten Post auch nicht die Rede… Zitieren Link zu diesem Kommentar
M4rt1n 1 Geschrieben 1. März Autor Melden Teilen Geschrieben 1. März (bearbeitet) 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 Zitieren Link zu diesem Kommentar
daabm 1.366 Geschrieben 1. März Melden Teilen Geschrieben 1. März 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. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.