Duo + Azure AD Conditional Access + ADFS + Office clients prompting for login

KevinMcDermott0758 · ‎04-08-2019

Hoping someone else has run into this…

So we are integrating Duo with Office 365 via Azure AD Conditional Access policies. Our Azure AD is currently integrated with our AD via ADFS 3.0 environment. The problem we’re running into is the O365 thick clients (Outlook / Skype / Teams) are prompting users for credentials when it shouldn’t.

User launches Outlook/Teams/Skype
Client pops up the Microsoftonline login window asking for email address
User provides company email and is redirected to our ADFS login page
ADFS Login page prompts for username/password
Duo prompts
User is logged in.

The problem is Step 4 shouldn’t happen if the user is on our internal network. ADFS uses “windows authentication” when you’re on the internal network which allows for transparent login (user doesn’t type in credentials). This works perfectly for websites, like Outlook.office.com or any other web based app we have integrated with Azure AD, but not the Outlook/Skype/Teams clients.

Anyone run into this and find a way to fix it? I really don’t want people having to log into Office more often just because of Duo (even if it is once every 60-90 days).

DuoKristina · ‎04-08-2019

Have you tried defining a location condition in the CA policy for Duo that excludes your internal network?

Duo, not DUO.

KevinMcDermott0758 · ‎04-09-2019

I have, but the issue isn’t with the Duo prompting it’s with ADFS prompting for credentials, which it shouldn’t be doing on the internal network.

cdavid · ‎04-11-2019

We have been battling a very similar issue for about two months now.

We want to be able to roll out Duo MFA to our users, and we want it to work in conjunction with our on-prem ADFS (using the Duo AD FS MFA Adapter / Duo Authentication for AD FS 1.2.0.17).

It’s working great for all of our relying parties EXCEPT FOR Office 365.

For Office 365, we want to use it in conjunction with Azure Conditional Access. (I will say that when we use the built-in AD FS Access Control Policy to enforce MFA for the Office 365 relying party, we have no issues).

When we are using Azure CA, we are basing the policy off of the “Locations” condition. We have it configured to include all locations, but to EXCLUDE the “MFA Trusted IPs” location. This way, anyone federated users on our corporate network should bypass the CA Policy altogether.

So far, we have this CA Policy scoped to a test group of 5 people. Some of these people will get prompted once an hour, by applications like Outlook and Teams, asking for their AD credentials (via the AD FS login prompt).

This makes me feel like the Primary Refresh Token (PRT) is not being respected and/or properly utilized. Since it’s happening for them once an hour, and our Session Tokens are set to the default value of 0 (which equates to 60 minutes), it’s when the Session Token Lifetime expires that the Primary Refresh Token is supposed to reach up to Azure to acquire a new Session Token.

The strange part is that we only really run into this issue when the “Locations” condition is configured/enabled. If I turn off the “Locations” condition, all issues go away [so it seems].

KevinMcDermott0758 · ‎04-11-2019

Cdavid – for your issue I’d recommend moving the “trusted locations” to the Duo policy instead of Azure CA. While not the same, we did run into a problem where people would get prompted to login to O365 if they took their from the office (where they were trusted location and no Duo) to their house (where they were). Moving locations would trigger a change in the conditions of their CA policy which would then force Azure to invalidate their login. If you move the trusted locations list to Duo that won’t happen. I wonder if your trusted IP list isn’t complete and you have users sometimes being load balanced onto a different public IP.

cdavid · ‎04-12-2019

Glitch,

Thanks for the reply.

We actually leave our Trusted IP list completely empty. You might ask yourself, well then how do you assert that you are from a trusted location? That is where the AD FS “Inside Corporate Network” Claim comes into play.

We have our Office 365 AD FS relying party configured with the Inside Corporate Network claim. In Azure > Conditional Access - Policies > ____ > Conditions > Locations, we have it set to Include “Any location” but to Exclude the “MFA Trusted IPs” location. Now, if you go to the “multi-factor authentication > trusted ips” section of Azure, you see there is a checkbox that says “Skip multi-factor authentication for requests from federated users on my intranet.” From all of the documentation I’ve seen, by having that checkbox toggled, you can then referenced the MFA Trusted IPs “group” in the “Exclude” portion of the Conditoins > Locations area.

I assume that we can’t leverage this ability with the Duo policy. I am guessing that with the Duo policy, we’d have to maintain an IP list.

The reason we cannot maintain an IP list is because he have tons of teleworkers with hardware VPNs (namely Meraki Z3 devices) which are all set up for split tunnel. When they hit O365 for instance, they’ll be coming from their own ISPs public IP address. These change dynamically, and it would be a pain to constantly maintain that list.

What boggles me is why this might work for some people in our test group, and not others.

KevinMcDermott0758 · ‎04-15-2019

Do you have Duo integrated with ADFS, or with Azure AD? I’ve deployed it in another environment with ADFS and used the “inside corporate network” feature you describe to avoid MFA inside the network and it worked quite well, but we’re using Azure AD this time.

We’re going to hit the issue with teleworkers that you explain, but that’s just unavoidable for us. For O365 they’ll only have to do it once per 90 days, and for anything else Duo protected they’ll be able to “trust for 8 hours”. That really shouldn’t be too much of a heartache for users and ADFS won’t force them to type in their credentials.

cdavid · ‎05-13-2019

Problem solved. Ahmed @ Microsoft explained why this was happening for us in this article:

Now, we have our conditional access policy set up where it doesn’t do things based on Location (InsideCorpNet vs OutsideCorpNet), but rather if the device is Azure AD Hybrid Joined device or not.