Implement DUO to ADFS 3.0 question

[TheZealous]

Hello everyone,

I am planning to rollout Duo with ADFS. I understand the risk of messing up the whole company authentication from Microsoft Cloud (Azure and Office 365 - Exchange) and other application that we are currently using. I found the documentation for the process here: https://duo.com/docs/ldap

Everything looks good until I was asked by my upper management ask about the step # 3 under “Configure ADFS Multi-Factor Authentication” here: https://duo.com/docs/adfs-30#configure-ad-fs-multi-factor-authentication. So let’s say I create a security group in AD and move a few test users to this new AD security group and add it here, what happen to the users that are not part of this group? Will they get the prompt for Duo push authentication? This wasn’t document anywhere in the documentation and so it is kind of concern us.

Thanks,
T.

[DuoKristina]

If users are not in that group then they won’t be required to use multifactor authentication.

HOWEVER - the AD FS multifactor GUI is misleading. If you make multiple selections then you’re creating an OR rule, not an AND rule. For example, you might want to add a test group and also check the Extranet box, thinking that this means “Require MFA for these specific people only when coming in from the outside.” Instead, what actually gets configured is “Require MFA for these specific people or anyone coming in from outside whether they are in the group I selected or not.”

I advise you to carefully review the TechNet article linked from the documentation: Overview: Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications.

In addition, enabling MFA in ADFS can have unexpected consequences for user access from applications that do not support Microsoft’s Modern Authentication. Please refer to the Duo Knowledge Base article Guide to advanced client configuration for Duo with AD FS 3 and later with Office 365 Modern Authentication.

[TheZealous]

First of all, thanks Kristina for the additional information. Below I would like to share what happened to my DUO integrate with ADFS during this weekend. It was a test deployment and it failed. The purpose of this post is only for informative and hope that it will help anyone run into this problem like me today.

So I began to proceed with making the changes to our ADFS server to implement DUO by following this instruction: https://duo.com/docs/adfs-30. After installed DUO in my ADFS servers with the integration key, secret key, and API hostname that I obtained from admin.duosecurity.com, I began with the steps in this instruction: https://duo.com/docs/adfs-faq. I created a Test1 security group in AD, added myself and a few of my coworkers in that group for testing. I made sure to go into Edit Global Authenthication Policy, added the security group that I just created, and intentionally leave the Extranet and Intranet check blank (read the post above from DuoKristrina and you will know why I left these check blank). I also leave the options to Unregistered devices and Registered devices blank. I checked the Duo Authentication for ADFS 1.1.0.4 and proceed with the next instruction. Which is create custom rule to globally disable 2FA on ActiveSync and Autodiscover endpoints while requiring 2FA for all other connection types. Instruction from here: https://duo.com/assets/pdf/Duo-ADFS-AdvancedClientAuthGuide.pdf. I ran this PowerShell command:

Example custom rule to globally disable 2FA on ActiveSync and
Autodiscover endpoints while requiring 2FA for all other
connection types

Set­AdfsAdditionalAuthenticationRule ­AdditionalAuthenticationRules ‘NOT
exists([Type ==
“http://schemas.microsoft.com/2012/01/requestcontext/claims/x­ms­client­appli
cation”, Value == “Microsoft.Exchange.ActiveSync”]) && NOT exists([Type ==
“http://schemas.microsoft.com/2012/01/requestcontext/claims/x­ms­client­appli
cation”, Value == “Microsoft.Exchange.AutoDiscover”]) =>issue(Type =
“http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod
”, Value = “http://schemas.microsoft.com/claims/multipleauthn”);’

According to this link https://help.duo.com/s/article/ka070000000fzgIAAQ/3476?language=en_US , if I don’t do that, our phones iOS and Android cannot authenticate in to check email. We use Office 365, so our email is in the Cloud with Microsoft.

The result:

After I made those changes mention above, it was time for testing. I was able to use Skype for business, check my email on my Macbook Pro laptop without any problem. I open a browser and go to portal.office.com and portal.azure.com, it prompted me to do Duo Push to my phone and worked fine. However, my colleagues (who were a member of Test1 group) told me their Windows laptop outlook just keep prompting for password over and over again, then crashed. iPhone Mail app (Apple’s native Mail app for iPhone) was doing the same thing, keep prompting for password. iPhone that use the Microsoft Outlook app download from the Apps store worked just fine. All Android devices that uses Outlook app worked just fine. However, at this point, we have a large amount of users that were not a part of the Test1 security group that I added earlier to test Duo ADFS started to put in tickets with our Help Desk and said their email are prompting for password and crash. So at this point, I know all users in our company cannot check their Outlook on their Windows laptops. I began to rollback the change because this is a critical issue. I went into Edit Global Authentication Policy in ADFS Management, only to find out the option to remove the Test1 security group is not there anymore. Instead, I get this screen: http://imgur.com/a/nCe8D. The message said "The MFA settings cannot be parsed. They may have been modified outside of the management console. Use Windows Powershell to configure the MFA settings. At this point, I draw a blank thinking how in the world I would do the rollback, while our users are putting tickets in complaining their Outlook keep crashing. I began to look into the ADFS logs. A lot of them show these error:

The Federation Service could not authorize token issuance for caller ‘ABES\zsmith
’. The caller is not authorized to request a token for the relying party ‘urn:federation:MicrosoftOnline’. See event 501 with the same Instance ID for caller identity.

Additional Data
Instance ID: 84be8422-9b38-4db6-8730-8290e4614d55
Relying party: urn:federation:MicrosoftOnline
Exception details:
Microsoft.IdentityServer.Service.IssuancePipeline.CallerAuthorizationException: MSIS5007: The caller authorization failed for caller identity ABES\zsmith for relying party trust urn:federation:MicrosoftOnline.
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.ProcessCoreAsyncResult.End(IAsyncResult ar)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.EndProcessCore(IAsyncResult ar, String requestAction, String responseAction, String trustNamespace)
User Action
Use the AD FS Management snap-in to ensure that the caller is authorized to request a token for the relying party.

AND

An error occurred during processing of a token request. The data in this event may have the identity of the caller (application) that made this request. The data includes an Activity ID that you can cross-reference to error or warning events to help diagnose the problem that caused this error.

Additional Data

Caller:
ABES\ymizzo

So, I know the root cause that cause the problem preventing me to see the option to remove the Test1 security group was because I ran the powershell command. That powershell command above also messed up the way Outlook authenticate in to check for mails in laptops. When I go into Edit Global Authentication Policy and uncheck the "Dui Authentication for AD FS 1.1.0.13, I can no longer log into portal.office.com anymore and show me a message stating ADFS ran into a problem, contact your administrator. After a few hours searching on google, I didn’t find the answer as to why the changes I made mess up all user’s ability to check their email. Then I though, what if I rollback the PowerShell command that I ran earlier? That might fix the problem. So I did some more google around and found this command that put all the problem to go away. The command that safe my life is: Set-ADFSAdditionalAuthenticationRules $null

After I ran Set-ADFSAdditionalAuthenticationRules $null , users are able to check email again after they close and reopen Outlook on their Windows laptop. So to conclude this, the powershell command I ran to bypass ActiveSync and AutoDiscover messed up the whole testing procedure and put the situation out of control. Duo + ADFS worked just fine after I enabled it. ActiveSync and Autodiscover didn’t work regardless if I run the PowerShell command provided in Duo documentation or not. Anyone here run into the same problem like me? What is your solution to make Duo work with ADFS? Thanks!

[DuoKristina]

After reading through all that it wounds like you just want the Duo MFA plugin for AD FS to kick in when your end users are using clients that support passive web authentication, like access from a browser or the Office 2016 rich client applications. Furthermore, you would like to just opt in a test group for Duo MFA and leave users not in that group unaffected.

I recommend trying this rule:

Set-AdfsRelyingPartyTrust -targetname "Microsoft Office 365 Identity Platform" -additionalauthenticationrules 'exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value =~ "(/adfs/ls)|(/adfs/oauth2)"]) && exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-rest-of-your-sid"]) => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");'

I’ve also updated our AD FS Advanced KB article to add the commands for removing additional authentication rules. I’m sorry that we didn’t have that information in the article all along!

As to why all your Outlook users started having issues, setting authentication rules from the shell overrides any changes you made in the GUI. So, since the Set­-AdfsAdditionalAuthenticationRule didn’t specify the SID of an AD group, it would apply to all users. However, excluding ActiveSync and AutoDiscover should still have let the Outlook users not in that group connect. Not sure what happened there. Were they using Outlook 2016 or an earlier version?

[TheZealous]

Hi Kristina,

So you recommend using the > Set-AdfsRelyingPartyTrust -targetname “Microsoft Office 365 Identity Platform” - instead of Set­AdfsAdditionalAuthenticationRule ­AdditionalAuthenticationRules 'NOT
exists([Type == ??? Can I add this rule in ADFS Management Console instead of Powershell? Because I hate to see those options under the Edit Global Authentication Policy go away once I run that PowerShell command.

We are using Outlook from Office 365 and Outlook 2016. We are not sure why users that are not a member of Test1 group were effected by the changes I made over the weekend.

[DuoKristina]

You simply cannot create authentication rules that target or exclude certain types of client connections for MFA from the GUI. If you want any granularity with multifactor beyond what’s shown in the GUI and then choose to configure rules from PowerShell, that supersedes any thing you set from the GUI.

Also note that the AD FS console has two places to configure MFA - the Global Multi-factor Authentication Rules dialog, and the per relying party trust options (Edit Custom Multi-factor Authentication).

The example I gave just applies the authentication rule to Office 365. If this is your only relying party using ADFS then certainly you can continue to set the rule globally. Many of our customers have multiple relying parties and only need to configure the rich client bypass for Office 365 while leaving the other RPs subject to the global rule.

“We are not sure why users that are not a member of Test1 group were effected by the changes I made over the weekend.”

The rule you set from PowerShell did not specify any group information, so it would have applied to everyone. I have given you an example that uses a group SID in determining whether or not to require MFA.

[TheZealous]

So this weekend we made a few changes.

1. We turned Modern Authentication for our Office 365 tenant that is being hosted with Microsoft.
2. I ran this command that recommended by DuoKristina, with the value of SID for the Test1 group.

Set-AdfsRelyingPartyTrust -targetname “Microsoft Office 365 Identity Platform” -additionalauthenticationrules ‘exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value =~ “(/adfs/ls)|(/adfs/oauth2)”]) && exists([Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “S-1-5-21-rest-of-your-sid”]) => issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod”, Value = “http://schemas.microsoft.com/claims/multipleauthn”);’

3. I added myself and a few other co-workers to the Test1 group and begun testing. Outlook seems to work just fine on my HP laptop, no more crashing as compare to before we turn on the Modern Authentication for Office 365 tenant. Meaning that Outlook is no longer keep prompting asking me to enter my username and password.
4. I removed my email off from my iPhone Mail (native iOS mail) client. When I tried to re-add my email account, it said it cannot find my account. I then went to the Apps store and download the Outlook client from Microsoft, it let me added my email in just fine. My co-worker tried the Blue Mail app for Android and it wasn’t working for him.
5. Skype for Business on my HP laptop is still prompting me to enter username and password to sync with Outlook on my laptop.

I think I am making some progress, but not quite near a point where I can roll this out to production yet. Any thoughts?
Thanks,
T.

[DuoKristina]

Did you enable Modern Auth on the Skype for Business online tenant in addition to enabling it for Exchange Online? If so, SfB client should be presenting you the Modern Auth ADFS primary login prompt. You don’t see this when you launch SfB?

The rule you created should exempt iOS Mail app. You can use AD FS Trace debugging to see exactly what rules are issued for a login attempt.

Instructions for turning on additional logging are covered in this MS blog article. Only do Step 1. You’ll want to do Step 1 only when you’re ready to submit the username and password on the Mail app login screen and disable the log immediately after the login fails. It’s going to generate a lot of output.

You’d be interested in events early in the log like these (if ADFS is applying an MFA rule to these non-web logon attempts):

ENTER: AuthenticationPolicyEvaluator.RequiresSecondStageAuthentication
Additional authentication required triggered by additional auth policy rules.
 
EXIT: AuthenticationPolicyEvaluator.RequiresSecondStageAuthentication

And if it is there will probably be more events later in the log like these:

Second stage authDomain: AuthenticationMethods: 
  http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/unspecified
ProviderAuthInfoList: 
  DuoAdfsAdapter
UseProviderAuthInfoList: True
 
Additional authentication required triggered by additional auth policy rules.

Entering ExternalAuthenticationHandler.Process() Identifier: DuoAdfsAdapter, ContextId: <null>`

This should help you see if the Mail app login is getting blocked by a MFA claim to Duo or another reason.

This forum isn’t intended as a replacement for Duo’s technical support team. We definitely don’t want you uploading debugger output here as it may contain organization-sensitive information! If you need additional in-depth troubleshooting assistance or log analysis after this please open a support case.

[psiess]

Hello @DuoKristina. I am about to enable Duo with ADFS and so I’ve read this post over and over, trying to wrap my head around it. I found this thread after enabling a Global MFA rule, resulting in much the same experience as @TheZealous.

Can you explain the various parts of the Set-AdfsRelyingPartyTrust command? I understand the groupsid part, but I don’t understand the one that ends with “(/adfs/ls)|(/adfs/oauth2)” or the one that ends with multipleauthn.

Also. If I am going configure rules from Powershell, do I need to do anything in the ADFS GUI? How does the powershell command shown in this post link to the associate the rule with the Duo Authentication for AD FS plugin?

My end goal is to require Duo 2FA for members of an AD group, for all types of external connections. Any other advice you can provide would be greatly appreciated!

[DuoKristina]

Also. If I am going configure rules from Powershell, do I need to do anything in the ADFS GUI?

No, for authentication rules these are mutually exclusive - once you make a change in Powershell to the authentication rules the GUI won’t let you make any changes, indicating instead that since you used Powershell you have to manage changes there. The only thing you’d do in the GUI is make sure the Duo AD FS adapter is enabled before creating your rules.

The (/adfs/ls)|(/adfs/oauth2) endpoints are the ones used for web authentication - so logins from a web browser or from a client application that uses MS Modern Authentication to show the AD FS logon web page. So this part of the rule means “if the request hits a web endpoint then evaluate the next part of the rule”.

multipleauthn is the AD FS mutlifactor endpoint, so this part of the rule means “if the already evaluated conditions indicate the request should use MFA, use MFA”.

Then, as part of mutlipleauthn processing AD FS looks to its list of enabled MFA adapters to use for the rest of the auth process. This is where the Duo MFA adapter for AD FS comes into play.

What is your definition of “external”? Many people define it as “users from a subnet outside of my internal network”. However, this is not AD FS’s definition of external. To AD FS, an external user is one whose authentication request was received from a web application proxy or reverse proxy which sets the X-MS-Proxy header to some value. So, if you actually want your rule to be based on an evaluation of a client’s IP address you’ll need to include a subnet definition in your rule using x-ms-forwarded-client-ip plus a regex of your external subnets. You can see an example of how to construct this claim in https://technet.microsoft.com/en-us/library/hh526961.

[psiess]

Thank you! That’s very helpful.

I’m using the AD FS definition…people who authenticated via the web app proxy, so I think want this:

-AdditionalAuthenticationRules 'exists([Type == “http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork”, Value == “false”])

Is there a particular order for evaluating conditions that needs to be followed?

[psiess]

I think I might have it.

Set-AdfsRelyingPartyTrust -additionalauthenticationrules 'exists([Type == “http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork”, Value == “false”]) && ‘exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value =~ “(/adfs/ls)|(/adfs/oauth2)”]) && exists([Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “S-1-5-21-rest-of-group-SID-goes-here”]) => issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod”, Value = “http://schemas.microsoft.com/claims/multipleauthn”);’

[Freddie_Eisa]

Im having the same issue as the users in here. Is there a solution yet for this?

[TheZealous]

@Freddie_Eisa What I did works fine for us. Only 1 problem that I see is that if our users are connected from home (or anywhere out side of office network AND VPN), they are expected to see the “Exchange needs your credentials, Until then, you might see outdated info in Skype for Business” error. I took a screenshot here https://imgur.com/a/ecMFc

@DuoKristina , Do you know how I can fix this error so that Skype for Business can sync info while on the internal network or out side of network? Thanks!

[DuoKristina]

I am not sure why you would see that message.

I posed these questions to you earlier in the thread:

Did you enable Modern Auth on the Skype for Business online tenant in addition to enabling it for Exchange Online? If so, SfB client should be presenting you the Modern Auth ADFS primary login prompt. You don’t see this when you launch SfB?

You can try going into the Credential Manager (from the Control Panel) and deleting any ADAL entry for Skype to try to force a new ADAL login.