winary
Goto Top

Windows-Sicherheit Pop-up friert nach Eingabe von Login-Daten den Desktop ein

Hallo in die Runde.

Ausgangssituation:

- 1x Remotedesktop-Server (Windows Server 2019, künftig RDS genannt)
- Mehrere Nutzer greifen über ThinClients via RDP auf den RDS zu
- Teile der Benutzerprofile liegen mittels Ordnerumleitung auf einem Netzwerk-Share; Der betroffene Nutzer besitzt zusätzlich einen PC, auf dem er sich mit dem selben Domänenprofil anmeldet und auch Zugriff auf seine umgeleiteten Daten hat


Problem:

Ein Nutzer (Gruppe Domänenbenutzer) beklagt das Phänomen, dass sobald ein Windows-Sicherheits Fenster (siehe Bild) erscheint, wenn erhöhte Rechte erforderlich sind, und man die Login-Daten eines Nutzers mit den entsprechenden Rechten eintippt und mit Enter oder OK bestätigt, so friert der ganze Desktop des Nutzers ein.

windows-security-dialog-boxjpg

Lediglich ein STRG+ALT+ENTF, gefolgt von ESC, stellt den Normalzustand wieder her. Es erscheint keine Fehlermeldung, egal wie lange man wartet. In der Ereignisanzeige findet man keine Einträge passend zum Zeitpunkt und Nutzer.
Nur dieser eine Nutzer hat dieses Problem und nur auf diesem RDS. Meldet er sich an einem PC an besteht das Problem nicht. Andere Nutzer sind in den selben Sicherheitsgruppen wie der Betroffene, dort funktioniert es allerdings.
Es beschränkt sich nicht nur, wie im Bild zu erahnen, auf das eröffnen einer RDP-Sitzung, sondern alles, was die Benutzerkontensteuerung (UAC) betrifft. Diese ist für den Nutzer aber genauso eingestellt wie für andere Nutzer auch (UAC-Standardeinstellung - Stufe 3).

Es scheint kein Rechte-Problem zu sein, da dies selbst eintritt, wenn ich dem Nutzer temporär Administratorberechtigung erteile, egal ob lokal auf dem RDS oder Domänenadministrator-Rechte.


Mir fällt nichts mehr ein, was ich noch versuchen kann. Die UAC will ich nicht ausschalten oder etwas an der Stufe verändern.

Hat jemand eine Idee, was ich eventuell übersehen oder missverstanden habe? Vielen Dank schon einmal im Voraus.


Grüße Winary

Content-Key: 558740

Url: https://administrator.de/contentid/558740

Printed on: April 26, 2024 at 12:04 o'clock

Member: emeriks
emeriks Mar 17, 2020 at 12:40:24 (UTC)
Goto Top
Hi,
ich würde testen, was ist, wenn man diesem Benutzer ein vollkommen neues Benutzerprofil gibt. Also wenn es nur auf diesem TS auftritt und es nur lokale Profile sind, dann auf diesem TS das Profil löschen (vorher sichern) und den Benutzer neu anmelden. Falls Roaming Profile, dann auch die Roaming Kopie vorher löschen oder Pfad umbenennen.

E.
Member: Winary
Winary Mar 17, 2020 at 12:52:22 (UTC)
Goto Top
Hi,

wie gesagt, nur dieser Nutzer hat das Problem. Nutzer, die früher oder später sich am RDS erstmals angemeldet haben, haben dieses Problem nicht. Bei einem komplett neuen Nutzer, frisch im AD erzeugt und mit den selben Sicherheitsgruppen versorgt, tritt der Effekt nicht auf.

Ich habe dem Betroffenen auch bereits alle Verbindungen zu seinen lokalen und umgeleiteten Benutzerordnern durch umbenennen gekappt, sodass sie bei der nächsten Anmeldung wieder neu erzeugt wurden. Keine Veränderung.

Macht es Sinn, zusätzlich sein AD-Benutzerkonto zu löschen und neu zu erstellen? Ich kann mir nicht vorstellen, dass eine neu erzeugte SID Auswirkungen darauf hat. Der betroffene Nutzer muss genau diesen Kontonamen behalten, da linuxseitig historisch sehr viel an diesem Benutzernamen hängt (ja ich weiß, auch dort sollte man besser Gruppen für Berechtigungen nehmen, aber darauf habe ich keine Handhabe).
Member: emeriks
emeriks Mar 17, 2020 at 12:54:00 (UTC)
Goto Top
Wenn ich Deinen Text richtig deute, Du alles geschrieben hast, dann hast Du eins noch nicht getan:
Dem Benutzer ein neues Profil verpasst.
Member: Winary
Winary Mar 17, 2020 at 13:12:38 (UTC)
Goto Top
Richtig, aber sein aktuelles AD-Konto muss ich löschen, da es, wie erwähnt, den selben Benutzeranmeldenamen haben muss. Ich werde es bei Gelegenheit nochmal damit probieren, Danke.

Aber unabhängig davon, was könnte das denn auslösen? Der Prozess für Windows-Sicherheit heißt "Credential Manager UI Host" und entstammt der %SYSTEMROOT%\System32\CredentialUIBroker.exe.
In den NTFS-Berechtigungen für diese und dafür relevante Dateien sehe ich keine Einschränkung für den Nuter; alles beim Standard. Auch löst während des Stillstands kein Prozess des Nutzers einen Ausschlag in den verwendeten Ressourcen des RDS aus; CPU, RAM und Handles alles moderat. Mit procmon und resmon komme ich so auch nicht der Ursache auf die Spur.
Member: emeriks
emeriks Mar 17, 2020 at 13:21:22 (UTC)
Goto Top
Benutzerprofil löschen, nicht Benutzerkonto!
Kennst Du den Unterschied nicht?
Member: Winary
Winary Mar 17, 2020 at 13:34:20 (UTC)
Goto Top
Doch doch, aber ich sagte schon dass ich das "Löschen" des Profilordners schon probiert habe. Roamingprofil gibt es nicht, nur Ordnerumleitung (Desktop, Dokumente, usw.).
Member: emeriks
emeriks Mar 17, 2020 at 13:43:05 (UTC)
Goto Top
Zitat von @Winary:
Doch doch, aber ich sagte schon dass ich das "Löschen" des Profilordners schon probiert habe.
Wenn ich nicht gerade blind bin: nein.

Aber gut. Nun wissen wir das ja.
Member: Winary
Winary Mar 17, 2020 at 14:02:05 (UTC)
Goto Top
Löschen in Anführungszeichen :D Ich habe sämtliche relevante Ordner umbenannt und alle Reg-Einträge in der Profilelist vom RDS und dem PC exportiert und gelöscht. Sprich, es ist so alsob ich das AD-Konto gerade erst angelegt habe. Und selbst dann nach der Anmeldung friert der Desktop ein, ohne dass ich Profildaten zurück übertragen habe. Es ist wie verhext