Protect employee accounts in on-prem software?

Hi all, was curious if anyone has a recommendation for how to accomplish my use case with Duo, or knows it may not be possible.

I sell a web-based application for customers to install on their own websites. It has its own internal user database and authentication + 2fa methods, where the 2fa includes the typical options like webauthn, yubiotp, etc. Sometimes customers request technical support, and as a result must add one or more of our staff as a user in their own copy of the software. Upon login our staff should add a 2fa method, upon completion of the support request our staff are supposed to ask the customer to delete the user account they’d created for support, and then we of course hope the customer does so. These are three steps all subject to human error.

We would like to ensure there is no situation where such an account could sit there dormant to later be used in an unauthorized manner. The idea is that since we already use Duo for MFA, we could release an update for our software that forces any account ending in our email domain to go do the second factor at Duo rather than one of the internal methods. Then, even if an account is left around, and later has its password compromised, the login would only succeed if the account is also still present and active in Duo, and the bad actor is able to complete the Duo second factor for that particular employee. This would put a stop to access by terminated accounts, those whose second factor was stolen and updated on our side, etc.

We thought Duo’s Web SDK was the way to go but the secret key you’re issued seems to be able to create users in Duo. Obviously we can’t bundle that into the software and distribute it. We were hoping it was more like an SSH public key where having possession of it just means you could add it to other apps without authorization, but it wouldn’t compromise Duo or existing apps since they’d be using different keys.

Any ideas? Thanks!

Hi @colohost ,

The integration & secret key for the WebSDK (or any application that you create in Duo besides the Admin API) itself does not permit Duo users to be created. What may be happening is that the New User Policy is currently set to Require enrollment, which allows inline enrollment. This means that if a user successfully authenticates via 1st factor (primary) authn but Duo is unaware of the username, it will create said Duo user on the fly and prompt for 2FA device enrollment. Setting this Policy to Deny access will ensure that only users known to Duo (and in an active state) are challenged for 2FA (Knowledge Base | Duo Security).

The safest option (and I apologize if I misinterpret your use case) might be to bundle the WebSDK within your software but require the customer to integrate it via their own instance of Duo (wherein they could input their own integration/secret key and API hostname) for protecting their Duo users. Here is an example: Configure Duo Security for Use with JumpCloud MFA

Hope this helps!