Export (0) Print
Expand All

Using Multi-Factor Authentication with Active Directory Federation Services

Published: May 20, 2013

Updated: February 10, 2014

WarningWarning
This article pertains to AD FS 2.0. For information on using Azure Multi-Factor Authentication Server with AD FS for Windows Server 2012 R2 see Walkthrough Guide: Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications.

Active Directory Federation Services (ADFS) is a component in Microsoft® Windows Server™ that provides web Single Sign-On (SSO) technologies through federation using standard authentication mechanisms such as Security Assertion Markup Language (SAML) and Kerberos. It does this by sharing digital identity and entitlement rights or “claims” across security and enterprise boundaries, effectually extending Active Directory to the Internet. ADFS is therefore used to validate a user’s identity when they attempt to access a cloud-based service such as Microsoft® Office 365™. When users navigate to the cloud service, they are redirected so that ADFS can perform the authentication. Once authenticated, a claim or assertion is provided back to the cloud service, which then grants the user access. Azure Multi-Factor Authentication can be added to the ADFS authentication process to add a second factor of authentication for enhanced security.

The IIS Authentication section of the Azure Multi-Factor Authentication Server allows the administrator to enable and configure IIS authentication for integration with Microsoft IIS web applications, including ADFS 2.0. The Azure Multi-Factor Authentication Server installs a plug-in which can filter requests being made to the IIS web server in order to add Azure Multi-Factor Authentication. An IP whitelist can be configured to exempt internal IP addresses from multi-factor authentication if desired. The Azure Multi-Factor Authentication configuration to secure ADFS varies slightly depending on whether your environment uses an ADFS proxy server or not.

To secure ADFS with a proxy, install the Azure Multi-Factor Authentication Server on the ADFS proxy server and configure the Server per the following steps.

  1. Within the Azure Multi-Factor Authentication Server click the IIS Authentication icon in the left menu.

  2. Click the Form-Based tab.

  3. Click the Add… button.

  4. To detect username, password and domain variables automatically, enter the Login URL (e.g. https://sso.contoso.com/adfs/ls) within the Auto-Configure Form-Based Website dialog box and click OK.

  5. Check the Require Azure Multi-Factor Authentication user match box if all users have been or will be imported into the Server and subject to multi-factor authentication. If a significant number of users have not yet been imported into the Server and/or will be exempt from multi-factor authentication, leave the box unchecked. See the help file for additional information on this feature.

  6. If the page variables cannot be detected automatically, click the Specify Manually… button in the Auto-Configure Form-Based Website dialog box.

  7. In the Add Form-Based Website dialog box, enter the URL to the ADFS login page in the Submit URL field (e.g. https://sso.contoso.com/adfs/ls) and enter an Application name (optional). The Application name appears in Azure Multi-Factor Authentication reports and may be displayed within SMS or Mobile App authentication messages. See the help file for more information on the Submit URL.

  8. Set the Request format to “POST or GET”.

  9. Enter the Username variable (ctl00$ContentPlaceHolder1$UsernameTextBox) and Password variable (ctl00$ContentPlaceHolder1$PasswordTextBox). If your form-based login page displays a domain textbox, enter the Domain variable as well. You may need to navigate to the login page in a web browser, right-click on the page and select “View Source” to find the names of the input boxes within the login page.

  10. Check the Require Azure Multi-Factor Authentication user match box if all users have been or will be imported into the Server and subject to multi-factor authentication. If a significant number of users have not yet been imported into the Server and/or will be exempt from multi-factor authentication, leave the box unchecked. See the help file for additional information on this feature

  11. Click the Advanced… button to review advanced settings, including the ability to select a custom denial page file, to cache successful authentications to the website for a period of time using cookies and to select how to authenticate the primary credentials.

  12. Since the ADFS proxy server is not likely to be joined to the domain, you will likely use LDAP to connect to your domain controller for user import and pre-authentication. In the Advanced Form-Based Website dialog box, click the Primary Authentication tab and select “LDAP Bind” for the Pre-authentication Authentication type.

  13. When complete, click the OK button to return to the Add Form-Based Website dialog box. See the help file for more information on the advanced settings.

  14. Click the OK button to close the dialog box.

  15. Once the URL and page variables have been detected or entered, the website data will display in the Form-Based panel.

  16. Click the Native Module tab and select the server, the website that the ADFS proxy is running under (e.g. “Default Web Site”) or the ADFS proxy application (e.g. “ls” under “adfs”) to enable the IIS plug-in at the desired level.

  17. Click the Enable IIS authentication box at the top of the screen.

  18. The IIS authentication is now enabled. However, in order to perform the pre-authentication to your Active Directory (AD) via LDAP you must configure the LDAP connection to the domain controller. To do this, click the Directory Integration icon.

  19. On the Settings tab, select the Use specific LDAP configuration radio button.

  20. Click the Edit… button.

  21. In the Edit LDAP Configuration dialog box, populate the fields with the information required to connect to the AD domain controller. Descriptions of the fields are included in the table below. Note: This information is also included in the Azure Multi-Factor Authentication Server help file.

  22. Test the LDAP connection by clicking the Test button.

     

    Field

    Description

    Server

    Enter the hostname or IP address of the server running the  LDAP directory.  A backup server may also be specified separated by a semi‐colon.

    Note: When Bind Type is SSL, a fully‐qualified hostname is  generally required and it must match the name on the SSL  certificate installed on the LDAP directory server. 

    Base DN

    Enter the distinguished name of the base directory object from  which all directory queries will start.  For example, dc=contoso,dc=com.

    Bind type - Queries

    Select the appropriate bind type for use when binding to search the LDAP directory.  This is used for imports, synchronization, and username resolution.

    Anonymous ‐ An anonymous bind will be performed.  Bind DN and Bind Password will not be used.  This will only work if the LDAP directory allows anonymous binding and permissions  allow the querying of the appropriate records and attributes.

    Simple ‐ Bind DN and Bind Password will be passed as plain text to bind to the LDAP directory.  This should only be used for testing purposes to verify that the server can be reached and  that the bind account has the appropriate access.  It is  recommended that SSL be used instead after the appropriate  cert has been installed.

    SSL ‐ Bind DN and Bind Password will be encrypted using SSL to bind to the LDAP directory.  This requires that a cert be installed on the LDAP directory server that the Azure Multi-Factor Authentication Server trusts.

    Windows ‐ Bind Username and Bind Password will be used to securely connect to an Active Directory domain controller or ADAM directory.  If Bind Username is left blank, the logged‐on  user's account will be used to bind. 

    Bind type - Authentication

    Select the appropriate bind type for use when performing LDAP bind authentication.  See the bind type descriptions under Bind type ‐ Queries.  For example, this allows for Anonymous bind to  be used for queries while SSL bind is used to secure LDAP bind  authentications. 

    Bind DN or Bind username

    Enter the distinguished name of the user record for the account to use when binding to the LDAP directory.  The bind distinguished name is only used when Bind Type is Simple or  SSL.   

    Enter the username of the Windows account to use when binding to the LDAP directory when Bind Type is Windows.  If left blank, the logged‐on user's account will be used to bind. 

    Bind Password

    Enter the bind password for the Bind DN or username being used to bind to the LDAP directory.  To configure the password for the Multi-Factor Auth Server AdSync Service, synchronization must be enabled and the service must be running on the local machine.   The password will be saved in the Windows Stored Usernames and Passwords under the account the Azure Multi-Factor Authentication Server AdSync  Service is running as.  The password will also be saved under the account the Multi-Factor Auth Server user interface is running as and under the account the Azure Multi-Factor Authentication Server Service is running as.    Note:  Since the password is only stored in the local server's  Windows Stored Usernames and Passwords, this step will need  to be done on each Multi-Factor Auth Server that needs access to the password. 

    Query size limit

    Specify the size limit for the maximum number of users that a directory search will return.  This limit should match the configuration on the LDAP directory.  For large searches where  paging is not supported, import and synchronization will  attempt to retrieve users in batches.  If the size limit specified  here is larger than the limit configured on the LDAP directory,  some users may be missed. 

  23. If the LDAP connection test was successful, click the OK button.

  24. Next, click the Company Settings icon and select the Username Resolution tab.

  25. Select the Use LDAP unique identifier attribute for matching usernames radio button.

  26. If users will enter their username into the ADFS proxy login form in “domain\username” format, the Server needs to be able to strip the domain off of the username when it creates the LDAP query. That can be done through a registry setting.

  27. Open the registry editor and go to HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Positive Networks/PhoneFactor on a 64-bit server. If on a 32-bit server, take the “Wow6432Node” out of the path. Create a new DWORD registry key called “UsernameCxz_stripPrefixDomain” and set the value to 1. Azure Multi-Factor Authentication is now securing the ADFS proxy. Ensure that users have been imported from Active Directory into the Server. See the IP Whitelist section below if you would like to whitelist internal IP addresses so that two-factor authentication is not required when logging into the website from those locations.

To secure ADFS when the ADFS proxy is not used, install the Azure Multi-Factor Authentication Server on the ADFS server and configure the Server per the following steps.

  1. Within the Azure Multi-Factor Authentication Server click the IIS Authentication icon in the left menu.

  2. Click the HTTP tab.

  3. Click the Add… button.

  4. In the Add Base URL dialogue box, enter the URL for the ADFS website where HTTP authentication is performed (e.g. https://sso.domain.com/adfs/ls/auth/integrated) into the Base URL field and enter an Application name (optional). The Application name appears in Azure Multi-Factor Authentication reports and may be displayed within SMS or Mobile App authentication messages.

  5. . If desired, adjust the Idle timeout and Maximum session times.

  6. Check the Require Azure Multi-Factor Authentication user match box if all users have been or will be imported into the Server and subject to multi-factor authentication. If a significant number of users have not yet been imported into the Server and/or will be exempt from multi-factor authentication, leave the box unchecked. See the help file for additional information on this feature.

  7. Check the cookie cache box if desired.

  8. Click the OK button.

  9. Click the Native Module tab and select the server, the website that ADFS is running under (e.g. “Default Web Site”) or the ADFS application (e.g. “ls” under “adfs”) to enable the IIS plug-in at the desired level.

  10. Click the Enable IIS authentication box at the top of the screen. Azure Multi-Factor Authentication is now securing ADFS. Ensure that users have been imported from Active Directory into the Server. See the IP Whitelist section below if you would like to whitelist internal IP addresses so that two- factor authentication is not required when logging into the website from those locations.

The IP Whitelist allows users to bypass Azure Multi-Factor Authentication for website requests originating from specific IP addresses or subnets. For example, you may want to exempt users from Azure Multi-Factor Authentication while logging in from the office. For this, you would specify the office subnet as an IP Whitelist entry. To configure an IP Whitelist use the following procedure:

  1. In the IIS Authentication section, click the IP Whitelist tab.

  2. Click the Add… button.

  3. When the Add Whitelist IP dialog box appears, select the Single IP, IP range or Subnet radio button.

  4. Enter the IP address, range of IP addresses or subnet that should be whitelisted. If entering a subnet, select the appropriate Netmask and click the OK button. The whitelist has now been added.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

Show:
© 2014 Microsoft