Announcements

SecurID® Community Blog

Subscribe to the official SecurID Community blog for information about new product features, industry insights, best practices and more.

Bypassing SecurID Windows MFA Logins by Specific AD/LDAP Group Membership

ChrisOlive
Employee
Employee
3 0 2,544

A customer asserts:

"In certain circumstances, we would like for certain user logins to bypass Windows MFA altogether. We would like users placed in a special AD group to have this functionality, so we can centrally control when and who can bypass Windows MFA. The group policy object (GPO) for the Windows MFA install does not have a feature that allows us to do this. Local logins may be disabled, but no setting exists in the GPO settings for AD bypass groups."

 

It is possible to address this use case simply and easily.

 

To GPO or To Write a Policy - That Is The Question

 

When the Windows MFA agent is installed, GPO settings are available to enable or disable certain features of the agent itself, local to that machine instance. Understandably, it can be easy to assume features such as the one a customer has addressed and questioned above should be set by GPO. Especially when the customer sees enable and disable settings in the GPO template such as "Disable Cloud Authentication Service authentication for local user accounts" shown below:

 

Screenshot 2019-10-28 00.27.12.png

 

In actuality, this use case is not addressed in the GPO settings, nor would you really want it to be. This use case is a perfect example of how the policy engine itself can be used to make decisions about who is required to step up authentications using MFA and who is not. All that is necessary in this case is to write a two rule set policy to quickly and easily address this use case.

 

Bypassing Windows MFA Logins by Specific AD/LDAP Group Membership

 

Let's make the following assumptions in order to cookbook this use case to success:

 

  1. The Cloud Authentication Service (CAS) policy I am using for Windows MFA logins is named "Windows MFA".
  2. The Active Directory (AD) group I wish to leverage to bypass Windows MFA logins is named "BYPASS_WINDOWS_MFA".
  3. All other users outside of this special bypass group MUST step up authentication using MFA.

 

Let's begin.

 

  1. Login into the CAS Administration Console.
  2. Go to Access -> Policies.
  3. Click on the pulldown next to your policy named "Windows MFA" and select "Edit".
  4. Select "Rule Sets" in the far left hand column to quickly open your rule sets.

 

A basic rule set will likely look as follows:

 

Screenshot 2019-10-28 01.01.25.png

 

This single rule set basically states that "All users in the target population (the ADs or LDAPs you have select in "Identity Sources") are allowed access after they have completed primary authentication as well as passed additional authentication at a 'Low' Assurance Level." (Then the Low Assurance Level shows that a Push To Approve at least is necessary to complete the additional factor of authentication.)

 

All we need in order to allow a bypass group from AD is to place a rule set above this rule set that contains the AD group (or groups) that are allowed to bypass additional authentication.

 

Remember: The access policy acts like an "access firewall." Rule sets that have no matches for target populations fall through to the rule sets below.

 

Let's add the rule we need to allow a special AD group called "BYPASS_WINDOWS_MFA" to bypass additional authentication.

 

1. Add An Additional Rule Set

 

On the same rule set screen, click "Add a Rule Set". A new rule set will appear. Give the rule set a meaningful name such as "Windows MFA Bypass Group." Make sure the Target Population applies to "Selected Users" and click the  Add button, to add the AD group.

 

In the dialog that follows, select the appropriate attribute that aligns to group membership. For AD, the User Attribute will be "virtualGroups". Set the Operation to "Set contains all" and assign the Value as "BYPASS_WINDOWS_MFA". Then click "Save".

 

Screenshot 2019-10-28 01.15.04.png

Make sure for Additional Authentication, you have selected "Not Required". Remember, that is the point, is that users in the BYPASS_WINDOWS_MFA group will NOT be required to provide additional authentication.

 

Your new rule set should look as follows:

 

Screenshot 2019-10-28 01.21.27.png

 

2. Set The Correct Rule Set Order

 

The rule set you have added was added to the bottom of your rule sets (by default) and is not in the proper place for the policy evaluation. It needs to be the first rule set in the policy to allow itself to be inspected first, ahead of everyone else authenticating from your chosen Identity Source.

 

To correct this, click the "Hide Details ^" button at the top of the page to collapse all the rule sets. Now drag and drop the "Windows MFA Bypass Group" rule set to bring it to the top of the rule sets.

 

You policy screen for "Windows MFA" should now look as follows:

 

Screenshot 2019-10-28 01.32.22.png

 

Click "Save and Finish" to save this policy. And don't forget to publish your changes to make them live!

 

Let's Review

 

  1. GPO settings for the Windows MFA agent are specific to the behavior of the agent on the local machine only.
  2. The customer's desire is to leverage a specific AD group to bypass Windows MFA logins.
  3. Because AD is involved, this is a clue to look to the policy engine to handle this use case and not to the GPO settings themselves.
  4. Our existing Windows MFA policy was altered to:
    1. Include a new rule set that addressed the BYPASS_WINDOWS_MFA group in AD and...
    2. Set those authentications to not require additional authentication (as desired).
    3. Then the new rule set was brought to the top of the policy so that it is evaluated first.
  5. Now users placed in the BYPASS_WINDOWS_MFA group in AD will not be required to step up authentication using any MFA authentication method.
  6. All other users not in the BYPASS_WINDOWS_MFA group will be required to step up authentication using an appropriate MFA authentication method.

 

Success!