Active Directory Federation Services (AD FS) in combination with Azure Multi-Factor Authentication (MFA) Server work together when you install and configure the Azure MFA Adapter for AD FS.
Now, per Relying Party Trust (RPT) in Active Directory Federation Services (AD FS), you might want to force the use of a specific Azure Multi-Factor Authentication method.
The default checkboxes in the Global Authentication Policies and Authentication Policies per Relying Party Trust allow to enable and/or disable Multi-Factor Authentication as a requirement to log on on a per user basis, for the extranet and/or intranet and for managed and/or unmanaged devices. Now, for a lot of scenarios, these option are inadequate. Not to worry, because you can use the Edit claim rules… option from the AD FS Management Console (Microsoft.IdentityServer.msc) for a specific Relying Party Trust in the list.
The default way to do this, is to add the following line to the Claims Issuance Rule for the Relying Party Trust (RPT):
=> issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod”, Value = “http://schemas.microsoft.com/claims/multipleauthn”);
Now, this claim rule will trigger the use of Multi-Factor Authentication, but it doesn’t force the use of a specific Azure Multi-Factor Authentication method.
To achieve this, we need to use an additional claims issuance rule.
This is pretty simple, because Azure MFA Server and the Active Directory Federation Services (AD FS) Security Token Service (STS) add the method to a claimtype called authmethod.
When you look at the logging produces when you enable AD FS Auditing, you can clearly see the claimtypes floating by:
Now, in the example above, the last claimtype specifies the the Azure Multi-Factor Authentication method used.
The table below lists the claimtype in relationship with the Azure Multi-Factor Authentication method used, based on AD FS on Windows Server 2012 R2 (AD FS 3.0) and Azure Multi-Factor Authentication Server version 126.96.36.199:
Let’s look at each of these a little deeper:
- http://schemas.microsoft.com/ws/2012/12/authmethod/phoneconfirmation indicates the use of the Standard Phone call.
- http://schemas.microsoft.com/ws/2012/12/authmethod/voicebiometric indicates that Phone call was successful with a PIN returned.
- http://schemas.microsoft.com/ws/2012/12/authmethod/smsreply signals the use of the Two-Way OTP used within the Text message method, whereas http://schemas.microsoft.com/ws/2012/12/authmethod/smsotp indicates One-Way OTP within the Text message method.
- http://schemas.microsoft.com/ws/2012/12/authmethod/phoneappnotification is a result of pressing Verify in the Azure Authenticator Mobile App.
- http://schemas.microsoft.com/ws/2012/12/authmethod/otp is the latest addition to the methods offered by Azure Multi-Factor Authentication Server. It indicates the use of an OATH-compatible token.
- http://schemas.microsoft.com/ws/2012/12/authmethod/kba is one that you won’t find often, since it’s the claim issued when you log in using the security answers. By default, this is a fall-back method to log onto the User Portal, only.
Forcing a method
Now all we need to do, to force the use of the phone call as the specific Azure Multi-Factor Authentication method for a Relying Party Trust in AD FS, is to edit the above Claims Issuance rule to look like this:
=> issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod”, Value = “http://schemas.microsoft.com/ws/2012/12/authmethod/otp”);
Now, this approach leads to a couple of interesting observations:
- The Active Directory Federation Services (AD FS) Extensible Authentication Framework (EAF) feature, that the Azure MFA Adapter uses, does not offer the ability to force a specific authentication method. When you don’t use the method specified, you get prompted for multi-factor authentication again and again. To this purpose, enable the Prompt for user method feature.
- When a user does not have the appropriate method configured, redirect him/her to the MFA Server User Portal to configure it.
Azure MFA Server 188.8.131.52 Release Notes
Choosing the right Azure MFA authentication methods
Azure Multi-Factor Authentication Server version 184.108.40.206 for your convenience
Azure Multi-Factor Authentication Server version 220.127.116.11 is here
Azure Multi-Factor Authentication Server reaches version 18.104.22.168
Prompting colleagues for their Multi-Factor Authentication method in AD FS
very nice post, i undcoubtedly really like this fabulous site, persist with it
We have ADFS acting as a federation provider. In this case can we invoke MFA via claims issuance rule
We ahve ADFS 2016 with Azure MFA (no mfa server). We created the claim rules; no mfa on intranet and require mfa on internet. Works great. But now we want to always enforce mfa on internet, so no caching/lifetime on internet. How can this be achieved?
There are two 'caching' values at play:
First, there is the AD FS Farm-wide SSO lifetime. Its lifetime is 480 minutes. This value can be queried using the Get-ADFSProperties Windows PowerShell Cmdlet. The other 'caching' mechanism is the TokenLifeTime value per Relying Party Trust (RPT). It, too, can be queried using Windows PowerShell. The Get-ADFSRelyingPartyTrust Windows PowerShell Cmdlet is used for it. When its value is 0, it defaults to the value of 60 minutes.
This is the caching that is done by AD FS. On the Azure MFA side, there is a section labeled 'Caching rules'. These rules can be used to eliminate consecutive authentications triggering two-step verification. However, caching rules only apply to MFA Server deployments, so they don't apply in your case.
It is not supported to change the values for the SSOLifeTime (for the AD FS Farm) or TokenLifeTime (for the AD FS RPT).
Thanks for your repsone with a personal touch 🙂
Yes i know about the sso/token-lifetime that ADFS issues and that this gives you the "caching" behaviour. But this is something we don't want, we want always require MFA on extranet.
I was in the asssumption that the require MFA on extranet claim always would trigger MFA but this is not the case so it seems.
My first idea to tackle this problem was to adjust the token lifetime in Azure AD (cause we want always MFA to O365). Internal users would not notice the tokenlifetime change in Azure AD cause they would have SSO from internal ADFS.
But I don't know what happens if you set Azure AD tokenlifetime lower than the on-prem ADFS tokenlifetime. Which tokenlifetime is honoured.
But I think i solved the problem to set the paramter 'alwaysrequireauthentication' on the Relying Party. This requires always authentication for extranet users cause they get FBA and internal users leverage SSO from WIA. This seems to work.
The only problem is when a user has a School or Work account configured in Windows 10 he always has SSO into O365 and Azure AD, because Windows 10 does direct authentication to O365/Azure i think?. Any idea how this could be tackled, maybe Conditional Access with bypass for federated user, but again if CA requires MFA i think the user only has to MFA once if he then closes his browser does he need to do MFA again?
PS. didn't know it was not supported to adjust token/sso lifetime in on-prem ADFS , learned a bit on this road 🙂
When you use AD FS for authentication towards an Azure AD-integrated app, the AD FS token is sent to Azure AD. Azure AD then passes the claim token with the right signature to the application. AD FS doesn't have a RPT with the app, just with Azure AD, so AD FS can't send its claims directly to the Azure AD-integrated application. In my recollection both token lifetime settings apply for users who have authenticated using AD FS.
Windows 10 features the Web Authentication Broker. This feature automatically reaches out to Azure AD to acquire tokens. When Windows Hello is used to logon, the token acquired contains the multi-factor claim.