This post describes an issue that under certain circumstances can affect MS Outlook running on Windows 10 Multi-Session.
The issue manifests itself as MS Outlook constantly prompting the user for credentials, and even after entering their correct username and password the prompt constantly loops which to a user this gives the same experience as if they’d entered a wrong password.
Note, this was not all users, on every WVD session host, all of the time, it was certain users, intermittently, on differing hosts.
I too did the usual dance of looking to diagnose issues with the user’s credentials, such as changing the password, forcing AD Connect syncs, checking issues with Basic versus Modern Auth, AAD App Passwords, disabling MFA – nothing worked.
Just to set the scene and give a bit more background info this particular customer uses ADFS to proxy authentication from Azure AD to Active Directory, they use Windows 10 Multi-Session (Build 1909) and MS Office 365 (Build 2004).
I read through dozens of articles with one consistent theme of disabling the use of Web Account Manager – the below paragraph from Duo Support added great context:
“By default, Microsoft Office 365 ProPlus (2016 version) uses Azure Active Directory Authentication Library (ADAL) framework-based authentication. Starting in build 16.0.7967, Office uses Web Account Manager (WAM) for sign-in workflows on Windows builds that are later than 15000 (Windows 10, version 1703, build 15063.138). There are generally two problems we see WAM causing:
Users unable to authenticate (particularly after a password reset)
WAM introduces new requirements for Identity Providers (IdP) used to federate Office 365 (O365) logins. When a Windows 10 workstation is joined to an on-premise Active Directory, WAM/O365 requires the IdP to support the WS-Trust protocol. When a user’s access/refresh tokens become invalid, such as after a password reset, the WAM framework tries to re-authenticate the user. The expected end-user experience is a popup window showing the login page of the IdP asking the user to re-authenticate. When the IdP is the DAG, this process will fail causing the user to be unable to re-connect to O365 with applications such as Microsoft Outlook. The user will see the authentication window open briefly then immediately close while Outlook continues to show the message Need Password.”
The article suggests disabling WAM using the below registry key:
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity Create Dword Value DISABLEAADWAM Set a value of 1
Now, this did resolve the issue however I always felt it was a workaround and not a fix as I was mindful of the effect disabling this service had on other dependent applications and Windows services.
Pieter’s post states that the issue could be caused when session hosts are registered in the same Azure AD tenancy as they are domain-joined, that is, domain joined to the same AD that syncs to the AAD in which they are registered – this is caused when a user selects the “use this account everywhere” prompt from an Office app which can be done by standard (non-admin) users.
I checked this in the customer’s AAD (Azure Portal > Azure Active Directory > Devices) which found that to be the case, see below. Note how a single session host VM is registered multiple times with different owners, subsequently these are all the same users who initially reported the issue with Outlook.
Pieter’s post advises Microsoft are “making changes to the Windows 10 multi-session image in the Azure gallery to prevent users from registering VMs” however in the immediate time suggests two methods to resolve this issue.
First, and the Microsoft preferred method is to configure Hybrid AAD which would allow VM’s to be joined to AAD, rather than registered.
Below is a quick reminder on the differences between an AAD registered device versus joined.
Azure AD Registered > Devices that are Azure AD registered are typically personally owned or mobile devices, and are signed in with a personal Microsoft account or another local account.
Azure AD Joined > Devices that are Azure AD joined are owned by an organisation, and are signed in with an Azure AD account belonging to that organisation.
The second option is to prevent the VM from registering in Azure AD, this is the option I opted for on this occasion, namely because shifting to a hybrid Azure AD was a significant design decision and presented a change in architecture for the customer, and not something they would opt into quickly, nor should they.
Preventing VM’s from registering in Azure AD can be achieved by adding the below registry key:
HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin Create Dword Value BlockAADWorkplaceJoin Set a value of 1
Note, you could add the above registry key to existing machines that had previously registered in AAD, you would simply have to delete them from AAD.
I hope you found this post useful, if you’re interested in engaging more with others using and learning more about WVD please consider following the WVD Community on Twitter and joining the Slack channel, both ran by Neil and Stefan, and both great sources of info!