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 22.214.171.124 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
SetAdfsAdditionalAuthenticationRule AdditionalAuthenticationRules ‘NOT
cation”, Value == “Microsoft.Exchange.ActiveSync”]) && NOT exists([Type ==
cation”, Value == “Microsoft.Exchange.AutoDiscover”]) =>issue(Type =
”, 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.
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.
Instance ID: 84be8422-9b38-4db6-8730-8290e4614d55
Relying party: urn:federation:MicrosoftOnline
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)
Use the AD FS Management snap-in to ensure that the caller is authorized to request a token for the relying party.
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.
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 126.96.36.199, 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!