Show
Microsoft AD FS (Active Directory Federation Services) is the identity and access management software installed on the Microsoft Windows server. It uses SAML 2.0 and WS-Federation protocols to enable a secure exchange of identity information, attributes, and authentication tokens. As a result, Microsoft AD FS, provides single sign-on (SSO) and identity management, allowing authorized users to access multiple applications located on-premise or in the cloud. By integrating Akamai MFA with Microsoft AD FS, you provide users with strong, two-step authentication to protected resources. See this diagram that presents a conceptual model of the authentication process. For clarity reasons, some traffic flows are not covered. This authentication process refers to users who are enrolled in Akamai MFA. The user attempts to access a protected enterprise application. The application server sends the authentication request to the Windows server. The Windows server validates user credentials against AD FS. AD FS using the Akamai plug-in confirms that the primary authentication succeeded. A connection is established over the TCP port 443, and the user is redirected to Akamai MFA. Akamai MFA challenges the user with secondary authentication. The user confirms their identity using the selected secondary authentication method. Akamai MFA redirects the user to the Windows server. The Windows server redirects the user to the application server. The user gains access to the application. This integration has been tested on Microsoft AD FS on Windows Server 2016. You should have an installed, configured, and working instance of AD FS on Windows Server 2016. This integration communicates with Akamai MFA on TCP port 443. Make sure that your firewall allows outbound connections to the host you specify when you set up the integration. Your <API Host> is available in the Akamai MFA Integrations configuration page. Follow this procedure to generate your integration credentials in Akamai MFA that you have to provide in the following step to enable the communication between AD FS and Akamai MFA. In the Enterprise Center navigation menu, select Multi-factor Authentication > Integrations. Click Add integration (+). In Integration Type, select the ADFS. In Name, enter a unique name for your ADFS integration. Click Save and Deploy. Your Signing Key should be kept completely secret like any other password or secret key credential. Follow these steps to run the AD FS plug-in for Akamai MFA and enable communication between the Microsoft AD FS and Akamai MFA. Download the AkamaiMfaAdfsAdapter.msi installation package. Open Command Prompt as administrator. Launch the installation of the package using the following command msiexec.exe /i <path to AkamaiMfaAdfsAdapter.msi>. In the installer welcome dialog, click Next. In the installer configuration dialog, enter the API Host and your authentication credentials copied in the previous step from the Akamai MFA integration page. Click Next. Click Install to start the installation. When the installation is completed, click Finish. Verify if there are no errors or red texts in the Powershell output to confirm that the installation was successful. Follow this instruction to configure Microsoft AD FS to redirect to Akamai MFA for the secondary authentication. With these settings, you'll also enable Akamai MFA to receive and return authentication requests from the ADFS.
Now, let's update the existing access control policy by applying Akamai MFA.
Follow this instruction to verify your ADFS configuration. With those steps, you can also test the end users' login experience when they attempt to access a protected application.
Learn more about: What's new in Active Directory Federation Services aa892a85-f95a-4bf1-acbb-e3c36ef02b0d What's new in Active Directory Federation Services for Windows Server 2016 The following is a brief summary of updates to protected logins available in AD FS 2019: The following additional security improvements are available in AD FS 2019: For more information, see Customize HTTP security response headers with AD FS 2019 The following authentication/policy capabilities are in AD FS 2019: The following sign-in SSO improvements have been made in AD FS 2019: The following support for building modern LOB apps has been added to AD FS 2019: The following supportability improvements are now part of AD FS 2019: The following deployment updates are now included in AD FS 2019: The following SAML update is in AD FS 2019: Previously, AD FS required the desired resource and scope to be in a separate parameter in any authentication request. For example, a typical oauth request would look like below:
7
https://fs.contoso.com/adfs/oauth2/authorize? With AD FS on Server 2019, you can now pass the resource value embedded in the scope parameter. This is consistent with how one can do authentication against Azure AD also. The scope parameter can now be organized as a space separated list where each entry is structure as resource/scope. [!NOTE]
Only one resource can be specified in the authentication request. If more than one resource is included in the request, AD FS will return an error and authentication will not succeed. OAuth public clients using the Authorization Code Grant are susceptible to the authorization code interception attack. The attack is well described in RFC 7636. To mitigate this attack, AD FS in Server 2019 supports Proof Key for Code Exchange (PKCE) for OAuth Authorization Code Grant flow. To use the PKCE support, this specification adds additional parameters to the OAuth 2.0 Authorization and Access Token Requests. A. The client creates and records a secret named the "code_verifier" and derives a transformed version "t(code_verifier)" (referred to as the "code_challenge"), which is sent in the OAuth 2.0 Authorization Request along with the transformation method "t_m". B. The Authorization Endpoint responds as usual but records "t(code_verifier)" and the transformation method. C. The client then sends the authorization code in the Access Token Request as usual but includes the "code_verifier" secret generated at (A). D. The AD FS transforms "code_verifier" and compares it to "t(code_verifier)" from (B). Access is denied if they are not equal. How to choose additional auth providers in 2019AD FS already supports triggering additional authentication based on claim rule policy. Those policies can be set on a particular RP or at global level. Additional auth policy for a particular RP could be set using the cmdlet Set-AdfsRelyingPartyTrust (AD FS) | Microsoft Docs by passing either AdditionalAuthenticationRules or AdditionalAuthenticationRulesFile parameter. To set it globally admin can use the cmdlet Set-AdfsAdditionalAuthenticationRule (AD FS) | Microsoft Docs. For example, 2012 R2 onwards admin can already write the following rule to prompt additional authentication if the request comes from extranet. Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "https://schemas.microsoft.com/claims/multipleauthn" );' In 2019, customers can now use claims rules to decide which additional authentication provider to invoke for additional authentication. This is useful for two scenarios: Customers are transitioning from one additional authentication provider to another. This way as they onboard users to a newer authentication provider they can use groups to control which additional authentication provider is called. Customers have a need for a specific additional authentication provider (for example, certificate) for certain applications but different method (AzureMFA) for other applications. This could be achieved by issuing the claim https://schemas.microsoft.com/claims/authnmethodsproviders from additional authentication policies. The value of this claim should be the Name of the authentication provider. Now in 2019 they can modify above claim rule to choose auth providers based on their scenarios. Transitioning from one additional authentication provider to another: We will modify the above rule to choose AzureMFA for users that are in group SID S-1-5-21-608905689-872870963-3921916988-12345 (say a group managed by enterprise, which tracks the users that have registered for AzureMFA) and for rest of the users, admin wants to use certificate auth. 'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "https://schemas.microsoft.com/claims/multipleauthn" ); c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-608905689-872870963-3921916988-12345"] => issue(Type = "`https://schemas.microsoft.com/claims/authnmethodsproviders`", Value = "AzureMfaAuthentication"); not exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value=="S-1-5-21-608905689-872870963-3921916988-12345"]) => issue(Type = "`https://schemas.microsoft.com/claims/authnmethodsproviders`", Value = "CertificateAuthentication");’ Example to set two different auth providers for two different applications. Application A to use Azure MFA as additional auth provider: Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "https://schemas.microsoft.com/claims/multipleauthn" ); c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication");' Application B to use Certificate as additional auth provider: Set- Set-AdfsRelyingPartyTrust -TargetName AppB -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "http://schemas.microsoft.com/claims/multipleauthn" ); c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");' Admin can also make rules to allow more than one additional authentication provider in which case AD FS will show all the issued auth methods providers and user can choose any of them. For allowing multiple additional authentication providers, they should issue multiple claim https://schemas.microsoft.com/claims/authnmethodsproviders If none of the auth providers are returned by the claim evaluation, AD FS will fall back to show all the additional auth providers configured by Admin on AD FS and user will need to select the appropriate auth provider. To get all the additional authentication providers allowed, admin can use the cmdlet (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider. The value of https://schemas.microsoft.com/claims/authnmethodsproviders claim should be one of the provider names returned by above cmdlet. There is no support to trigger particular additional auth provider if the RP is using Access Control Policies in AD FS Windows Server 2016 | Microsoft Docs. While moving an Application away from Access control policy, AD FS copies the corresponding policy from Access Control Policy to AdditionalAuthenticationRules and IssuanceAuthorizationRules. So if an admin wants to use particular auth provider, they can moves away from not using access control policy and then modify AdditionalAuthenticationRules to trigger particular additional auth provider. FAQ
Q. Can I pass resource value as part of the scope value like how requests are done against Azure AD? Q. Does AD FS support PKCE extension? What's new in Active Directory Federation Services for Windows Server 2016If you are looking for information on earlier versions of AD FS, see the following articles: AD FS in Windows Server 2012 or 2012 R2 and AD FS 2.0 Active Directory Federation Services provides access control and single sign-on across a wide variety of applications including Office 365, cloud based SaaS applications, and applications on the corporate network.
This article describes what is new in AD FS in Windows Server 2016 (AD FS 2016). Eliminate Passwords from the ExtranetAD FS 2016 enables three new options for sign on without passwords, enabling organizations to avoid risk of network compromise from phished, leaked, or stolen passwords. Sign in with Azure Multi-Factor AuthenticationAD FS 2016 builds upon the multi-factor authentication (MFA) capabilities of AD FS in Windows Server 2012 R2 by allowing sign on using only an Azure MFA code, without first entering a username and password.
For more information about Azure MFA with AD FS
Password-less Access from Compliant DevicesAD FS 2016 builds on previous device registration capabilities to enable sign on and access control based the device compliance status. Users can sign on using the device credential, and compliance is reevaluated when device attributes change, so that you can always ensure policies are being enforced. This enables policies such as
AD FS provides the on premises component of conditional access policies in a hybrid scenario. When you register devices with Azure AD for conditional access to cloud resources, the device identity can be used for AD FS policies as well. For more information about using device based conditional access in the cloud
For more information about using device based conditional access with AD FS Sign in with Windows Hello for Business
Windows 10 devices introduce Windows Hello and Windows Hello for Business, replacing user passwords with strong device-bound user credentials protected by a user's gesture (a PIN, a biometric gesture like fingerprint, or facial recognition). AD FS 2016 supports these new Windows 10 capabilities so that users can sign in to AD FS applications from the intranet or the extranet without the need to provide a password. For more information about using Windows Hello for Business in your organization
Secure Access to ApplicationsModern AuthenticationAD FS 2016 supports the latest modern protocols that provide a better user experience for Windows 10 as well as the latest iOS and Android devices and apps. For more information, see AD FS Scenarios for Developers Configure access control policies without having to know claim rules languagePreviously, AD FS administrators had to configure policies using the AD FS claim rule language, making it difficult to configure and maintain policies. With access control policies, administrators can use built in templates to apply common policies such as
The templates are easy to customize using a wizard driven process to add exceptions or additional policy rules and can be applied to one or many applications for consistent policy enforcement. For more information, see Access control policies in AD FS. Enable sign on with non-AD LDAP directoriesMany organizations have a combination of Active Directory and third-party directories. With the addition of AD FS support for authenticating users stored in LDAP v3-compliant directories, AD FS can now be used for:
For more information, see Configure AD FS to authenticate users stored in LDAP directories. Better Sign-in experienceCustomize sign in experience for AD FS applicationsWe heard from you that the ability to customize the logon experience for each application would be a great usability improvement, especially for organizations who provide sign on for applications that represent multiple different companies or brands. Previously, AD FS in Windows Server 2012 R2 provided a common sign-on experience for all relying party applications, with the ability to customize a subset of text-based content per application. With Windows Server 2016, you can customize not only the messages, but images, logo and web theme per application. Additionally, you can create new, custom web themes and apply these per relying party. For more information, see AD FS user sign-in customization. Manageability and Operational EnhancementsThe following section describes the improved operational scenarios that are introduced with Active Directory Federation Services in Windows Server 2016. Streamlined auditing for easier administrative managementIn AD FS for Windows Server 2012 R2, there were numerous audit events generated for a single request and the relevant information about a log-in or token issuance activity is either absent (in some versions of AD FS) or spread across multiple audit events. By default the AD FS audit events are turned off due to their verbose nature. With the release of AD FS 2016, auditing has become more streamlined and less verbose. For more information, see Auditing enhancements to AD FS in Windows Server 2016. Improved interoperability with SAML 2.0 for participation in confederationsAD FS 2016 contains additional SAML protocol support, including support for importing trusts based on metadata that contains multiple entities. This enables you to configure AD FS to participate in confederations such as InCommon Federation and other implementations conforming to the eGov 2.0 standard. For more information, see Improved interoperability with SAML 2.0. Simplified password management for federated O365 usersYou can configure Active Directory Federation Services (AD FS) to send password expiry claims to the relying party trusts (applications) that are protected by AD FS. How these claims are used depends on the application. For example, with Office 365 as your relying party, updates have been implemented to Exchange and Outlook to notify federated users of their soon-to-be-expired passwords. For more information, see Configure AD FS to send password expiry claims. Moving from AD FS in Windows Server 2012 R2 to AD FS in Windows Server 2016 is easierPreviously, migrating to a new version of AD FS required exporting configuration from the old farm and importing to a brand new, parallel farm. Now, moving from AD FS on Windows Server 2012 R2 to AD FS on Windows Server 2016 has become much easier. Simply add a new Windows Server 2016 server to a Windows Server 2012 R2 farm, and the farm will act at the Windows Server 2012 R2 farm behavior level, so it looks and behaves just like a Windows Server 2012 R2 farm. Then, add new Windows Server 2016 servers to the farm, verify the functionality and remove the older servers from the load balancer. Once all farm nodes are running Windows Server 2016, you are ready to upgrade the farm behavior level to 2016 and begin using the new features. For more information, see Upgrading to AD FS in Windows Server 2016. Page 2
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. |