05-18-2020 04:27 AM
05-18-2020 04:27 AM
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?
05-18-2020 07:06 AM
@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.
05-18-2020 08:25 AMSolution
@bec064 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 https://blog.markdepalma.com/?p=490:(
$x = Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 $x.ServicePrincipalnames.Add("https://autodiscover.domain.com/") 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.