10
RDP Anmeldeversuch fehlgeschlagen
Hallo zusammen,
wir haben hier seit einigen Tagen ein Problem mit RDP und können es nicht richtig einordnen.
Trotz korrektem Benutzernamen und Passwort, kommt die Meldung "Anmeldeversuch ist fehlgeschlagen".
Manchmal hilft ein Neustart, manchmal auch nicht. Es kann auch sein, dass am nächsten Tag weider alles funktioniert.
Was immer funktioniert ist der Eintrag enablecredsspsupport:i:0 in der RDP-Datei.
Das hilft aber nur bedingt um alle Server zu verwalten. Dafür nutzen wir momentan den RDC Manager, da kann man den Eintrag nicht setzen.
Jemand eine Idee wo das Problem sein könnte?
Client(s) Win10 22H2
Server 2016 oder 2019, bei älteren Versionen ist mir das noch nicht aufgefallen.
Vielen Dank
Thorsten
wir haben hier seit einigen Tagen ein Problem mit RDP und können es nicht richtig einordnen.
Trotz korrektem Benutzernamen und Passwort, kommt die Meldung "Anmeldeversuch ist fehlgeschlagen".
Manchmal hilft ein Neustart, manchmal auch nicht. Es kann auch sein, dass am nächsten Tag weider alles funktioniert.
Was immer funktioniert ist der Eintrag enablecredsspsupport:i:0 in der RDP-Datei.
Das hilft aber nur bedingt um alle Server zu verwalten. Dafür nutzen wir momentan den RDC Manager, da kann man den Eintrag nicht setzen.
Jemand eine Idee wo das Problem sein könnte?
Client(s) Win10 22H2
Server 2016 oder 2019, bei älteren Versionen ist mir das noch nicht aufgefallen.
Vielen Dank
Thorsten
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 4970682442
Url: https://administrator.de/contentid/4970682442
Printed on: April 27, 2024 at 21:04 o'clock
10 Comments
Latest comment
Moin,
betrifft das
Client = User oder PC-Client)
Wenn es nur manche Clients = User betrifft: mal im lokalen Tresor geschaut, ob dort "Mist" gespeichert ist?
betrifft das
- spezielle Clients an allen Servern?
- alle Clients an manchen Servern?
- alle Clients an allen Servern?
Client = User oder PC-Client)
Wenn es nur manche Clients = User betrifft: mal im lokalen Tresor geschaut, ob dort "Mist" gespeichert ist?
Bei den einfachen Benutzern, die kaum RDP nutzen, weiß ich es nur von wenigen Clients.
Bei uns Admins betrifft es aktuell alle Notebooks.
Es betrifft nicht immer alle Clients und alle Server.
Nein, lokal sind keine Anmeldedaten gespeichert, schon geprüft.
Viele Grüße
Thorsten
Bei uns Admins betrifft es aktuell alle Notebooks.
Es betrifft nicht immer alle Clients und alle Server.
Nein, lokal sind keine Anmeldedaten gespeichert, schon geprüft.
Viele Grüße
Thorsten
INstalliere bitte auf den DCs die aktuellen (Dezember-) updates. Diese beheben Probeleme mit Kerberos, welche auch RDP-Probleme verursacht haben (seit November).
Guten Morgen,
das hat leider auch nicht geholfen.
Heute funktioniert RDP auf einige Server wieder, auf andere immer noch nicht.
Völlig verrückt, den Hyper Cluster Owner Node kann ich über seinen DNS Namen erreichen. Den Host-Server, der ja physisch die selbe Maschine ist, nicht.
D.h. RDP auf "ClusterNode" (IP 192.168.123.1) funktioniert, RDP auf "Host1" (IP 192.168.123.1) funktioniert nicht.
Viele Grüße
Thorsten
das hat leider auch nicht geholfen.
Heute funktioniert RDP auf einige Server wieder, auf andere immer noch nicht.
Völlig verrückt, den Hyper Cluster Owner Node kann ich über seinen DNS Namen erreichen. Den Host-Server, der ja physisch die selbe Maschine ist, nicht.
D.h. RDP auf "ClusterNode" (IP 192.168.123.1) funktioniert, RDP auf "Host1" (IP 192.168.123.1) funktioniert nicht.
Viele Grüße
Thorsten
Und auf Host1.deine.dom?
Gerade nach einem Neustart geht erstmal alles. Prüfe deinen Vorschlag wenn der Fehler nochmal auftritt.
Danke
Danke
Guten Morgen,
in unserer Umgebung treten genau die selben Probleme auf, wie Thorsten sie beschrieben hat.
Die Notlösung mit dem Eintrag: "enablecredsspsupport:i:0" kann bei uns nicht verwendet werden --> Der Remotecomputer erfordert Authentifizierung auf Netzwerkebene.
(Damit wird dem Client die Möglichkeit gegeben, sich zunächst auf den Server einzuloggen, ohne sich vorher authentifizieren zu müssen.)
Wir haben auf den Primary DC alle Updates installiert und auf den S-DC ist noch ein Neustart fällig.
Auf den DCs wird folgender Fehler vom Terminalserver angezeigt:
Quelle: Microsoft-Windows-Kerberos-Key-Distribution-Center
Ereignis-ID: 37
Beschreibung:
Das Schlüsselverteilungscenter (KDC) hat ein Ticket gefunden, das keine Informationen über das Konto enthielt, das das Ticket angefordert hat, während eine Anforderung für ein anderes Ticket verarbeitet wurde. Dies verhinderte die Ausführung von Sicherheitsüberprüfungen und konnte zu Sicherheitsrisiken führen.
Dazu habe ich unter Info Ereignis 35-37 einige Infos gefunden.
Leider tritt das Problem immer wieder auf.
Falls jemand hierzu noch weitere Informationen oder die Selben Probleme hat, dann gerne hier Posten.
Vielen Dank!
in unserer Umgebung treten genau die selben Probleme auf, wie Thorsten sie beschrieben hat.
Die Notlösung mit dem Eintrag: "enablecredsspsupport:i:0" kann bei uns nicht verwendet werden --> Der Remotecomputer erfordert Authentifizierung auf Netzwerkebene.
(Damit wird dem Client die Möglichkeit gegeben, sich zunächst auf den Server einzuloggen, ohne sich vorher authentifizieren zu müssen.)
Wir haben auf den Primary DC alle Updates installiert und auf den S-DC ist noch ein Neustart fällig.
Auf den DCs wird folgender Fehler vom Terminalserver angezeigt:
Quelle: Microsoft-Windows-Kerberos-Key-Distribution-Center
Ereignis-ID: 37
Beschreibung:
Das Schlüsselverteilungscenter (KDC) hat ein Ticket gefunden, das keine Informationen über das Konto enthielt, das das Ticket angefordert hat, während eine Anforderung für ein anderes Ticket verarbeitet wurde. Dies verhinderte die Ausführung von Sicherheitsüberprüfungen und konnte zu Sicherheitsrisiken führen.
Dazu habe ich unter Info Ereignis 35-37 einige Infos gefunden.
Leider tritt das Problem immer wieder auf.
Falls jemand hierzu noch weitere Informationen oder die Selben Probleme hat, dann gerne hier Posten.
Vielen Dank!
Leider haben wir nun auch das Problem. ( Beide DCs sind Srv2019 )
Willkürlich kann man sich auf diversen Servern nicht anmelden, Fehlermeldung gibt's keine......
Mit der IP geht es mit dem Servernamen geht's willkürlich...
Was heute mehrmals funktioniert hatte war die Anmeldung wie Folgt server.domain.local. wichtig ist der PUNKT am ende ohne macht er es nicht.
Willkürlich kann man sich auf diversen Servern nicht anmelden, Fehlermeldung gibt's keine......
Mit der IP geht es mit dem Servernamen geht's willkürlich...
Was heute mehrmals funktioniert hatte war die Anmeldung wie Folgt server.domain.local. wichtig ist der PUNKT am ende ohne macht er es nicht.
Zitat von @Brixar:
Was heute mehrmals funktioniert hatte war die Anmeldung wie Folgt server.domain.local. wichtig ist der PUNKT am ende ohne macht er es nicht.
*.local ist ja auch nicht besonders klug gewählt. Stichwort MDNS.Was heute mehrmals funktioniert hatte war die Anmeldung wie Folgt server.domain.local. wichtig ist der PUNKT am ende ohne macht er es nicht.
https://en.wikipedia.org/wiki/.local
Guten Morgen,
habt ihr in der Zwischenzeit die Ursache bzw. eine Lösung gefunden? Wir haben diese Woche in einer 2008er Domäne einen 2022er Server installiert (nur AD und DNS) und auf einem der beiden 2008er Server noch Updates installiert.
Jetzt haben wir dasselbe Problem...
habt ihr in der Zwischenzeit die Ursache bzw. eine Lösung gefunden? Wir haben diese Woche in einer 2008er Domäne einen 2022er Server installiert (nur AD und DNS) und auf einem der beiden 2008er Server noch Updates installiert.
Jetzt haben wir dasselbe Problem...
