ADFS Associating Multiple MFA Providers to Active Directory Groups Groups

Where I work, we heavily use Active Directory Federation Servers (ADFS) as our preferred SSO provider. We have been looking to switch from our existing MFA provider to Azure MFA. Upon configuring our test environment with multiple MFA providers I found that this requires users to select which MFA provider to use at login.

For us, this is far from ideal, we would prefer to manage this on behalf of the user. With a large and diverse user base it can be a significant challenge communicating changes, especially with big bang changes. We want to be able to pilot and deploy Azure MFA without affecting the community of users that have not yet been migrated.

The ideal solution would be to have the assignment of MFA provider to be associated to an AD group. There is no way of configuring this in the GUI and was not able to find any documentation on how to accomplish this, so I contacted Microsoft support.

Thankfully they came back with a solution, it’s a a new feature in Windows Server 2019.

It requires that:

  • The ADFS environment is running Windows Server 2019 at a Farm Behaviour Level of 4 (ADFS 5).
  • All relying trusts for claims rules are updated with the additional authentication rules as described below.
  • Access Control rules need to be removed from all RPTs in favour of additional authentication rules.

Step 1

Find the MFA provider names for from ADFS using the following Powershell command on the ADFS server:

Step 2

Create 2 groups in Active Directory for each MFA provider and find their group SIDs. Can achieved with the following Powershell on a domain controller, where MFA-Provider1 is replaced by the name of your group.

In your production environment, you will want to make sure that all ADFS users are made a member of the group created for your current MFA provider.

Step 3

Create file for the MFA rules, for example “MFARules.txt”, and dependent on your MFA requirements add one of the following to the top of the text file:

A: For MFA to be challenged inside and outside the corporate network, then add the following:

=>issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod”,Value = “http://schemas.microsoft.com/claims/multipleauthn”);

B: For MFA to be challenged outside the corporate network only, then add the following:

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”);)

Step 4

Add the below to the text file, replacing the values in bold with the MFA provider name and group SID from steps 1 & 2 (keep the quotation marks).

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “GROUP SID FOR FIRST MFA PROVIDER (from step 2)” “, Issuer == “AD AUTHORITY”] => issue(Type = “http://schemas.microsoft.com/claims/authnmethodsproviders”, Value = “NAME OF FIRST MFA PROVIDER (from step 1)“, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, ValueType = c.ValueType); c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “GROUP SID FOR SECOND MFA PROVIDER (from step 2)” “, Issuer == “AD AUTHORITY”] => issue(Type = “http://schemas.microsoft.com/claims/authnmethodsproviders”, Value = “NAME OF FIRST SECOND PROVIDER (from step 1)” “, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, ValueType = c.ValueType);

Step 5

If you have an access control policy for on a replying party trust, you will need to first disable this as it cannot be used in conjunction with additional authentication rules. Use the following Powershell:

And finally, assign policy to the relying party:

It is likely in a large production environment such as ours, you will already have a complex set of additional authentication rules, so these need to be checked carefully before any changes are made and the steps above altered appropriately.

It is also worth using Microsoft’s claims X-Ray tool to validate your rules before applying them, see:

https://adfshelp.microsoft.com/ClaimsXray/TokenRequest

Microsoft Connected Cache Stats From IIS Logs

Recently we have had some issues with Windows Update network utilisation, to tackle this we have enabled Microsoft Connected Cache on some of our System Center Configuration Manager (SCCM) distribution points. This is a new feature available with System Center Current Branch 1906+ technology that provides a dedicated local server.

Microsoft have some great documentation on implementing this here: https://docs.microsoft.com/en-us/configmgr/core/plan-design/hierarchy/microsoft-connected-cache

You can see quite easily from the cache folder created by Connected Cache how much data cached, however it’s not so easy to see:

  • How much data clients are downloading from the cache server.
  • Which network locations are they downloading from, want to know it’s being downloaded from the expected network locations.

I’ve noticed SCCM can be a bit sluggish updating the Delivery Optimisation registry key, so there is some concern that users moving between networks. It writes these settings here:

Note: Useful for debugging, when connected cache is enabled a value named “DOCacheHost” is created here for clients in the relevant boundary group which holds the Connected Cache (Distribution Point) server name.

To tackle this I have have written a PowerShell script that parses IIS log data downloaded from a connected cache server. Clients connecting have the User Agent string “Microsoft-Delivery-Optimization/10.0”. This tells me how much data has been transferred and which subsets and IP address have downloaded content.

Download from https://github.com/Sysfcuk/ConnectedCacheStats or code below: