A colleague of mine recently solved one of the biggest pain points I have dealt with regarding Office365 – that is, Microsoft’s seemingly hit-or-miss modern authentication.

Symptoms look like this:
1. Outlook client can’t connect and/or authenticate for end-users
2. Turning on Azure MFA for an end-user ruins their life (and yours) because all office applications, teams, etc. break.
3. Admins have an impending sense of “dread” when setting up systems for new users because 80% of the time they are going to spend hours sorting out the above issues.
4. You call Microsoft Support complaining of these issues and they are eventually stumped and tell you to rebuild the desktop/laptop from scratch… great for end-users that deal with this issue 1 year into the job and rather like their systems as-is… -or- MS Support tells you to pop a registry key into the end-user’s system which just disables Modern Authentication all together – which may fix Outlook but leaves many many other things broken…

If any of that sounds familiar, I highly recommend you read the article he published on linked-in…. this is THE SILVER BULLET to end your Microsoft Authentication woes: Solving Modern Authentication Issues with Office 365

I also document fixes like this here so this is the powershell that he wrote up to run on end-user systems experiencing these issues (stolen from article, all credit goes there)…

Get-AppxPackage Microsoft.AAD.BrokerPlugin

If that returns NOTHING then there is your issue… So proceed to run this:

if (-not (Get-AppxPackage Microsoft.AAD.BrokerPlugin)) { Add-AppxPackage -Register "$env:windir\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Appxmanifest.xml" -DisableDevelopmentMode -ForceApplicationShutdown } Get-AppxPackage Microsoft.AAD.BrokerPlugin

Then – if you did the thing (per MS support) where you added that registry key to disable Modern Auth… undo that and then clear cached credentials…

Remove-ItemProperty -Path "HKCU:\Software\Microsoft\Office\16.0\Common\Identity" -Name "EnableADAL"
cmdkey /list | ForEach-Object{if($_ -like "*Target:*"){cmdkey /del:($_ -replace " ","" -replace "Target:","")}}

Once the above has all been run… Office365 authentication woes magically disappear and Azure MFA starts working… for everything.

My friend also provided this solution to Microsoft Support (in full) and they thanked him so hopefully other people won’t continue wrestling with this issue because support can NOW provide the right answer. (there are LOTS of people dealing with this right now…)

Cheers!

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

1 of 1

13 comments on: Modern Authentication Issues with Office 365 – FIXED – Don’t Just Disable Azure Active Directory Authentication Library (ADAL) – Instead… Fix It With This!

  1. Rustom
    Reply

    Awesome work dude. This helps a lot.

    • nbeam
      Reply

      Thanks, my colleague was the one that discovered it! It’s amazing because modern auth finally just WORKS and Azure MFA roll-out is no longer anger inducing for everyone involved.

  2. Trevor
    Reply

    Truly, You and your colleague deserve a medal. Excellent work.

    I’d been using the EnableADAL = 0 registry hack to fix 365 login prompts not appearing for several months now, and only recently realised it was breaking MFA in the process.

    • nbeam
      Reply

      Thanks! – Microsoft has made it official guidance apparently so I am glad it finally made it up. This frustrated us, literally, for years :/

  3. Chris Gibbs
    Reply

    Microsoft has officially acknowledged the issue and provided guidance on this https://docs.microsoft.com/en-us/office365/troubleshoot/authentication/automatic-authentication-fails

    • nbeam
      Reply

      Hooray! – thanks for this 🙂

  4. Krishna
    Reply

    thanks brother it really worked, much appreciated.

  5. Mick
    Reply

    Late to the party, but just letting you know this really helped the mind boggling issue we had with 1 user.

    Thank you very much!

  6. Theo
    Reply

    Hi
    Thanks for the tip, it is really helpfull.
    But i’m having one question :
    This solution works on my server, but it looks like it’s working only on the account you run those lines, not for others end-users on the server.

    It is a RDS server with VHDX profiles stored on a broker.

    I was wondering if you had a solution about this, or any details of how this plugins is working/stored ?
    Thanks again !

    • nbeam
      Reply

      @Theo – Yes that would be correct – this is making changes to the HKCU portion of the registry as the last step – CU –> “Current User”. I haven’t looked at this in a long time (and haven’t worked with RDS in a longer time than that) but first I would try to find out if there is a Group Policy that could be used to set that specific key. Additionally, you could also work on some form of powershell automation script that could be run to do the rest (if needed, because you are using an RDS server I am not sure if all software is shared across all profiles or not) at user login. Hope this at least points you in the right direction. If you have a large number of user profiles, you are definitely gonna want some kind of automation.

  7. Tarun Kumar
    Reply

    In one of our customer’s environment suddenly we got this issue. The outlook authentication was working fine and suddenly it broke. The MFA was already enabled.

    The problem is outlook authentication is stopped working suddenly on one of the proxy (which is a bypass proxy) on which it was working previously. We have Azure MFA already enabled from long time and issue just appeared now.
    When we are switching to another proxy, the authentication working fine.

    Microsoft suggested to disable the modern authentication till the time issue is not fixed.
    As per their troubleshooting there are issues in hybrid devices in authentication here are some logs which they highlighted:
    ——————————————-
    sso state
    ——————————————-
    AzureAdPrt : No
    AzureAdPrtAuthority :
    EnterprisePrt : No
    EnterprisePrtAuthority :
    ——————————————-

    Also have issues with WAM:
    ——————————————–
    User State
    ——————————————–
    NgcSet : No
    WorkplaceJoined : No
    WamDefaultSet : Error
    ——————————————–

    Any help would be appreciated.

  8. William
    Reply

    Have used this in the past with sucsess. But today it did not help.
    Turns out I had to rename this folder manually (with the user logged off the system) for it to work:

    %LocalAppData%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy

  9. Matt
    Reply

    This command doesn’t work on a 2012 R2 Server because C:\windows\systemapps folder does not exist. Is there something we can run to get this to do the same thing for 2012 R2? I am unable to upgrade the server to more current version because of RDS User cals and would be required to buy more licensing. Going to open a ticket with Microsoft but like tons of people on the web microsoft just tells them to turn off modern authentication which will break everyone in October when Microsoft turns off basic authentication for Exchange Online.

    THought about taking a snapshot of the 2012 r2 server and copying the folder over from a 2016 server and running the command to see if it will work and delete snapshot if it blows it up.

Join the discussion

Your email address will not be published. Required fields are marked *