ADFS Additional Authentication Rules – MFA Issue Type

ADFS Claim / Additional Authentication rules can appear very complex and confusing, and that’s because they are! One thing that tripped me up recently is related to the issue section of a claim rule whereby MFA is specified. During a project, I created a rule from a template I had used for another customer. Upon saving the rule I found that it didn’t apply MFA as I was expecting, and instead caused an error message in ADFS during logon attempts.

The rule I had used was issuing a claim for the Azure MFA Server rather than the Azure MFA Cloud Service. To clarify, the difference in the claim type is as follows:

Azure Cloud MFA

=> issue(Type = "", Value = "");

Azure MFA Server

=> issue(Type = "", Value = "");


This is an important distinction and needs to be considered when applying different types of authentication flows in ADFS.



Azure AD Powershell – Token Lifetime Configuration for MFA

The default token expiry in Azure AD for ADAL clients (using Modern Authentication) is 14 days for single factor and multi factor authentication users. This can stretch up to 90 days as long as the user does not change their password, and they do not go offline for longer than 14 days.

This means that clients using Outlook or Skype for Business can perform MFA once and then remain signed in using their access token for up to 90 days before being required to authenticate using MFA. As you can imagine, this is not an ideal situation for multi-factor authentication as a compromised account could be accessed through a rich client application with no MFA for up to 90 days.

Until recently, this could not be modified. However Microsoft released Configurable Token Lifetime as a Preview feature quite recently. This allows for various properties to be controlled, giving administrators more granular control over token refresh and enforcing a more secure MFA policy.

The Azure team have provided a solid guide here:

To do this, you need the Azure AD Preview PowerShell module. Install this by running the following from a PowerShell prompt:

Install-Module -Name AzureADPreview 

Here is a sample policy I’ve configured which will change the MFA token lifetime to 12 hours. I’ve combined this with ADFS Claim Rules which only enforce MFA if the user is on the extranet and using particular applications:

New-AzureADPolicy -Definition @("{`"TokenLifetimePolicy`":{`"Version`":1, `"MaxAgeMultiFactor`":`"12:00:00`",`"AccessTokenLifetime`":`"04:00:00`"}}") -DisplayName OrganizationDefaultPolicyScenario -IsOrganizationDefault $true -Type TokenLifetimePolicy

This is  a much needed feature from the point of view of security controls, although keep in mind it is still in Preview!



ADFS & Multi Factor Authentication – Force MFA for browser based access to Office 365

Azure MFA is a great concept in itself, especially when applied to Office 365 using ADFS, but quite often there is a need for granular control over when MFA is actually applied. There are GUI options for enabling MFA just for extranet requests, but this poses several problems:

  1. Issues with Autodiscover requests – these are proxied from Office 365 and thus always route via the ADFS Proxy servers. This means that all Autodiscover requests, no matter where the client is located, appear to originate from the internet, which poses a problem when applying MFA to only be enforced for Extranet requests, as Outlook clients will be prompted for MFA even when inside the Intranet.
  2. Mobile Applications – These will likely always come from Extranet locations. It is undesirable, and in some cases unsupported, for these applications to use MFA whenever they are opened.
  3. Skype for Business client – It is not desired to require MFA when Skype for Business is opened from the Extranet.

One thing worth mentioning straight off the bat is that using the Azure MFA server with ADFS requires the ADFS Proxies either use the WAP role in Server 2012 R2 or a 3rd party proxy which can add the claim “” to show whether the connection is coming from the Extranet or not.

If you need more granular control than Extranet or Intranet (taking into account the considerations above), you need to use the Azure MFA server option to integrate MFA with ADFS. This provides the ability to great custom rules for your relying parties. There is a great guide on installation of this service here:

In addition to the MFA Server configuration itself, a custom ADFS claim needs to configured to force MFA if certain conditions are present. This can be very fiddly and currently there are not any GUI based tools to achieve this, so PowerShell is your friend!

For my example, I wanted to force MFA if the request comes from a browser on the extranet. This ensures that Outlook, the Skype for Business client and mobile applications never require MFA, but any access from browsers outside of the local network are MFA secured. The claim looks like this:

c:[Type == "", Value == "false"] && 

c1:[Type == "", Value =~ "(/adfs/ls)|(/adfs/oauth2)"] 

=> issue(Type = "", Value = "");

This rule was applied using the below command. First, the above rule was set as the $mfarule variable.

$mfarule='c:[Type == "", Value == "false"] && c1:[Type == "", Value =~ "(/adfs/ls)|(/adfs/oauth2)"] => issue(Type = "", Value = "");'

Then the Office 365 Relying Party Trust was set as a variable.

$rpt = Get-AdfsRelyingPartyTrust –Name "Microsoft Office 365 Identity Platform"

And then the Authentication Rule was applied to the Relying Party!

Set-AdfsRelyingPartyTrust –TargetRelyingParty $rpt –AdditionalAuthenticationRules $mfarule

Before this was placed into production, a similar claim rule was applied which limited MFA to only a particular group of users. The claim for this is shown below and the group is specified using the ObjectSID. This is useful for testing the rule out on a subset of users:

c:[Type == "", Value == "false"] && c1:[Type == "", Value =~ "(/adfs/ls)|(/adfs/oauth2)"] && c2:[Type == "", Value == "S-1-5-21-3388933763-2387696048-3050347461-86618"] => issue(Type = "", Value = "");

This gave us the settings we needed for compliance, and figuring out the claim rules was complicated but quite fun. I hear that all this functionality will be moving into a GUI based system in Server 2016 so that’ll be nice.

Anyway, if anybody has any particular claim types they would like for particular situations, let me know and we can try and put something together!

DoubleD IT =]

P.S. Huge thanks to Mark Vale and his article on the same subject, it helped me find the light in a very dark tunnel!

Office 365 – MFA support for the Windows Office 2013 suite on it’s way!

Great news for users of Office 365 Multi Factor Authentication! Office 365 MFA is soon to be fully supported in the Office 2013 Windows client applications.

At the moment, MFA only supports web based applications like OWA. If you have MFA enabled and want to use rich client applications such as Outlook 2013, you have to use an App Password. This is a randomly generated 16 digit persistent passcode which is assigned to an individual application, such as Word 2013.This provides a higher level of security than a user specified password however is not as secure as true MFA.

This new functionality will pave the way for customers making use of the integrated Office 365 MFA authentication. Especially considering that it is totally free to enable!

Currently the update is only available to those people taking part in a Private Preview, however interested parties can keep their eyes on the Office 365 roadmap at to find out about release dates for this update.