Share via

Office 365 customers who have ADFS installed can do simple filtered MFA using ADFS claim rules

  • Article

RECENT UPDATE:
------------------------------------------------------------------------------------------
Please continue to use Azure AD Conditional Access for the future as part of your strategy. Please refer the following article for further information about Azure AD Conditional Access.

Conditional access in Azure Active Directory Azure AD Conditional Access
------------------------------------------------------------------------------------------

Small Medium sized Office 365 customers may not want to deploy on premises MFA server if the requirements are very simple and scope is limited to Office 365 workloads only.

Small Medium sized Office 365 customers who want to enable MFA may want to skip AppPassword based authentication for rich clients and activesync clients but most want to do MFA when the web based access happens to Office 365 outlook web access or similar web based services.

This solution is mainly for Small Medium sized Office 365 customers.

MFA helps secure user sign-ins for cloud services beyond just a single password. With MFA for Office 365, users are required to acknowledge a phone call, text message, or app notification on their smart phones after correctly entering their passwords. They can sign in only after this second authentication factor has been satisfied.

A form of multi-factor authentication is included with Office 365, but you can also purchase Azure Multi-Factor authentication that includes extended functionality.

Multi-factor authentication is enabled per user. This means that if a user has been enabled for multi-factor authentication and they are attempting to use non-browser clients, such as Outlook with Office 365, they will be unable to do so. An app password allows this to occur. An app password, is a password that is created within the Azure portal that allows the user to by-pass the multi-factor authentication and continue to use their application.

Some customers may find AppPasswords difficult to manage for basic users as it needs another credentials set for users to remember.

Simple solution would be enable MFA only for web based clients when they access from internet initially. For Outlook and ActiveSync clients some customers may want to bypass MFA due to AppPassword requirements if they don't support MFA natively.

Scenario is simple: Customer has Office 365 and Azure AD tenant implicitly. They have ADFS and ADFS proxy to redirect federated domain authentication requests to STS servers first. Then the second will be Azure AD MFA if the client is web browser and if the client is accessing from the internet. They don't have any Azure AD MFA server on premises installed on ADFS as additional authentication provider.

null

Step 1:
Enable MFA for some Office 365 users.

To set up multi-factor authentication for Office 365
1. Sign in to the Office 365 admin center.
2.In the admin center, choose users and groups > Active Users.
3.In the classic admin center, next to Set Multi-factor authentication requirements, choose Set up.
Set up multifactor authentication.
In the admin center preview, choose More > setup azure multi-factor auth.
Set up multifactor authentication
4.Find the user or users that you want to enable for MFA. In order to see all the users, you might need to change the view at the top.
The views have the following values based on the MFA state of the users:
Disabled
This is the default state for a new user not enrolled in multi-factor authentication.
Enabled
The user has been enrolled in multi-factor authentication, but has not completed the registration process. They will be prompted to complete the process the next time they sign in.
Enforced
The user may or may not have completed registration. If they have completed the registration process then they are using multi-factor authentication. Otherwise, the user will be prompted to completer the process at next sign-in
In non-browser apps (such as …Outlook etc.) will not work until app passwords are created and entered into the non-browser apps.
5.Check the check box next to the names you chose.
Users selected for MFA.
6.This will reveal two options on the right: Enable and Manage user settings. Choose Enable.
7.In the dialog box that opens, choose enable multi-factor auth.

Step 2:
Set SupportsMFA flag to False.
SupportsMFA feature has been enabled for all tenants on Production. This feature changes MFA behavior so that for federated tenants, by default MFA happens on the cloud. The old default behavior was MFA on prem. We have done backfilling to set a flag to true to ensure customers who were using MFA on-prem continue to have MFA on prem. The switch lets tenant admin control where he wants MFA. Switch essentially sets flag SupportsMFA on the trusted realm object. SupportsMFA as true means ESTS must redirect user to ADFS for MFA if MFA is required and MFA claim is missing. SupportsMFA as false means ESTS does MFA natively (again assuming MFA is required and MFA claim is missing). If flag is not set, it is assumed to be false. Users won't be double MFA'd. If MFA was already done at ADFS as part of login, MFA claim will be present and ESTS won't ask for MFA again.

Do MFA on premises:
Set-MsolDomainFederationSettings -DomainName -SupportsMFA $true

Do MFA on cloud:
Set-MsolDomainFederationSettings -DomainName -SupportsMFA $false

Identifying where Current MFA is being done
To determine if the customer has a configuration that forces MFA to be performed at the on-premises Identity Provider:

Ensure the most current version of MSONLINE Powershell Module has been downloaded
Launch MSONLINE powershell
Type Connect-MSOLService
Type Get-MSOLDomainFederationSettings –DomainName

In the Output, look for SupportsMFA value
If SupportsMFA == TRUE, then the CloudIDP expects MFA authentication to happen on-premises
If SupportsMFA == FALSE, then the CloudDIP expects to perform MFA authentication for the principal

$credential = Get-Credential Connect-MsolService -Credential $credential Set-MsolDomainFederationSettings -DomainName "verifieddomain.com" -SupportsMfa $false Get-MsolDomainFederationSettings -DomainName "verifieddomain.com" null

STEP 3:
Create 2 new custom claim rules in ADFS.

Start the AD FS Management console.
Navigate to Relying Party Trusts and right-click on the OFFICE 365 Relying Party Trust. Select Edit Claim Rules…
Click Add Rule…
From the drop down, select Send Claims Using a Custom Rule and click Next.
Enter any name for the claim rule such “Rule1”.
Under Custom rule: add the following text
Click OK.
Click Add Rule…
From the drop down, select Send Claims Using a Custom Rule and click Next.
Enter any name for the claim rule such “Rule2”.
Under Custom rule: add the following text
Click OK. Click Finish. Close the AD FS Management console.

NOTE: sending the multipleauthn claim is a work-around to skip MFA when the user is inside the network, but the workaround implies that the user has performed MFA on-premises, thus forcing Azure AD to skip MFA.

If the client is not from Internet, then do not perform MFA in Azure AD.
CLAIM RULE1:

not exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) => issue(Type = "https://schemas.microsoft.com/claims/authnmethodsreferences", Value = "https://schemas.microsoft.com/claims/multipleauthn"); null

If the client type is not web browser, then do not perform MFA in Azure AD.
CLAIM RULE2:

not exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value =~ "(/adfs/ls)|(/adfs/oauth2)"]) => issue(Type = "https://schemas.microsoft.com/claims/authnmethodsreferences", Value = "https://schemas.microsoft.com/claims/multipleauthn"); null

You may also want to add another transformation rule to disable MFA for AutoDiscover and ActiveSync.

Exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value =~"^(Microsoft.Exchange.(Autodiscover|ActiveSync))$"])

=> Issue(Type = "https://schemas.microsoft.com/claims/authnmethodsreferences", Value = "https://schemas.microsoft.com/claims/multipleauthn"); 

STEP 4: TEST FROM INTRANET WEB BROWSER CLIENT TO ACCESS OFFICE 365 without MFA
You will notice that only ADFS authentication will be sufficient. MFA will not be performed.

STEP 5: TEST FROM INTERNET WEB BROWSER CLIENT TO ACCESS OFFICE 365 with MFA
You will notice that ADFS authentication will not be be sufficient. MFA will be performed in Azure AD additionaly.

Hope this helps.

Comments

  • Anonymous
    June 07, 2016
    Can Rule 2 be made more granular so that we only exclude activesync, autodiscover and skype for business online from MFA?
    • Anonymous
      June 09, 2016
      actually, the existing rule states that if the request is not coming from a web browser, it is already excluded. so it should be good enough for your requirements.
  • Anonymous
    September 22, 2016
    Thanks for the informative post. A couple of questions:How long after setting the supportsMFA parameter do changes take effect?Will the 'Remember device for X days' feature become available in the MFA Server on-prem version? Currently that appears to only be supported in the Azure MFA cloud-only version.
    • Anonymous
      June 21, 2017
      SupportsMFA flag takes effect immediately. Remember MFA for X Days feature only exists in Azure AD MFA, not in on premises MFA server. Watch out ADFS 2016 built-in Azure AD MFA adapter. May be you would not need to deploy MFA Server on premises for ADFS integration scenarios.
  • Anonymous
    October 10, 2016
    Is it possible to add an additional rule to check member of a group to perform MFA? like: exists([Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value =~ “Group SID value of allowed AD group”])
  • Anonymous
    December 02, 2016
    Can claim rule 1 be amended to so that if the request is not from internet and the request is from an IP range, then do not perform MFA in Azure AD?
  • Anonymous
    December 13, 2016
    Bulent,Is it possible that things have changed on the Azure MFA side because these rules to filter out MFA don't seem to work for our organization
    • Anonymous
      April 09, 2017
      Watch out for new capabilities in Azure AD for conditional access and ADFS 2016 for built-in Azure AD MFA adapter.
  • Anonymous
    May 24, 2017
    Outlook 2013 (with ADAL Regkey) and Outlook 2016 supports Modern Authentication. If Modern authentication is enabled for EXO, then Outlook 2013/2016 can do MFA and wouldn't need App Password.
  • Anonymous
    September 08, 2017
    Does this work with Office 365 Basic MFA ? Basic MFA enabled in portal per user
    • Anonymous
      October 11, 2017
      Yes. it should work. simply put "Office MFA = limited Azure MFA".
  • Anonymous
    November 03, 2017
    Is the same process if I'm working with ADFS 4.0 ? we run following command but we received error "Should not configure authorization rules together with an access control policy"Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules ‘exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”]) && NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value==”Microsoft.Exchange.Autodiscover”]) && NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value==”Microsoft.Exchange.ActiveSync”]) => issue (Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod”, Value = “http://schemas.microsoft.com/claims/multipleauthn”);’
  • Anonymous
    February 06, 2018
    These rules only work when Modern Authentication is disabled? If yes, what's the impact to turn off Modern Authentication at Teams, SPO?
    • Anonymous
      April 13, 2018
      I think it should work with either Modern Authentication enabled or disabled. Please try and let me know. Regards.