Microsoft 365 DUO SSO

[khudson1]

I followed the documentation for setting up the Microsoft 365 protection via DUO SSO pretty carefully.

Once I federated the domain, I tested with a few service accounts and everything appeared to work. However, the users ended up contacting me because their Outlook clients were disconnected and constantly asked for credentials. I ended up having to move the office 365 domains back to managed from federated.

Is there something I possibly missed while setting this up?

[aaron_heroic]

I’m currently prepping for O365 SSO integration and I was worried about this happening! I want to make sure there is a good way to enable sso for test accounts before I interrupt users. I didn’t see anything in the documentation about it either.

[jamieis]

aaron_heroic:

I’m currently prepping for O365 SSO integration and I was worried about this happening! I want to make sure there is a good way to enable sso for test accounts before I interrupt users. I didn’t see anything in the documentation about it either.

Currently Microsoft does this as an “all or nothing” setup. If you do have multiple domains added in your Microsoft 365 tenant I’d recommend trying them out with a single domain before federating all of them.

[BabbittJE]

After federating my domain, I had to rebuild each person’s Outlook profile so that it would correctly recognize authenticating via MFA. But, I still had issues and had to follow this article, which resolved my issue:

Users unable to authenticate (particularly after a password reset)

WAM introduces new requirements for Identity Providers (IdP) used to federate Office 365 (O365) logins. When a Windows 10 workstation is joined to an on-premise Active Directory, WAM/O365 requires the IdP to support the WS-Trust protocol. Currently this is not supported in the Duo Access Gateway (DAG). When a user’s access/refresh tokens become invalid, such as after a password reset, the WAM framework tries to re-authenticate the user. The expected end-user experience is a popup window showing the login page of the IdP asking the user to re-authenticate. 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 user will see the authentication window open briefly then immediately close while Outlook continues to show the message “Need Password”.

To work around this issue, you can add the following Registry keys on the client machine to suppress WAM and revert Outlook back to ADAL:

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity]
Disable ADALatopWAMOverride"=dword:00000001 (remove space between Disable and ADAL)

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity]
“DisableAADWAM”=dword:00000001

[jamieis]

Hi @Kurt,

I wouldn’t expect users to be constantly required to log in again unless they were typing incorrect credentials. If this is a brand new user depending on how they are connected to Azure their profile might automatically be provisioned for them or they added it manually.

If they added it manually they may be asked to reauthenticate again (usually via a browser pop-up). After that, if WS-Trust is enabled in the Duo SSO Microsoft 365 application all further authentication attempts should happen in the background with bothering the user.

[khudson1]

To clarify, the outlook client would alert that it’s disconnected from exchange or show “need password” and the windows security authentication window would pop up repeatedly after entering good creds

I will probably try what @BabbittJE described above

I’ll also add that I did try enabling WS-Trust as well and it didn’t resolve it at the time

Edit: Also confirmed during this time that outlook on the web was accessible and user got through duo first factor

[jamieis]

Kurt:

To clarify, the outlook client would alert that it’s disconnected from exchange or show “need password” and the windows security authentication window would pop up repeatedly after entering good creds

I will probably try what @BabbittJE described above

I’ll also add that I did try enabling WS-Trust as well and it didn’t resolve it at the time

Is it all users that are impacted or just a few? It might be worthwhile having them sign out of their profile in the Outlook app and resigning in completely to see if that resolves the issue.

@BabbittJE is correct about WAM being an issue for the Duo Access Gateway but it should not be an issue for using Duo Single Sign-On with Microsoft 365 as we built this to specifically work with WS-Fed and WS-Trust.

[khudson1]

At the time it was only a few before I decided to move the domain back to managed. I didn’t want to cause a lot of disruption for the rest of the users the following morning.

I’ll likely plan for another test after hours with a test account signed into an outlook client in order to figure out the best way to reduce any disruptions. However I am open for any additional ideas

[BabbittJE]

@jamie, any idea if Duo Access Gateway will ever be compatible with WS-Trust? Or, do I need to replace my DAG with a different product? It’s working now with the registry hack but I’m thinking of the future path.

[colin_medfisch]

Hey @BabbittJE,

We do not plan to bring WS-Fed or WS-Trust support to the DAG.

As we look towards the future, we are focusing our efforts on Duo SSO and definitely encourage customers to start planning migrations from the DAG as soon as possible. Not only are certain issues seen with the DAG resolved, such as the WAM issue in this thread, but consolidating efforts towards Duo SSO allows us to build more efficiently, whether that be within the SSO product itself, with the current work on OIDC support, or tying into other key Duo initiatives, such as Passwordless or improved compatibility with the Universal Prompt.

Our team built a tool into the Duo Admin Panel that will automagically create new Duo SSO integrations from your existing DAG integrations as well!

[adam.palmer · Accepted solution]

Hi @Kurt,

Continuous prompts for credentials are typically due to basic auth still being allowed in your o365 tenant as MFA requires Modern Auth. Older tenants (pre-2017 do not have Modern Auth turned on by default), so you have to manually enable it. From https://portal.microsoft.com browse to Settings > Org Settings > Modern Authentication and turn it on if it’s off.

Ideally, you’ll want to disable basic auth while you are at it, but this may take a lot of work depending on your environment. You can check for basic auth in use by going to Azure AD admin center, clicking sign-ins, add a filter for status = successful, and a filter for clientapp and add all 13 of the legacy authentication options. If you see no sign-ins in the last month, then turn off all basic auth options in the same spot you enabled modern auth in the pic above. NOTE: only turning on MFA will not stop bad actors from easily bypassing MFA and breaching your environment. You have to turn on MFA, AND turn off basic auth in order to be safe. One other thing to point out is that unless you are using the conditional access method to protect your Office 365 tenant then only the federated domains are protected with Duo MFA. This means that for any .onmicrosoft.com sign-ins that are configured for any user account they will not be protected by MFA. If you only have a “break glass” account using the .onmicrosoft.com domain, and it’s got an extremely long password then you are fine, but any others you’ll either need to change their domain to your custom domain or protect them with Azure MFA (the standard free tier is sufficient).

After you have basic auth turned on, go to any problem workstations run this PowerShell command to tell Outlook to use Modern Authentication.

Set-ItemProperty -Path " HKCU:\Software\Microsoft\Exchange" -Name 'Always UseMSOAuthForAutoDiscover' -Value 1 -Type DWORD -Force    "(remove the space between Always and UseMSOAuthForAutoDiscover)"

For Outlook 2013 you’ll need to deploy these regkeys:

Set-ItemProperty -Path "HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity" -Name EnableADAL -Type DWORD -Force
Set-ItemProperty -Path "HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity" -Name Version -Type DWORD -Force

Other keys you can safely set to ensure modern auth is working as advertised:

Set-ItemProperty -Path "HKCU:\SOFTWARE\Microsoft\Office\16.0\Common\Identity" -Name EnableAdal -Value 1 -Type DWORD –Force
Set-ItemProperty -Path "HKCU:\SOFTWARE\Microsoft\Office\16.0\Common\Identity" -Name Disable ADALatopWAMOverride -Value 0 -Type DWORD –Force   "(remove the space between disalbe and ADALaptopWAMOverride)"
Set-ItemProperty -Path "HKCU:\SOFTWARE\Microsoft\Office\16.0\Common\Identity" -Name DisableAADWAM -Value 0 -Type DWORD –Force

Hope that helps!

Adam

[khudson1]

Thanks, I have modern auth on and I can see it being used.

I’m trying to find documentation on disabling basic auth. I still see many users signing in with basic auth from the filter in Azure AD. You mentioned it’d be a lot of work to disable basic auth if it’s still being used, do you have any references on that process?

[adam.palmer]

Hi @Kurt,

Yes, you have to use Azure AD sign-in reports in order to find your culprit accounts, and then inquire with your team to find out who is responsible for those accounts to discuss what they are used for today. It may be as simple as converting to a Shared Mailbox and delegating access to the responsible party so they no longer have to login to them, or changing the application or device to use an internal SMTP relay that does not require authentication (option 3) to Office 365, and in some cases it will require a lot more work. For example, if you have SalesLoft (a Salesforce product) and your marketing team is integrating their o365 mailbox with that application to send bulk email via ActiveSync or EWS, then you will have remove those legacy options in the SalesLoft app and enable and consent to the OAuth integration which supports Modern Authentication. You may have no apps like this or many it’s hard for me to predict.

In the Azure AD sign-in reports I strongly recommend that you take the 13 legacy authentication types one at a time, and as you eliminate them go back into Settings > Org Settings > Modern Auth in the m365 Admin Center and disable that basic auth control (pictured in my last post). That way you are preventing new problems from popping up while you are working through the rest.

Thanks,

Adam