[English]Frage in die Runde der Administratoren – ich habe keine Zeit, das auszutesten: Hat jemand beobachtet, dass sich das Autologon am Terminal Server nach Installation der Sicherheitsupdates für Oktober 2023 verändert hat? Ein Blog-Leser kam mit der Beobachtung auf mich zu, dass er in seiner Firmenumgebung nun Probleme mit dem Terminal Server (läuft unter Windows Server 2016) nach diesem Update habe.
Autologon am Terminal Server verändert
Der Blog-Leser betreibt einen Terminal Server unter Windows Server 2016, auf den die Mitarbeiter in der dortigen Umgebung zugreifen können. Die Mitarbeiter können per Autologon auf diesen Terminal Server. Nachdem die Oktober 2023-Sicherheitsupdates installiert wurden, gibt es aber Probleme, die der Administrator so beschreibt.
Wir haben seit dem Update unserer Windows Server 2016 Terminalserver eine interessante Änderung im Startverhalten: Der Warmup-User wird nicht mehr angemeldet.
Bisher war der Autologon im Image auf 0, jedoch per GPO für die Produktivmaschinen aktiv. Somit wurde auf den produktiven Terminalservern der Warmup-User automatisch nach dem Hochfahren angemeldet.
Seit dem letzten Windows-Update funktioniert das so nicht mehr, der Warmup-User wird nicht angemeldet. Unsere Einstellungen sind aber die gleichen geblieben. Mit dem alten Image geht auch alles wie zuvor. Wir vermuten, dass sich in der Reihenfolge des Startvorgangs irgend eine Änderung eingeschlichen hat. Oder ist das eine neue Sicherheitsfunktion?
Beim Update muss es sich um das Sicherheitsupdate KB5031362 handeln, welches zum 10. Oktober 2023 freigegeben wurde (siehe Patchday: Windows 10-Updates (10. Oktober 2023)). Mir ist ad-hoc nichts untergekommen, dass sich etwas geändert hat. Ich hatte dem Leser angeboten, dass ich das Thema mal im Blog aufgreife, um das Wissen der Leserschaft anzuzapfen. Darauf hin meldete sich der Administrator mit einer ergänzenden Information:
Wir kennen nach wie vor den Grund [für das geänderten Anmeldeverhalten] nicht. Aber nach erneutem Installieren der Updates auf dem älteren Snapshot, wird der Autologon nach bisherigem Mechanismus wieder richtig durchgeführt.
Allerdings wird jetzt das Anmeldeskript nicht gestartet.
Irgend etwas läuft dort gravierend schief – die Frage ist, welche Gruppenrichtlinien da mit rein spielen könnten? Ist jemand aus der Leserschaft hier was entsprechendes aufgefallen?
Ähnliche Artikel:
Windows Server 2016: Fix für RDP-Probleme in KB5015808
Windows Server 2016: Startmenü nach Sept. 2023-Update KB5029242 kaputt?
Windows Server 2016: Microsoft bestätigt Bug im Gruppenrichtlinieneditor
Windows Server 2016: Workaround für GPO-MMC wsecedit.dll-Fehler
Was ist denn ein „Warmup-User“?
Er wird irgendeine schlechte Anwendung die JAVA oder so etwas benutzt einmal Starten mit dem Warmup User, so das der erste User nicht 5 Minuten warten muss bis die Anwendung geladen werden kann. Und die Anwendung kann nicht als Dienst ausgeführt werden. Da wir keine Autologen User haben kann ich das Problem allerdings nicht bestätigen oder widerlegen. ;)
ah – leuchtet ein ;-)
Dankeschön :-)
Halleluja klingt das gruselig – warum gibt es so etwas immer noch, im Jahre 2023?
Am Ende ist das eine sinnvolle Geschichte. Ich gehe mal davon aus, die IT-Kollegen dort haben Terminalserver die täglich neu starten.
Nun werden beim Systemstart einmal alle wichtigen Anwendungen gestartet. Damit liegen diese Anwendungen zum Teil im Arbeitsspeicher und der Start für den ersten Benutzer ist spürbar schneller.
Das braucht man im Jahr 2023 viel eher als vor 20 Jahren. Da waren die Anwendungen viel kleiner und die Arbeitsspeichernutzung dieser Anwendungen viel besser optimiert.
In 2023 hat oder sollte man zumindest für den TS ein SSD-Storage einsetzen und somit fallen die Ladezeitenunterschiede meistens nicht mehr ins Gewicht.
Wir haben auch Auto Login, machen dass aber über das PS Tool. Keine Probleme.
Die Frage stellt sich mir auch gerade. Aus Sicherheitsgründen würde ich – egal ob physische oder virtualisierte Server – generell auf ein Autologin eines Nutzers verzichten. Falls nach dem Start wirklich etwas unter dem Account eines Nutzers gemacht werden muß, kann man das immer noch als Dienst oder geplanter Task unter diesem Account starten. Permanent eingeloggte Benutzer manchen nach meiner Erfahrung in vielerlei Hinsicht (Backup, offene Dateien, Verhinderung Neustart nach Update) mehr Probleme als sie lösen.
Oder man regelt es per GPO so das der „Warmup User“ als Startscript direkt ein Logout Script ausführt. In der Regel erledigt sich das Problem auch schon per TS Richtlinie das inaktive Logins nach XXX Minuten automatisch abgemeldet werden.
Würde ein Logoff-Skript, nicht im Zweifel das ganze konterkarieren? – Durch einen Logoff-Skript werden (hoffentlich) alle Prozesse des betreffenden Users sauber beendet. Falls also das „WarmUp“ nicht einen Cache z.B. im ProgramData-Bereich neuerstellt, würde m.E. ein Logon und Logoff, meines Verständnis nach nicht weiterhelfen.
Unabhängig davon wundere ich mich gerade aber auch ein „bisschen“, ich bräuchte erst einmal 1,2 Programme als konkrete Beispiele, um den ganzen Sinn der Aktion nachzuvollziehen.
Wir haben hier zwei Server 2016 mit Autologon und da läuft alles wie gewohnt.
Allerdings nicht per GPO sondern manuell konfiguriert.
Bei den TS ist uns bisher nichts aufgefallen. Jedoch haben wir seither Probleme mit RADIUS / LDAP. Unsere Windows 10 Clients bekommen sich nicht mehr ins WLAN eingeloggt. Am RADIUS Server wird Event 16 geworfen.
Reason Code: 16
Reason: Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.
Mit den Windows 11 Clients und iPhone funktioniert die Authentifizierung.
Gibt es hierzu Anregungen?
TLS-Versionen prüfen. Deaktiviert sollten die kleiner gleich 1.1 sein. Verbindungen zum MSSQL sind z.B. gestört, wenn TLS 1.3 aktiv ist, der 2019er kann das aber noch gar nicht, der neueste Client (ODBC 18.x z.B) probiert das aber trotzdem.
Dazu kommen evtl noch neuere Protokolle, die bei Win10 nicht vorhanden oder nicht sauber ausgehandelt werden.
Reason 16 und Radius hört sich für mich nach Microsoft certificate hardening an. Bitte mal prüfen, ob der Radius mit Zertifikaten arbeitet und hier eine Abhänigkeit zur neuen Zertifikatsrichtlinie von Microsoft besteht. Hatte meinen NPS auch erwischt, aber das ist schon gut ein Jahr her.
https://support.microsoft.com/en-au/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16