11
Kennwortrichtlinie bei Remoteverbindung (VM bzw. Terminalserver)
Hallo liebe Gemeinde,
ich habe entweder einen Denkfehler oder stehe auf dem Schlauch (naja, Jahresende...).
Folgendes Szenario :
Es existieren in unserem Netz zwei DC (SRV 2016, bald 2019), mehrere HyperV Server und mehrere Synology-NAS.
Die Zugriffe und Nutzerverwaltung erfolgen via AD - alles soweit ok.
Nun soll aber (endlich, da dies vor meiner Zeit versäumt wurde) u.a. eine Kennwortrichtlinie aktiviert werden, welche z.B.
Komplexitätsvoraussetzungen aktiviert, Länge, Chronik und zeitlichen Ablauf festlegt.
Dies funktioniert bei Usern mit "normalen" PC ganz normal.
Die bekommen eine Anzeige, wonach sie Ihr Kennwort via Eingabe des alten und zweifacher Eingabe des neuen regelmäßig ändern müssen.
Nun gibt es jedoch im Netz einerseits viele User, die via Remotedesktopverbindung auf Terminalserver oder dedizierte Windows10 VMs zugreifen und darauf arbeiten.
Zum einen, weil es im Netz ne Menge "dummer Terminals" gibt (IGEL) und zum anderen, weil situationsbedingt viele im Homeoffice arbeiten.
Wenn nun ein erzwungener Kennwortwechsel ansteht (per Richtlinie oder weil ich den Haken bei "Nutzer muss beim nächsten Anmelden Kennwort ändern" setze), passiert folgendes :
Igel-Terminals melden "Server unreachable" - so als wäre der Server nicht da. Was Quatsch ist, denn wenn ich die Kennworterzwingung rausnehme ist alles ok.
RDP-Verbindungen von einer Windows Station aus zeigen ein Meldungsfenster, welches freundlich darauf hinweist, dass doch bitte erst das Kennwort geändert werden soll, bevor man sich anmelden kann. Jedoch keine Möglichkeit, dies auch zu tun sondern sofort ein Beenden sder Sitzung.
Habe ich da etwas verpasst ? Es muss doch möglich sein, eine Änderung des Kennworts regelmäßig auch über ne RDP-verbindung zu erzwingen....
Vielen Dank im Voraus für Eure Hilfe.
miscmike
ich habe entweder einen Denkfehler oder stehe auf dem Schlauch (naja, Jahresende...).
Folgendes Szenario :
Es existieren in unserem Netz zwei DC (SRV 2016, bald 2019), mehrere HyperV Server und mehrere Synology-NAS.
Die Zugriffe und Nutzerverwaltung erfolgen via AD - alles soweit ok.
Nun soll aber (endlich, da dies vor meiner Zeit versäumt wurde) u.a. eine Kennwortrichtlinie aktiviert werden, welche z.B.
Komplexitätsvoraussetzungen aktiviert, Länge, Chronik und zeitlichen Ablauf festlegt.
Dies funktioniert bei Usern mit "normalen" PC ganz normal.
Die bekommen eine Anzeige, wonach sie Ihr Kennwort via Eingabe des alten und zweifacher Eingabe des neuen regelmäßig ändern müssen.
Nun gibt es jedoch im Netz einerseits viele User, die via Remotedesktopverbindung auf Terminalserver oder dedizierte Windows10 VMs zugreifen und darauf arbeiten.
Zum einen, weil es im Netz ne Menge "dummer Terminals" gibt (IGEL) und zum anderen, weil situationsbedingt viele im Homeoffice arbeiten.
Wenn nun ein erzwungener Kennwortwechsel ansteht (per Richtlinie oder weil ich den Haken bei "Nutzer muss beim nächsten Anmelden Kennwort ändern" setze), passiert folgendes :
Igel-Terminals melden "Server unreachable" - so als wäre der Server nicht da. Was Quatsch ist, denn wenn ich die Kennworterzwingung rausnehme ist alles ok.
RDP-Verbindungen von einer Windows Station aus zeigen ein Meldungsfenster, welches freundlich darauf hinweist, dass doch bitte erst das Kennwort geändert werden soll, bevor man sich anmelden kann. Jedoch keine Möglichkeit, dies auch zu tun sondern sofort ein Beenden sder Sitzung.
Habe ich da etwas verpasst ? Es muss doch möglich sein, eine Änderung des Kennworts regelmäßig auch über ne RDP-verbindung zu erzwingen....
Vielen Dank im Voraus für Eure Hilfe.
miscmike
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: 629275
Url: https://administrator.de/contentid/629275
Ausgedruckt am: 21.11.2024 um 10:11 Uhr
11 Kommentare
Neuester Kommentar
Hi.
Was die Igels angeht weiß ich es nicht, aber ich bin mir ziemlich sicher, dass es den selben Grund hat wie bei den anderen auch: auf den Terminalservern ist NLA (Network Level Authentication) aktiviert, welches ein Authentifizieren bereits am Quellrechner anfordert. Damit kommen die Igels wohl nicht klar.
NLA hat zwar sicherheitstechnisch theoretisch Vorteile, es ist jedoch nict so kritisch, dass man es nicht deaktivieren könnte.
Wenn Du das nicht willst, musst Du die Nutzer dazu bringen, das Kennwort z.B. über einen Webserver (Exchange OWA, oder RemoteApp-Server Startseite 1 zu ändern (siehe auch http://woshub.com/allow-users-to-reset-expired-password-via-rd-webacces ... )
Was die Igels angeht weiß ich es nicht, aber ich bin mir ziemlich sicher, dass es den selben Grund hat wie bei den anderen auch: auf den Terminalservern ist NLA (Network Level Authentication) aktiviert, welches ein Authentifizieren bereits am Quellrechner anfordert. Damit kommen die Igels wohl nicht klar.
NLA hat zwar sicherheitstechnisch theoretisch Vorteile, es ist jedoch nict so kritisch, dass man es nicht deaktivieren könnte.
Wenn Du das nicht willst, musst Du die Nutzer dazu bringen, das Kennwort z.B. über einen Webserver (Exchange OWA, oder RemoteApp-Server Startseite 1 zu ändern (siehe auch http://woshub.com/allow-users-to-reset-expired-password-via-rd-webacces ... )
Nun gibt es jedoch im Netz einerseits viele User, die via Remotedesktopverbindung auf Terminalserver oder dedizierte Windows10 VMs zugreifen und darauf arbeiten.
Zum einen, weil es im Netz ne Menge "dummer Terminals" gibt (IGEL) und zum anderen, weil situationsbedingt viele im Homeoffice arbeiten.
Wenn nun ein erzwungener Kennwortwechsel ansteht (per Richtlinie oder weil ich den Haken bei "Nutzer muss beim nächsten Anmelden Kennwort ändern" setze), passiert folgendes :
Igel-Terminals melden "Server unreachable" - so als wäre der Server nicht da. Was Quatsch ist, denn wenn ich die Kennworterzwingung rausnehme ist alles ok.
Da ist der IGEL nicht richtig konfiguriert, bzw. ohne Anmeldung am ADZum einen, weil es im Netz ne Menge "dummer Terminals" gibt (IGEL) und zum anderen, weil situationsbedingt viele im Homeoffice arbeiten.
Wenn nun ein erzwungener Kennwortwechsel ansteht (per Richtlinie oder weil ich den Haken bei "Nutzer muss beim nächsten Anmelden Kennwort ändern" setze), passiert folgendes :
Igel-Terminals melden "Server unreachable" - so als wäre der Server nicht da. Was Quatsch ist, denn wenn ich die Kennworterzwingung rausnehme ist alles ok.
RDP-Verbindungen von einer Windows Station aus zeigen ein Meldungsfenster, welches freundlich darauf hinweist, dass doch bitte erst das Kennwort geändert werden soll, bevor man sich anmelden kann. Jedoch keine Möglichkeit, dies auch zu tun sondern sofort ein Beenden sder Sitzung.
Habe ich da etwas verpasst ? Es muss doch möglich sein, eine Änderung des Kennworts regelmäßig auch über ne RDP-verbindung zu erzwingen....
Dies setze ich hier problemlos bei 250 ThinClients um
Die Hilfe von IGEL gibt es hier dazu
IGEL Active Directory/Kerberos
Use passthrough authentication for IGEL RDP
Danke für die Info. Das bringt mich ein Stück weiter, jedoch ist es (noch) nicht die Lösung.
Die RDP-Verbindungen zielen auf ganz normale (wenn auch virtuelle) Windows 10 Maschinen. Also ohne Webserver bzw. Remote-App-Verwaltung. Auch der Terminalserver ist nicht damit konfiguriert.
Ich habe bei den Systemeigenschaften unter "remote" den Haken bei "Verbindungen nur von Computersn zulassen, auf denen Remotedesktop mit Authentifizierung auf Netzwerkebene (NLA) ausgeführt wird" rausgenommen.
Leider hat das nicht zum Erfolg geführt.
Nutzer können sich ganz normal anmelden.
Wenn jedoch ihr Kennwort abgelaufen ist und ein neues festgelegt werden soll, kann keine Verbindung hergestellt werden - nicht einmal, um das Kennwort über diesen Weg zu ändern.
Die RDP-Verbindungen zielen auf ganz normale (wenn auch virtuelle) Windows 10 Maschinen. Also ohne Webserver bzw. Remote-App-Verwaltung. Auch der Terminalserver ist nicht damit konfiguriert.
Ich habe bei den Systemeigenschaften unter "remote" den Haken bei "Verbindungen nur von Computersn zulassen, auf denen Remotedesktop mit Authentifizierung auf Netzwerkebene (NLA) ausgeführt wird" rausgenommen.
Leider hat das nicht zum Erfolg geführt.
Nutzer können sich ganz normal anmelden.
Wenn jedoch ihr Kennwort abgelaufen ist und ein neues festgelegt werden soll, kann keine Verbindung hergestellt werden - nicht einmal, um das Kennwort über diesen Weg zu ändern.
Ich habe bei den Systemeigenschaften unter "remote" den Haken bei "Verbindungen nur von Computersn zulassen, auf denen Remotedesktop mit Authentifizierung auf Netzwerkebene (NLA) ausgeführt wird" rausgenommen.
Das musst Du auf den Zielrechnern machen, nicht auf den Rechnern von wo du kommst. UND zudem dort den Remotedesktopdienst neu starten - hast Du das denn gemacht?
Ist mir klar, dass das auf den Zielrechnern muss 
, allerdings habe ich den RD-Service nicht neu gestartet.
Windows - da war ja was...
Probiere ich gleich mal aus..
, allerdings habe ich den RD-Service nicht neu gestartet.Windows - da war ja was...
Probiere ich gleich mal aus..
Nö, funktioniert leider auch nicht nach Dienst neu starten. Auch nicht nach kompletter Maschine neu starten.
Interessanter Bug!
Ich bekomme in einem Test das Selbe... Es sei denn, ich wähle SmartCard-Authentifizierung (PIN lasse ich leer), dann komme ich bis zur Remote-Anmeldemaske, dort gebe ich das Kennwort ein und werde zur Änderung aufgefordert (NLA ist aus).
Somit ist die Vermutung, dass es etwas mit Credential Delegation zu tun hat. Hast Du das aktiv? Sprich, ist die Zeile mit dem Benutzernamen vorausgefüllt (und grau) im Remotedesktopclient?
Ich bekomme in einem Test das Selbe... Es sei denn, ich wähle SmartCard-Authentifizierung (PIN lasse ich leer), dann komme ich bis zur Remote-Anmeldemaske, dort gebe ich das Kennwort ein und werde zur Änderung aufgefordert (NLA ist aus).
Somit ist die Vermutung, dass es etwas mit Credential Delegation zu tun hat. Hast Du das aktiv? Sprich, ist die Zeile mit dem Benutzernamen vorausgefüllt (und grau) im Remotedesktopclient?
Meinst Du das :
Name des letzten angemeldeten Nutzers steht drin, ist jedoch änderbar (nicht grau) und soll eigentlich auch so sein.
An welcher Stelle wählst Du SmartCard-Auth ?
Name des letzten angemeldeten Nutzers steht drin, ist jedoch änderbar (nicht grau) und soll eigentlich auch so sein.
An welcher Stelle wählst Du SmartCard-Auth ?
Das meine ich, ja. Wenn es nicht grau ist, werden keine zwischengespeicherten CRedentials verwendet, daran liegt es also nicht.
SmartCardAuth ist nur verwendbar, wenn man, wie wir, SmartCards nutzt. So konnte ich nachvollziehen, dass es ein Bug sein muss, da es sich nur OHNE Smartcard so verhält, als wäre NLA noch an.
Habe leider keinen weiteren Tipp für Dich...ich denke nicht, dass Du dir nun eine SmartCard anschaffen willst.
SmartCardAuth ist nur verwendbar, wenn man, wie wir, SmartCards nutzt. So konnte ich nachvollziehen, dass es ein Bug sein muss, da es sich nur OHNE Smartcard so verhält, als wäre NLA noch an.
Habe leider keinen weiteren Tipp für Dich...ich denke nicht, dass Du dir nun eine SmartCard anschaffen willst.
nee, das nicht.Schade, hab ich wohl mal ein echtes Problem gefunden.
Trotzdem vielen Dank für Deine Mitarbeit !
Sollte hier noch jemand ein ähnliches Problem haben - ich bin für Lösungen empfänglich.
Es kann doch nicht sein, dass das noch niemandem aufgefallen ist...
Zitat von @miscmike:
Danke für die Info. Das bringt mich ein Stück weiter, jedoch ist es (noch) nicht die Lösung.
Die RDP-Verbindungen zielen auf ganz normale (wenn auch virtuelle) Windows 10 Maschinen. Also ohne Webserver bzw. Remote-App-Verwaltung. Auch der Terminalserver ist nicht damit konfiguriert.
Danke für die Info. Das bringt mich ein Stück weiter, jedoch ist es (noch) nicht die Lösung.
Die RDP-Verbindungen zielen auf ganz normale (wenn auch virtuelle) Windows 10 Maschinen. Also ohne Webserver bzw. Remote-App-Verwaltung. Auch der Terminalserver ist nicht damit konfiguriert.
Wir haben auch keine RemoteApp Verwaltung und auch kein WebGateway.
