Forum Discussion

BrentStobbs's avatar
BrentStobbs
Brass Contributor
May 18, 2020
Solved

Outlook constantly reverts to "Need Password"

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 :

[HKCU\SOFTWARE\Microsoft\Office\16.0\Common\Identity]
"EnableADAL"=dword:00000000

 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?

 

Thanks

  • BrentStobbs's avatar
    BrentStobbs
    May 18, 2020

    ChristianBergstrom Thank you

     

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

     

    HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity\Identities

     

    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.

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.

     

    https://www.linkedin.com/pulse/solving-modern-authentication-issues-office-365-chris-leet/

     

    https://docs.microsoft.com/en-us/office365/troubleshoot/authentication/automatic-authentication-fails

     

    https://support.microsoft.com/en-us/help/3211279/outlook-2016-implementation-of-autodiscover

     

     

    • BrentStobbs's avatar
      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

       

      HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity\Identities

       

      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.

Resources