10
Terminalserver Anmeldung über VPN nicht möglich
Guten Tag Zusammen
Zur Zeit habe ich ein Problem mit dem Terminalserver.
Und zwar kann man sich nicht auf den Server anmelden via VPN, ist man aber vor Ort oder auf einem anderen Server in der Domain funktioniert die Anmeldung Problemlos. Die MA arbeiten via RDP auf einem dem Terminalserver 2008 R2, dies funktioniert auch solange sie inhouse arbeiten, aber sobald sie von aussen arbeit wollen schlägt die Anmeldung fehl. Egal ob mit User oder Admin konto.
Die Domain Besten aus 3 DC (MAINSERVER, COMMSERVER, SQLSERVER) und diese Laufen auf 2 HyperV Servern ab.
Denkt ihr das die AD einen Schuss hat und neu aufgebaut werden muss?
Schräger Text ist aus dem Ereignisslog
Fehler beim Anmelden eines Kontos.
Ereigniss Fehler
Antragsteller:
Sicherheits-ID: NULL SID
Kontoname: -
Kontodomäne: -
Anmelde-ID: 0x0
Anmeldetyp: 3
Konto, für das die Anmeldung fehlgeschlagen ist:
Sicherheits-ID: NULL SID
Kontoname: [USER]
Kontodomäne: [ZIEL-DOMAIN]
Fehlerinformationen:
Fehlerursache: Die Domänen-SID ist inkonsistent.
Status: 0xc000006d
Unterstatus:: 0xc000019b
Prozessinformationen:
Aufrufprozess-ID: 0x0
Aufrufprozessname: -
Netzwerkinformationen:
Arbeitsstationsname: [REMOTE-PC]
Quellnetzwerkadresse: -
Quellport: -
Detaillierte Authentifizierungsinformationen:
Anmeldeprozess: NtLmSsp
Authentifizierungspaket: NTLM
Übertragene Dienste: -
Paketname (nur NTLM): -
Schlüssellänge: 0
Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde.
Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe".
Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk).
Die Felder für die Prozessinformationen geben den Prozess und das Konto an, für die die Anmeldung angefordert wurde.
Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. Der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben.
Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung.
- Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren.
- Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an.
- Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0.
Mit freundlichen Grüßen
Andi
Zur Zeit habe ich ein Problem mit dem Terminalserver.
Und zwar kann man sich nicht auf den Server anmelden via VPN, ist man aber vor Ort oder auf einem anderen Server in der Domain funktioniert die Anmeldung Problemlos. Die MA arbeiten via RDP auf einem dem Terminalserver 2008 R2, dies funktioniert auch solange sie inhouse arbeiten, aber sobald sie von aussen arbeit wollen schlägt die Anmeldung fehl. Egal ob mit User oder Admin konto.
Die Domain Besten aus 3 DC (MAINSERVER, COMMSERVER, SQLSERVER) und diese Laufen auf 2 HyperV Servern ab.
Denkt ihr das die AD einen Schuss hat und neu aufgebaut werden muss?
Schräger Text ist aus dem Ereignisslog
Fehler beim Anmelden eines Kontos.
Ereigniss Fehler
Antragsteller:
Sicherheits-ID: NULL SID
Kontoname: -
Kontodomäne: -
Anmelde-ID: 0x0
Anmeldetyp: 3
Konto, für das die Anmeldung fehlgeschlagen ist:
Sicherheits-ID: NULL SID
Kontoname: [USER]
Kontodomäne: [ZIEL-DOMAIN]
Fehlerinformationen:
Fehlerursache: Die Domänen-SID ist inkonsistent.
Status: 0xc000006d
Unterstatus:: 0xc000019b
Prozessinformationen:
Aufrufprozess-ID: 0x0
Aufrufprozessname: -
Netzwerkinformationen:
Arbeitsstationsname: [REMOTE-PC]
Quellnetzwerkadresse: -
Quellport: -
Detaillierte Authentifizierungsinformationen:
Anmeldeprozess: NtLmSsp
Authentifizierungspaket: NTLM
Übertragene Dienste: -
Paketname (nur NTLM): -
Schlüssellänge: 0
Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde.
Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe".
Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk).
Die Felder für die Prozessinformationen geben den Prozess und das Konto an, für die die Anmeldung angefordert wurde.
Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. Der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben.
Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung.
- Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren.
- Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an.
- Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0.
Mit freundlichen Grüßen
Andi
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: 300872
Url: https://administrator.de/contentid/300872
Ausgedruckt am: 05.11.2024 um 04:11 Uhr
10 Kommentare
Neuester Kommentar
Hi,
also erstens solltest Du Zitate (z.B. aus Eventlog-Medungen) kenntlich machen, damit man sie von Deinem Text unterscheiden kann.
Zweitens: Nein, nicht AD neu aufsetzen. Baust Du ein neues Haus, wenn das Fenster nur Samstags nicht aufgeht?
Wie weit kommt man denn noch, wenn man über VPN geht? Kann der VPN-Client den TS denn überhaupt erreichen?
E.
also erstens solltest Du Zitate (z.B. aus Eventlog-Medungen) kenntlich machen, damit man sie von Deinem Text unterscheiden kann.
Zweitens: Nein, nicht AD neu aufsetzen. Baust Du ein neues Haus, wenn das Fenster nur Samstags nicht aufgeht?
Wie weit kommt man denn noch, wenn man über VPN geht? Kann der VPN-Client den TS denn überhaupt erreichen?
E.
Ich nehme mal an, dass die Sicherheitseinstellung der RDP-Sitzungen etwas zu hoch sind und vom VPN nicht widergespiegelt werden.
Schau doch mal auf dem TS unter "konfiguration des Remotedesktop-Hosts", Eigenschaften von RDP-tcp.
Ist ein Haken bei "Nur Verbindungen von Computern zulassen, auf denen der Remotedesktop mit Authentifizierung auf Netzwerkebene ausgeführt wird." dann mach den mal raus.
Schau doch mal auf dem TS unter "konfiguration des Remotedesktop-Hosts", Eigenschaften von RDP-tcp.
Ist ein Haken bei "Nur Verbindungen von Computern zulassen, auf denen der Remotedesktop mit Authentifizierung auf Netzwerkebene ausgeführt wird." dann mach den mal raus.
Danke für die Rasche Antwort!
@emeriks
Habe den Text editiert, bitte entschuldige.
Ja da gebe ich die vollkommen recht. Wir durften diese IT so übernehmen und da hat vorher jemand schon gewaltig rumgebastelt. Vor 1-2 Monaten hatte das Problem das die DC nicht mehr Repliziert haben, dies konnte ich aber beheben.
Ja man kann den Server erreichen, sprich das Anmeldefenster erscheint, Benutzername und Passwort Eingabe ist möglich. Es kommt aber immer die Meldung: "Der Anmeldeversuch ist Fehlgeschlagen"
@beidermachtvongreyscull
Danke!
Haken ist nicht drin
@emeriks
Habe den Text editiert, bitte entschuldige.
Ja da gebe ich die vollkommen recht. Wir durften diese IT so übernehmen und da hat vorher jemand schon gewaltig rumgebastelt. Vor 1-2 Monaten hatte das Problem das die DC nicht mehr Repliziert haben, dies konnte ich aber beheben.
Ja man kann den Server erreichen, sprich das Anmeldefenster erscheint, Benutzername und Passwort Eingabe ist möglich. Es kommt aber immer die Meldung: "Der Anmeldeversuch ist Fehlgeschlagen"
@beidermachtvongreyscull
Danke!
Haken ist nicht drin
Hi,
Hat denn die Firewall/das VPN-Gateway irgendwelche Verweigerungen oder Fehler protokolliert?
LG
Hat denn die Firewall/das VPN-Gateway irgendwelche Verweigerungen oder Fehler protokolliert?
LG
Ha!
Das gleiche Problem hatte ich unlängst mit ipsec via Mikrotik.
Lösung des Problems in meinem Fall: fasttrack connections deaktivieren!
Andere mögliche Probleme: ist die MTU des VPN Tunnels korrekt eingestellt?
Wenn ein Router dazwischen versucht zu fragmentieren und die Packets haben das Do-Not-Fragment-Flag gesetzt wird dir die Verbindung fehlschlagen.
Lg
NACHTRAG:
Tja, nachgedacht mit Impulskraft während mit Warpgeschwindigkeit das Mundwerk / die Tastatur gelaufen ist.
Es ist zwar generell eine gute Idee zu checken, ob die MTUs beim VPN passen, habe jetzt aber noch einmal genauer in die Ereignislog-Anzeige hineingeschaut.
Fehlerursache: Die Domänen-SID ist inkonsistent. Darf ich davon ausgehen, dass du die Server im Hyper-V von einem Template einfach kopiert hast?
Wenn JA: Hast du SYSPREP laufen lassen?
lG
Mal 'ne ganz andere Frage: Kennt der Terminalserver eigentlich den Weg ins VPN?
und/oder der DNS-Server?! (und wird auf den in der VPN-Config bezug genommen?)
HG
Mark
HG
Mark
Hoi
@DopeEx1991
Habe ich angeschaut, aber nichts entdeckt. Sonnst sollten doch die anderen Server auch nicht via RDP errechbar sein. Es können sich nur die Benutzer nicht anmelden. Als lokaler Admin vom Server kann ich mich Anmelden. Zum Testen habe ich vom VPN in die LAN Zone alle Ports geöffnet, hat aber keinen unterschied gebracht.
@areanod
Gute Frage wie der MTU wert ist, dies muss ich Prüfen.
Ehm kann ich dir leider nicht sagen, da wir die IT dieser Firma übernommen haben war das soweit eingerichtet.
SYSREP müsste ich mal machen allenfalls.
@fa-jka
Sollte er eigentlich kennen. Überprüfe ich aber auch noch.
Komischerweise tritt das Problem erst seit kurzem auf. Vor ein paar Wochen war der Zugriff noch IO, also muss ja irgend was passiert sein in dieser zeit. Werde eure Vorschläge mal Prüfen bis ende Woche.
Danke an alle!
@DopeEx1991
Habe ich angeschaut, aber nichts entdeckt. Sonnst sollten doch die anderen Server auch nicht via RDP errechbar sein. Es können sich nur die Benutzer nicht anmelden. Als lokaler Admin vom Server kann ich mich Anmelden. Zum Testen habe ich vom VPN in die LAN Zone alle Ports geöffnet, hat aber keinen unterschied gebracht.
@areanod
Gute Frage wie der MTU wert ist, dies muss ich Prüfen.
Ehm kann ich dir leider nicht sagen, da wir die IT dieser Firma übernommen haben war das soweit eingerichtet.
SYSREP müsste ich mal machen allenfalls.
@fa-jka
Sollte er eigentlich kennen. Überprüfe ich aber auch noch.
Komischerweise tritt das Problem erst seit kurzem auf. Vor ein paar Wochen war der Zugriff noch IO, also muss ja irgend was passiert sein in dieser zeit. Werde eure Vorschläge mal Prüfen bis ende Woche.
Danke an alle!
@Bluebear89
Mit Anmeldefenster meinst Du den kleinen Dialog und nicht etwa ein Fenster, in welchem die Anmeldemaske des Servers zu sehen ist?
Mit Anmeldefenster meinst Du den kleinen Dialog und nicht etwa ein Fenster, in welchem die Anmeldemaske des Servers zu sehen ist?
Da noch nicht gelöst ?
Würde mich mal mit IP Adresse in RDP Fenster statt der DNS Adresse anmelden.
Das ist bei mir das Problem. Mit IP geht LogIN gebe ich Name des Rechners ein. Dreht er mir Nase.
Würde mich mal mit IP Adresse in RDP Fenster statt der DNS Adresse anmelden.
Das ist bei mir das Problem. Mit IP geht LogIN gebe ich Name des Rechners ein. Dreht er mir Nase.
