Outlook constantly reverts to "Need Password"

Brass Contributor

I have an Exchange (2016 CU 16) Hybrid set up, with all mailboxes stored On-Prem.  I use MFA/ADFS for Authentication.


A number of my users are getting "Need Password" a few minutes after starting Outlook.  You can double click on this (no prompt for password) and it connects to exchange, downloads the latest messages and then reverts back to "Need Password".  Creating a new profile resolves the issue for a little while, but then reverts back to the same issue.


The only long term fix I have found is to disable ADAL :


 I was under the impression that ADAL is more secure, and hence I don't particularly want to disable it. 


Can anyone enlighten me as to why I need to disable ADAL to get Outlook to work?  What implications does it have?



2 Replies

@BrentStobbs Hello Brent, I certainly agree that you should enable and use ADAL. ADAL/WAM issues can be a real pain, especially in some environments. I've heard from some organizations that they have solved similar issues either by using the registry key 'ExcludeExplicitO365Endpoint' or reestablishing the Microsoft.AAD.BrokerPlugin at the affected machines (which I believe could be the case here).


I am attaching a couple of links to guide you in the right direction and for reference.



best response confirmed by BrentStobbs (Brass Contributor)

@ChristianBergstrom Thank you


I believe I have resolved this issue.  After researching the issue and coming across the suggestion to delete the registry key




While this didn't resolve the issue, it pointed me to the error : AADSTS500011: The resource principal named <autodiscover URL> was not found in the tenant named <tenant ID>.


After checking the Service Principal URLs I found that the Autodiscover URL was not added.


After running the following commands (As per

$x = Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000
Set-MSOLServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 -ServicePrincipalNames $x.ServicePrincipalNames

The problem has been resolved for the past hour.  I'm still monitoring before the celebration.