Configuring Duo Access Gate and Self-Service Portal


#1

Greetings all. We have deployed the Duo Access Gateway (DAG) in our organization to fulfil the role of providing access for our users as a Self-Service Portal to manage their devices. One of the issues we’ve run into is attempting to craft a policy that performs the following functionality:

  • External Access - Deny unenrolled users from enrolling their device(s) from outside our secure corporate network(s), yet allow enrolled users to be prompted for 2FA to manage changes to their Duo profile when accessing the Self-Service Portal once authenticated.
  • Internal Access - Allow unenrolled and enrolled users to enroll and/or manage device(s) whilst connected to our secure corporate network(s) when accessing the Self-Service Portal once authenticated…

Thus far, the policies I’ve crafted either blocks all enrollment access from internal or external sources, or allows enrollment from all sources. The concern is worst case scenario a users credentials are compromised, and used by the unknown third party to enroll devices under the aforementioned users credentials without their knowledge or ours. The policies follow:

Device Mgmt Portal Policy - Deny External Enrollment

This policy applies to: Device Management Portal (for Duo - Test1, Duo - Test2).

Enabled New User Policy Deny access to unenrolled users.
Enabled Group Access Policy No effect.
Enabled Remembered Devices Do not remember devices.

Device Mgmt Portal - Internal Enrollment

This policy applies to: Device Management Portal (for Duo - Test1, Duo - Test2).

Enabled New User Policy Prompt unenrolled users to enroll whenever possible.
Enabled Group Access Policy No effect.
Enabled Remembered Devices Do not remember devices.
Enabled Authorized Networks Require 2FA for these networks: Specific Internal/External Network(s).

If anyone has suggestions or a sample of how they have their policy(ies) configured sans any sensitive information contained therein, I would appreciate sharing the knowledge. Or if this is something that currently is unavailable, but may be a future feature request, I’ll take that as well.

Thanks.

Kevin


#2

Kevin,

Thanks for providing the detail on what you are trying to accomplish as well as what you have tried so far.

Setting the new user policy to “Deny Access” accomplishes only part of your requirement to ensure that only users who have attached at least one 2FA device to their account can log to manage devices after successfully completing 2FA. Unenrolled users are denied and not offered the option to enroll a new device. It will not satisfy the requirement of preventing the scenario of compromised credentials.

One possible option is to spin up a second DAG to handle new user enrollments from your internal network. Here, the new user policy would be set to “Require Enrollment”. Access to this DAG would then be restricted ONLY to internal networks via traditional network level controls. This allows users who have not yet enrolled a device to do so. Users who have previously enrolled will be prompted for 2FA before they are allowed to manage their devices.

In summary:

External DAG
DNS - external.devicemanagement.mycompany.com
New User Policy - Deny Access
IP address x.x.x.x
Accessible from external networks

Internal DAG
DNS - internal.devicemanagement.mycompany.com
New User Policy - Require Enrollment
IP address y.y.y.y
Only accessible from internal networks

If you have the ability to configure split DNS resolution for internal vs. external networks, you could essentially make this transparent to your end users regardless of whether they try to access the Device Management portal internally vs externally using the same URL.

We’re aways interested in feedback and use cases regarding policies. I can definitely see the benefit of having a way to accomplish this via Duo policy vs. separate portals and additional infrastructure. I will make sure to file a feature request for this type of capability.

Hopefully this helps!

Regards,
Ryan


#3

Ryan,

Thank you for the reply and suggested solution for my query. If/when this feature becomes available, looking forward to implementing it.

Have a great day.

  • Kevin