

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.
Outlook 365 need password no prompt windows 10#
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.įirst, and the Microsoft preferred method is to configure Hybrid AAD which would allow VM’s to be joined to AAD, rather than registered.īelow is a quick reminder on the differences between an AAD registered device versus joined.Īzure AD Registered > D evices 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.Īzure 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. 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. I checked this in the customer’s AAD (Azure Portal > Azure Active Directory > Devices) which found that to be the case, see below. 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. That’s when a colleague shared this post from Pieter Wegleven, WVD Product Manager at Microsoft.

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. The article suggests disabling WAM using the below registry key: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity The user will see the authentication window open briefly then immediately close while Outlook continues to show the message Need Password.” 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 expected end-user experience is a popup window showing the login page of the IdP asking the user to re-authenticate. When a user’s access/refresh tokens become invalid, such as after a password reset, the WAM framework tries to re-authenticate the user. When a Windows 10 workstation is joined to an on-premise Active Directory, WAM/O365 requires the IdP to support the WS-Trust protocol. WAM introduces new requirements for Identity Providers (IdP) used to federate Office 365 (O365) logins.

Users unable to authenticate (particularly after a password reset) There are generally two problems we see WAM causing: Starting in build, 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). “By default, Microsoft Office 365 ProPlus (2016 version) uses Azure Active Directory Authentication Library (ADAL) framework-based authentication. 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: 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 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. Note, this was not all users, on every WVD session host, all of the time, it was certain users, intermittently, on differing hosts. 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.

This post describes an issue that under certain circumstances can affect MS Outlook running on Windows 10 Multi-Session.
