Allow Group Bypass - non-enrolled users

[olfuddyduddy]

My institution is not licensed for students and so we want students to bypass 2FA. I want to configure a policy that allows bypass across different applications based on an Active Directory group that would be synced. However if the user is synced, they’re partially enrolled and then must complete enrollment and thus consume a license.

The alternative that appears to be the only solution is to configure OU_Exempt on each application within the config of the DUO auth proxy. However, managing a user and determining how they’re configured by looking at AD group membership is easier than and OU path. OU path may change for an account, and thus cause unexpected results.

Are there any alternatives to an OU_Exempt by using an AD group that do not involve partially enrolling users?

[rynothopter]

Unfortunately the workarounds are limited due to how we currently treat those “partially enrolled” users.

For those new to Duo, we define a partially enrolled user as username that exists in Duo but has no 2FA devices attached. This is an important distinction, especially for customers utilizing AD Sync. Setting the New User Policy to “Allow Access” DOES NOT ignore those users as many have assumed. Instead, partially enrolled users will be prompted to enroll during a login attempt. For more information on this and other Duo policies, please check out our Policy Deployment Guide

We are exploring ways to change this behavior to make it more intuitive.

I can think of only two additional options outside of the one you already mentioned. Also keep in mind that not all Duo protected applications will need to use the authentication proxy:

1. Eliminate these partially enrolled users from ever making into Duo in the first place.

   • Within AD (or however you automatically provision users to Duo), create a group that ONLY contains faculty, staff, or other users that will require Duo.
   • Sync this group and for each application, apply an application policy that has the new user policy set to “Allow Access”. Enrolled and partially enrolled users will either be prompted for 2FA or to enroll.
   • End result: Users completely unknown to Duo will bypass 2FA and of course will not consume a license

2. Upgrade to Access to utilize group policy. This would allow you create additional group policies that will override the application policy, allowing you to target specific users groups with specific policies, including the the New User Policy and Group Access Policy (bypasses 2FA and enrollment)

Hopefully this helps!

Regards,
Ryan

[olfuddyduddy]

Hi Ryan,
Conveniently we are licensed for Access. And we do group our staff and students appropriately by AD groups.

Using the group policy was the path I was going down, but targeting groups would require I sync that group. Syncing is bad juju for people you don’t want enrolled. Am I missing a critical step?

Somewhat related, it there a way to block enrollment for a group?

[rynothopter]

Excellent, so you definitely have some flexibility on how to approach this.

In your case, it still sounds like your best and the least complex approach is to set your new user policy for each application to “Allow” and then ensure that the groups you’ve selected to sync with Duo do not contain any student accounts or accounts that you do not want to require 2FA or enrollment. This essentially creates an opt-in experience: Any username that Duo doesn’t know about will not be prompted for 2FA OR enrollment. If you decide to require Duo for additional user audiences, simply add them to one of your Sync’d groups and they will be prompted to complete inline enrollment the next time they login to a Duo protected application (or they could click on an enrollment e-mail link).

** Keep in mind that those partially enrolled users still consume a Duo license!

A second approach would utilize Group Policies.

Let’s say you have your group of users that you want to require and enforce 2FA. We’ll call this group “Duo-2FA-Enforce”.

We don’t want to require users who are not part of this group to have to 2FA or enroll. To accomplish this we will set an Application policy with the “Group Access Policy” set to “Allow Access Without 2FA”.

Next, while still within the application properties, we’ll create a Group Policy and name it “GP-Enforce-Duo”. We’ll then select the “Duo-2FA-Enforce” group as a target group for this policy. This policy with have the “New User Policy” set to Require Enrollment and the Group Policy to “No Action”.

Since group policies override application policies, users who belong to “Duo-2FA-Enforce” will be prompted to 2FA or to enroll. The application policy then applies to everyone else logging into the application, so users who do not belong to our “Duo-2FA-Group” will not have to 2FA or enroll.

The drawback with this approach becomes determining when a user or group of users has completed enrollment. If you happen to sync in additional new AD groups and have enrollment e-mail enabled, 2FA or inline enrollment will not be required until you modify the group policy to also target those newly imported groups. Users could still of course enroll at any time by clicking the link in the enrollment e-mail. This provides a grace period between when a user enrolls and when they may begin to actually see 2FA when logging into an application.

Hopefully this provides some food for thought!

Regards,
Ryan

[rynothopter]

I forgot to answer your second question “Is there a way to block enrollment for a group”

Setting the new user policy to “deny access” will essentially prevent inline enrollment AND blocks access to the application until the user enrolls a device through some other mechanism (e-mail enrollment, call the help desk to have a device manually added). Note that this posture will block access to the application for both unknown and partially enrolled users.

Regards,
Ryan