Duo integrates with Microsoft AD FS v3 and later to add two-factor authentication to services using browser-based federated logins, complete with inline self-service enrollment and Duo Universal Prompt.
The Duo AD FS module supports relying parties that use Microsoft's WS-Federation protocol, like Office 365, as well as SAML 2.0 federated logons for cloud apps like Google G Suite and salesforce.com.
The AD FS application is part of Duo Beyond, Duo Access, and Duo MFA plans.
The Duo AD FS MFA adapter supports AD FS on Windows Server 2012 R2 and later. To protect AD FS on Windows Server 2012, use the AD FS 2.1 integration.
This application communicates with Duo's service on TCP port 443. Firewall configurations that restrict outbound access to Duo's service with rules using destination IP addresses or IP address ranges aren't recommended, since these may change over time to maintain our service's high availability. If your organization requires IP-based rules, please review this Duo KB article.
This integration adds a pluggable multi-factor (MFA) authentication provider that provides a Duo two-factor authentication prompt to web-based logins through an AD FS Identity Provider and/or Web Application Proxy. After completing primary authentication to the AD FS server (by any standard means such as Windows Integrated or Forms-Based), your users will be redirected to Duo for two-factor authentication before getting redirected back to the relying party.
Install the Duo integration on the internal AD FS identity provider server only. In an AD FS farm deployment install Duo on all identity provider AD FS servers in the farm.
When configuring the multi-factor authentication policies after the Duo installation on the internal AD FS server you select whether to require MFA on Internal or External access locations (or both). If you are planning to require two-factor authentication for External access locations, a Web Application Proxy server is required. You do not need to install the Duo AD FS integration on the Web Application Proxy server.
Before moving on to the deployment steps, it's a good idea to familiarize yourself with Duo administration concepts and features like options for applications, available methods for enrolling Duo users, and Duo policy settings and how to apply them. See all Duo Administrator documentation.
Also verify that federated logins to your relying parties are working prior to installing Duo.
Previously, the Client ID was called the "Integration key" and the Client secret was called the "Secret key".
The security of your Duo application is tied to the security of your secret key (skey). Secure it as you would any sensitive credential. Don't share it with unauthorized individuals or email it to anyone under any circumstances!
The new Universal Prompt provides a simplified and accessible Duo login experience for web-based applications, offering a redesigned visual interface with security and usability enhancements.
| Universal Prompt | Traditional Prompt |
 |
 |
Migration to Universal Prompt for your Microsoft ADFS application is a two-step process:
Before you activate the Universal Prompt for your application, it's a good idea to read the Universal Prompt Update Guide for more information about the update process and the new login experience for users.
When you install the latest version of Duo for AD FS you're ready to use the Universal Prompt. If you're configuring Microsoft ADFS now, proceed with the installation instructions in this document.
The "Universal Prompt" area of the application details page shows that this application is "New Prompt Ready", with these activation control options:
Duo for AD FS needs a software update installed to support the Universal Prompt. The "Universal Prompt" section of your existing Microsoft ADFS application reflects this status as "App Update Ready". To update Duo for AD FS application to a newer version, follow the update directions below.
Once a user authenticates to Duo for AD FS via the updated Duo plugin, the "Universal Prompt" section of the Microsoft ADFS application page reflects this status as "New Prompt Ready", with these activation control options:
In addition, the "Integration key" and "Secret key" property labels for the application update to "Client ID" and "Client secret" respectively. The values for these properties remain the same.
Activation of the Universal Prompt is a per-application change. Activating it for one application does not change the login experience for your other Duo applications.
Enable the Universal Prompt experience by selecting Show new Universal Prompt, and then scrolling to the bottom of the page to click Save.
Once you activate the Universal Prompt, the application's Universal Prompt status shows "Update Complete" here and on the Universal Prompt Update Progress report.
Should you ever want to roll back to the traditional prompt, you can return to this setting and change it back to Show traditional prompt.
Click the See Update Progress link to view the Universal Prompt Update Progress report. This report shows the update availability and migration progress for all your Duo applications in-scope for Universal Prompt support. You can also activate the new prompt experience for multiple supported applications from the report page instead of visiting the individual details pages for each application.
Set your application's New User Policy to "Allow Access" while testing. Enrolled users must complete two-factor authentication, while all other users are transparently let through.
Then (when you're ready) change the "New user policy" to "Require Enrollment." This will prompt all users to authenticate (or enroll) after they type in their usernames and passwords.
If you have deployed AD FS as a WID farm, install Duo on the primary server first. If you have a SQL farm, you may begin with any node.
Launch the Duo AD FS MSI installer as a user with local administrator privileges.
Enter your Client ID (formerly called the Integration key), Client secret (formerly called the Secret key), and API hostname from the Duo Security AD FS application page when prompted.
If the Bypass Duo authentication when offline option is unchecked, then Duo for AD FS will "fail closed" when Duo Security cloud services are unreachable and users will not be able to access protected federated resources. Check the box if you want users to be able to access protected applications without Duo authentication if Duo's cloud service is unreachable. This setting can be changed post-install from the registry.
The Duo MFA adapter sends a user's Windows sAMAccountName to Duo's service by default. To send the userPrincipalName to Duo instead, check the Use UPN username format box.
If you enable this option, you must also change the properties of your AD FS application in the Duo Admin Panel to change the "Username normalization" setting to None. Otherwise, Duo drops the domain suffix from the username sent from AD FS to our service, which may cause user mismatches or duplicate enrollment.
Complete the Duo installation.
If you have an AD FS farm, repeat the Duo installation steps on all farm members.
Launch the AD FS Management console on your primary AD FS internal server and navigate to AD FS → Service → Authentication Methods.
Click the Edit link under Multi-factor Authentication Methods or click Edit Multi-factor Authentication Methods... action on the far right.
Check the box next to the Duo Authentication for AD FS X.X.X.X authentication method (where X.X.X.X reflects the Duo version) to enable Duo protection. Click OK.
Go to AD FS → Access Control Policies and either edit one of the existing MFA policies to apply it to users or groups, or create a new MFA policy if no pre-defined one is sufficient for your organization's MFA requirements.
Go to AD FS → Relying Party Trusts , right-click the relying party trust where you want to add Duo, then select Edit Access Control Policy.
Pick a policy for the relying party that includes MFA and then click OK. The MFA policy immediately applies to the selected relying party.
In this example, all users have access to this relying party, but members of the "Duo Users" domain group also require multi-factor authentication before accessing the application.
In an advanced multi-factor scenario, you can choose Intranet and/or Extranet location requirements, along with other conditions for access. Refer to the Microsoft article Access Control Policies in Windows Server 2016 AD FS for more information.
If you need to enforce more complex MFA rules for an Office 365 relying party, please take a look at our Guide to advanced client configuration for Duo with AD FS 3 and later with Office 365 Modern Authentication.
Launch the AD FS Management console on your primary AD FS internal server. Navigate to AD FS → Authentication Policies and click the Edit Global Multi-factor Authentication... action, or click on the Edit link under Multi-factor Authentication → Global Settings.
On the "Multi-factor (MFA)"" tab of the "Edit Global Authentication Policy" you can choose to assign a domain group for MFA using the Add... button.
Alternatively, after determining what types of connections will be required to use MFA check the boxes for Extranet and/or Intranet. For example, if you want to always require two-factor authentication for all of your users, select both the Extranet and Intranet location when configuring the multi-factor authentication policy and don't specify a group assignment for MFA (as shown in the example).
If you only want to enforce two-factor authentication for external users (in any group), and you have configured your network such that external users communicate with an AD FS Web Application Proxy while internal users communicate with the Identity Provider, do not add any groups for MFA and only enable the Extranet location in the multi-factor authentication policy and leave the Intranet location unchecked.
Note that any MFA assignments made via the Global Authentication Policy editor are effectively "OR" rules, so each individual condition always applies. If you were to add a specific group (like ACME\Duo_Users) to the Users/Groups section, and then also check the box for the Extranet location, you may expect that the net effect is that members of the ACME\Duo_Users who access AD FS externally require MFA while members of that group accessing AD FS internally and any user who is not a member of that group do not require MFA. Since the GUI creates "OR" rules instead of "AND" rules the net effect is actually that members of ACME\Duo_Users always require MFA regardless of location, while users not in the ACME\Duo_Users group accessing AD FS externally also require MFA.
In an advanced multi-factor scenario, you can choose Intranet and/or Extranet location requirements on a per user or per relying party basis. Refer to the Microsoft article Overview: Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications for more information.
Check the box next to the Duo Authentication for AD FS X.X.X.X authentication method (where X.X.X.X reflects the actual installed Duo version) to enable Duo protection.
If you need to enforce more complex MFA rules for an Office 365 relying party (bypass or require policies for certain clients, users, or subnets), please take a look at our Guide to advanced client configuration for Duo with AD FS 3 and later with Office 365 Modern Authentication
If you federate Microsoft online services with AD FS you may want your AD FS server to pass an "Authentication Methods Reference" (AMR) claim back to Microsoft Online to show use of multifactor authentication by including the multipleauthn value after installing Duo for AD FS. This will satisfy Azure AD conditional access policies that require multifactor authentication.
To do this, you need to update your federation configuration for that domain to indicate support for multifactor authentication, and then create a custom claims rule in AD FS to send the AMR information.
Launch PowerShell on the server where you installed the MSOnline PowerShell module, and run the following commands (the module prompts you to enter your Microsoft 365 or Azure admin credentials):
Import-Module MSOnline
Connect-MsolService
Get-MsolDomainFederationSettings -DomainName yourDomainNameExamine the command output and look for SupportsMfa : True. If you do not see this, then run this command to set it:
Set-MsolDomainFederationSettings -DomainName yourDomainName -SupportsMFA $trueIn the AD FS Management console, navigate to Relying Party Trusts and locate the "Microsoft Office 365 Identity Platform" or "Microsoft Office 365 Identity Platform Worldwide" relying party.
Right click the "Microsoft Office 365 Identity Platform" or "Microsoft Office 365 Identity Platform Worldwide" relying party and click Edit Claim Issuance Policy.
On the "Issuance Transform Rules" tab, click Add Rule....
Select the Pass Through or Filter an Incoming Claim claim rule template and click Next.
Give your new claim rule a name, and then in the "Incoming claim type" field type in Authentication Methods References. Do not try to select this using the drop-down list, because the required value is not present. You must type it in exactly as shown.
Leave the "Pass through all claim values" option selected and then click Finish to save your new claim rule and return to the list of issuance transform rules
Click OK to apply your new claim rule for Authentication Methods References to the 365 relying party.
When a user authenticates to Microsoft Online services through this AD FS server or farm with Duo installed, and completes Duo 2FA, this rule includes the multipleauthn claim for multifactor authentication in the response from AD FS.
To test your setup, use a web browser to log into a relying party for your AD FS deployment. As an example, you might log into https://portal.microsoftonline.com to access Office 365.
Enter the primary username and password as usual.
The AD FS page briefly indicates that it's necessary to redirect you to Duo for authentication then performs the redirect.
Complete Duo two-factor authentication when prompted and then you'll return to AD FS to complete the login process to your relying party.
*Universal Prompt experience shown.
Visit our guides to protecting popular cloud applications like Google G Suite and Office 365 with Duo's powerful two-factor authentication for AD FS.
Office 2013 and 2016 desktop applications (including Outlook and Skype for Business) can connect to Office 365 after Duo AD FS adapter installation only if Modern Authentication is enabled for your Office 365 tenant (or you've constructed your MFA rules to exclude Office client applications). More information about Modern Authentication, including a list of Office applications that support Modern Authentication, is available at the Office Blog.
To upgrade the Duo AD FS plugin server, first disable the Duo Authentication for AD FS authentication method in the AD FS Management console.
Launch the AD FS Management console on your AD FS internal server.
Navigate to AD FS → Authentication Policies and click the Edit Global Multi-factor Authentication... action (AD FS 2012 R2) or AD FS → Service → Authentication Methods and click the Edit Multi-factor Authentication Methods... action (AD FS 2016+).
Uncheck the box next to the Duo Authentication for AD FS X.X.X.X authentication method to disable Duo protection. Note that in older releases of Duo for AD FS the authentication method is called Duo Security for AD FS 3.0.
Download the most recent Duo AD FS Installer Package for AD FS and run the MSI from an elevated command prompt. View checksums for Duo downloads here.
Follow the on-screen prompts to complete the upgrade installation.
When the installer is finished, repeat the steps you originally followed to enable the Duo method in AD FS. Users may log on to federated services without two-factor protection until you've re-enabled the Duo authentication method.
If you have deployed AD FS as farm, you'll need to upgrade Duo on each of your servers. For a WID farm, install Duo on the primary server first. If you have a SQL farm, you may begin with any node.
Need some help? Take a look at the AD FS Frequently Asked Questions (FAQ) page or try searching our AD FS Knowledge Base articles or Community discussions. For further assistance, contact Support.
