Einleitung
Heute ist ein Tag, an dem du länger arbeiten musstest, und dann das. Du arbeitest, und plötzlich ist das Profil nicht mehr voll funktionsfähig. Nach dem Ab- und wieder Anmelden funktioniert alles wieder, aber was war da los?
Oder du bist Entwickler und hast eine Persönliche VDI. Am Abend schliesst du das Fenster von der Session und möchtest am nächsten Tag am gleichen Ort weiterarbeite. Aber am Morgen, nach dem Anmelden, verhält sich deine Session anders. Startmenü ist nicht mehr richtig vorhanden. Alle Anwendungen mit einem Login bei Microsoft Entra Id, also Teams, Edge, Outlook oder OneDrive, verlangen einen Login. Was ist da los?
Für einen Kunden haben wir über einen längeren Zeitraum ein Ticket mit dem Microsoft Support bearbeitet. Nach mehr als einem halben Jahr haben wir das Ticket nun abgeschlossen. Es ist meine persönliche Meinung, dass es sich beim Einsatzszenario um ein potenziell immer mehr verbreitetes handelt. Mein Ziel mit diesem Beitrag ist es, das Problem bekannt zu machen, und zu helfen, eine schnelle Lösung zu finden, sollte man das gleiche Szenario haben.
Ausgangslage
Wir waren am Testen von persönlichen VDI, welche Microsoft Entra Id only joined sind. Der Benutzer meldet sich mit der Hybrididentität an, und das Betriebssystem ist auch dafür vorbereitet. Für die das Speichern der Profil Disks verwenden wir einen Microsoft Entra Id joined Storage Account. Alles in allem ein unterstütztes Szenario.
Der Benutzer kann sich anmelden, und bekommt ein Profil, soweit funktioniert alles.
https://learn.microsoft.com/en-us/azure/virtual-desktop/authentication
https://learn.microsoft.com/en-us/azure/virtual-desktop/azure-ad-joined-session-hosts
https://learn.microsoft.com/en-us/azure/virtual-desktop/create-profile-container-azure-ad
Der Kunde hat entschieden, dass Benutzer, die eine persönliche VDI erhalten, ihre Session bis zu 4 Tage getrennt haben können, bevor der Benutzer abgemeldet wird. Damit können die Benutzer ihre VDI praktisch wie Windows 365 nutzen.
Für eine bessere Benutzererfahrung haben wir einmaliges Anmelden aktiviert. (SSO) Die Benutzer wurden jedoch so eingestellt, dass nach 5 Minuten die Sitzung gesperrt wird, was in dieser Konstellation bedeutete, dass die Sitzung getrennt wird.
Der Domain Service hat eine die Standardkonfiguration der Maximum Service Ticket Lebenszeit von 10 Stunden konfiguriert.
Das Anhaben dieser Zeit ist nicht empfohlen. Best Practices ist dies auf den 10 Stunden zu belassen.
Symptom
Während dem Testen der persönlichen VDI, haben die IT-Benutzer die ersten Feedbacks gegeben, dass mit dem Profil etwas nicht stimmen könne. Die IT-Benutzer haben die Sitzung gestartet und haben getestet, und dann wieder anderen Arbeiten zugewandt. Nach 5 Minuten wurde dann die Sitzung getrennt. Bis zum nächsten Test konnten dann Stunden vergehen, oft erst am Abend oder nächsten Tag. Im Nachhinein ist klar, dass diese Unterbrechung dann mindestens 10 Stunden dauerte.
Nach dem Anmelden an die bestehende Sitzung traten dann die Symptome auf:
- Start Menü war nicht funktionsfähig
- An den Microsoft Anwendungen musste man sich neu anmelden, trotzdem funktionierten die Apps dann nicht richtig
- Links auf dem Desktop waren verschwunden
- Anwendungen in der Taskliste waren ohne Icons
Auch in dem FSLogix Log sah man, dass einen Fehler «Failed to read WindowsSessionID…) auftrat, und später die Disk nicht wieder verbinden konnte, als ich mich an der Sitzung neu angemeldet hatte.
Auch im Event Log findet man Einträge dazu:
Nach dem Login
Wenn man sich die Tokens nach dem Anmelden anzeigen lässt, sieht man folgendes (Ausgeführter Befehl: klist):
Benutzer mit dem Fehler:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
Cached Tickets: (4) #0> Client: max.mustermann @ CONTOSO.COM Server: krbtgt/CONTOSO.COM @ CONTOSO.COM KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize Start Time: 9/1/2023 10:09:50 (local) End Time: 9/1/2023 20:09:50 (local) Renew Time: 9/8/2023 10:09:50 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x1 -> PRIMARY Kdc Called: AZDC01.CONTOSO.com #1> Client: max.mustermann @ CONTOSO.COM Server: krbtgt/KERBEROS.MICROSOFTONLINE.COM @ KERBEROS.MICROSOFTONLINE.COM KerbTicket Encryption Type: Unknown (-1) Ticket Flags 0x40810000 -> forwardable renewable name_canonicalize Start Time: 9/1/2023 10:09:48 (local) End Time: 9/1/2023 20:09:48 (local) Renew Time: 9/8/2023 10:09:48 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x400 -> 0x400 Kdc Called: TicketSuppliedAtLogon #2> Client: max.mustermann @ CONTOSO.COM Server: cifs/AZDC01.CONTOSO.com @ CONTOSO.COM KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize Start Time: 9/1/2023 10:09:56 (local) End Time: 9/1/2023 20:09:50 (local) Renew Time: 9/8/2023 10:09:50 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0 Kdc Called: AZDC01.CONTOSO.com #3> Client: max.mustermann @ CONTOSO.COM Server: cifs/contosofiles01.file.core.windows.net @ KERBEROS.MICROSOFTONLINE.COM KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40000000 -> forwardable Start Time: 9/1/2023 10:09:50 (local) End Time: 9/1/2023 11:09:50 (local) Renew Time: 0 Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0 Kdc Called: KdcProxy:login.microsoftonline.com |
Benutzer ohne Fehler:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
Cached Tickets: (2) #0> Client: max.mustermann @ contoso.com Server: krbtgt/KERBEROS.MICROSOFTONLINE.COM @ KERBEROS.MICROSOFTONLINE.COM KerbTicket Encryption Type: Unknown (-1) Ticket Flags 0x40810000 -> forwardable renewable name_canonicalize Start Time: 8/29/2023 21:46:30 (local) End Time: 8/30/2023 7:46:30 (local) Renew Time: 9/5/2023 21:46:30 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x400 -> 0x400 Kdc Called: TicketSuppliedAtLogon #1> Client: max.mustermann @ contoso.com Server: cifs/contosofiles01.file.core.windows.net @ KERBEROS.MICROSOFTONLINE.COM KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40000000 -> forwardable Start Time: 8/29/2023 21:46:33 (local) End Time: 8/29/2023 22:46:33 (local) Renew Time: 0 Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0 Kdc Called: KdcProxy:login.microsoftonline.com |
Nach 10 Stunden
Mehr als zehn Stunden später sieht die Ausgabe wie folgt aus (Ausgeführter Befehl: klist):
Benutzer mit dem Fehler:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
Cached Tickets: (2) #0> Client: max.mustermann @ CONTOSO.COM Server: krbtgt/CONTOSO.COM @ CONTOSO.COM KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize Start Time: 9/1/2023 19:54:49 (local) End Time: 9/2/2023 5:54:49 (local) Renew Time: 9/8/2023 10:09:50 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x1 -> PRIMARY Kdc Called: AZDC01.CONTOSO.com #1> Client: max.mustermann @ CONTOSO.COM Server: cifs/AZDC01.CONTOSO.com @ CONTOSO.COM KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize Start Time: 9/1/2023 10:09:56 (local) End Time: 9/1/2023 20:09:50 (local) Renew Time: 9/8/2023 10:09:50 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0 Kdc Called: AZDC01.CONTOSO.com |
Benutzer ohne Fehler:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
Cached Tickets: (2) #0> Client: max.mustermann @ contoso.com Server: krbtgt/KERBEROS.MICROSOFTONLINE.COM @ KERBEROS.MICROSOFTONLINE.COM KerbTicket Encryption Type: Unknown (-1) Ticket Flags 0x40810000 -> forwardable renewable name_canonicalize Start Time: 8/30/2023 6:46:59 (local) End Time: 8/30/2023 16:46:59 (local) Renew Time: 9/6/2023 6:46:59 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x400 -> 0x400 Kdc Called: TicketSuppliedAtLogon #1> Client: max.mustermann @ contoso.com Server: cifs/contosofiles01.file.core.windows.net @ KERBEROS.MICROSOFTONLINE.COM KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40000000 -> forwardable Start Time: 8/30/2023 6:47:00 (local) End Time: 8/30/2023 7:47:00 (local) Renew Time: 0 Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0 Kdc Called: KdcProxy:login.microsoftonline.com |
Workaround
Der erste Vorschlag von Microsoft war die Maximum Service Ticket Lebenszeit zu erhöhen, auch wenn der Artikel davon abratet. Dies haben wir ausgeschlossen.
Es gibt aber zwei Workarounds, welche funktionieren:
- Konfigurieren von FSLogix, damit das Profil mit dem Storage Access Key (Setting: AccessNetworkAsComputerObject) vom Service verbunden wird
- Script welches regelmässig die Tickets erneuert
Die Lösung mit dem Storage Access Key erfordert, dass kein Benutzer als Administrator auf dem System arbeiten kann, was bei persönlichen VDI nicht ausgeschlossen werden kann. Eine gute Anleitung findest du bei Marcel Meurer: https://blog.itprocloud.de/Using-FSLogix-file-shares-with-Azure-AD-cloud-identities-in-Azure-Virtual-Desktop-AVD/
Das Script haben wir getestet und funktioniert. Man müsste nur noch das Script nun im Benutzerkontext regelmässig ausführen.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
@echo off Set ApplicationName=KerberosRefresh Set ProdVersion=V1 Call :Procedure >>%Temp%\%ApplicationName%_%ProdVersion%.log 2>&1 Goto End :Procedure echo ------------------------------------------------------------------------------ echo Logged time = %time% %date% echo ------------------------------------------------------------------------------ echo. echo --------------------------------------- echo Showing kerberos list echo --------------------------------------- C:\Windows\System32\klist.exe get krbtgt echo. echo --------------------------------------- Echo Running dsregcmd.exe /refreshprt echo --------------------------------------- C:\Windows\System32\dsregcmd.exe /refreshprt echo. echo --------------------------------------- Echo Running klist.exe purge echo --------------------------------------- C:\Windows\System32\klist.exe purge echo. echo --------------------------------------- Echo Showing kerberos list echo --------------------------------------- C:\Windows\System32\klist.exe get krbtgt echo. GoTo :EOF :End |
Lösung
Das Verhalten sei wie erwartet. Eine Lösung ist leider im Moment nicht in Sicht, das Problem befindet sich aber im Backlog.
Wenn dich das Szenario auch betrifft, kann man sicher etwas tun, nebst dem Implementieren eines der Workarounds. Du könntest bei Microsoft auch ein Ticket eröffnen und darauf verweisen, dass es ein bekanntes Problem ist, und dass man denselben Use Case, bzw. dasselbe Problem hat. Je mehr Kunden das Problem melden, desto höher die Wahrscheinlichkeit, dass das Problem schneller gelöst wird, und nicht nur ein Workaround die Runde macht.
Abschluss
Warum haben wir das nicht mit allen Benutzern? Da der Kunde für die Multi User Session Hosts auch mit Microsoft Entra Id Only Benutzern anmelden möchte, mussten wir für diese Systeme mit dem Storage Account arbeiten. Aus Überlegungen im Bezug auf Sicherheit, wollten wir auf den persönlichen VDI darauf verzichten.
Wir haben den Workaround nicht implementiert, da bis jetzt nur die persönlichen VDI betroffen sind. OneDrive war für die Benutzer konfiguriert, das komplette Profil sichern wir nun mit einem Backup der VM. Wen wir von den Storage Access Keys wegwollen, dann hätten wir das Problem auch mit anderen Benutzern, und dann müssten wir wohl den Workaround implementieren. Aber ich hoffe darauf, dass entweder Microsoft das Problem wegen hohem Kunden Feedback löst, oder dass es sich von alleine löst, wenn wir keine Hybrid User mehr benötigen, um FSLogix auf einem Storage Account zu speichern.