Introduction
Today is a day when you had to work late, and then this. You’re working and suddenly your profile is no longer fully functional. After logging out and back in, everything works again, but what was going on?
Or you are a developer and have a personal VDI. In the evening, you close the session window and want to continue working in the same place the next day. But in the morning, after logging in, your session behaves differently. The start menu is no longer correctly available. All applications with a login to Microsoft Entra Id, i.e. Teams, Edge, Outlook or OneDrive, require a login. What’s going on?
We worked on a ticket with Microsoft Support for a customer over a long period of time. After more than half a year, we have now closed the ticket. It is my personal opinion that the deployment scenario is potentially becoming more and more common. My aim with this post is to raise awareness of the problem and to help you find a quick solution if you have the same scenario.
Initial situation
We were testing personal VDI, which are Microsoft Entra Id only joined. The user logs in with the hybrid identity and the operating system is also prepared for this. We use a Microsoft Entra Id joined storage account to store the profile disks. All in all, a supported scenario.
The user can log in and gets a profile, so far everything works.
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
The customer has decided that users who receive a personal VDI can have their session disconnected for up to 4 days before the user is logged out. This allows users to use their VDI virtually like Windows 365.
For a better user experience, we have enabled single sign-on. (SSO) However, the users were set to lock the session after 5 minutes, which in this constellation meant that the session would be disconnected.
The domain service has a default configuration of the maximum service ticket lifetime of 10 hours.
Adding this time is not recommended. Best practice is to leave this at the 10 hours.
Symptom
While testing the personal VDI, the IT users gave the first feedback that something might be wrong with the profile. The IT users started the session and tested it, and then returned to other work. After 5 minutes, the session was disconnected. Hours could pass before the next test, often not until the evening or the next day. In retrospect, it is clear that this interruption then lasted at least 10 hours.
After logging on to the existing session, the symptoms appeared:
- Start menu was not functional
- You had to log in to the Microsoft applications again, but the apps still didn’t work properly
- Links on the desktop had disappeared
- Applications in the task list were without icons
The FSLogix log also showed that an error “Failed to read WindowsSessionID…) occurred, and later the disk could not reconnect when I logged on to the session again.
You can also find entries in the event log:
After the login
If you display the tokens after logging in, you will see the following (command executed: klist):
User with the error:
|
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 |
User without error:
|
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 |
After 10 hours
More than ten hours later, the output looks like this (Executed command: klist):
User with the error:
|
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 |
User without error:
|
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
The first suggestion from Microsoft was to increase the maximum service ticket lifetime, even though the article advises against this. We have ruled this out.
However, there are two workarounds that work:
- Configuring FSLogix to associate the profile with the Storage Access Key (Setting: AccessNetworkAsComputerObject) from the service
- Script that regularly renews the tickets
The solution with the Storage Access Key requires that no user can work as an administrator on the system, which cannot be ruled out with personal VDI. You can find good instructions at Marcel Meurer: https://blog.itprocloud.de/Using-FSLogix-file-shares-with-Azure-AD-cloud-identities-in-Azure-Virtual-Desktop-AVD/
We have tested the script and it works. The only thing left to do is to run the script regularly in the user context.
|
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 |
Solution
The behavior is as expected. Unfortunately, a solution is not in sight at the moment, but the problem is in the backlog.
If the scenario also affects you, something can certainly be done besides implementing one of the workarounds. You could also open a ticket with Microsoft and point out that it is a known problem and that you have the same use case or the same problem. The more customers report the problem, the higher the likelihood that the problem will be solved more quickly, and not just a workaround will make the rounds.
Conclusion
Why don’t we have this with all users? As the customer also wanted to log in with Microsoft Entra Id Only users for the multi-user session hosts, we had to work with the storage account for these systems. For security reasons, we wanted to do without it on the personal VDI.
We have not implemented the workaround as only the personal VDIs are affected so far. OneDrive was configured for the users, we now back up the complete profile with a backup of the VM. If we want to get rid of the storage access keys, then we would also have the problem with other users, and then we would probably have to implement the workaround. But I hope that either Microsoft will solve the problem due to high customer feedback, or that it will solve itself when we no longer need hybrid users to store FSLogix on a storage account.