Device Enrollment through SailPoint

I’m looking for a little guidance on an issue that we have. We use SailPoint IdentityIQ 8.0p1 as our IDAM and password reset solution, and I’m trying to come up with a way for new users to reset their temporary password, who don’t have a device enrolled in Duo yet. Our IdentityIQ implementation requires Duo MFA for all logins, and all new user accounts are forced to change their password on the next login. Since IdentityIQ doesn’t support inline registration, the reset process just fails. The users have active Duo accounts, which are being created by Duo using the AD sync process to pull all accounts in a certain AD group, and then sends the enrollment email to their company email address. They can’t get to this email without logging in, and they can’t login due to the issue mentioned above.

Since I’m a developer in IdentityIQ, and we have already customized the MFA form in it, I’m trying to see if I can get the enroll_portal_url from Duo on the PreAuth call. Unfortunately, our Test Duo system is only sending back “deny” instead of “enroll” in the PreAuth response when the user has an active account, but no devices are enrolled. My Duo admin tells me its because they don’t have “auto-enroll” turned on in Test.(limited licenses) Is that why I never get the “enroll” response, or is there some other setting that I might need to have changed? I have also tried posting a message to the “enroll” endpoint in Duo, but then I get an error back stating that the account already exists. These are already active Duo accounts, so I’m not sure why the “auto-enroll” setting would matter, I’m just trying to get a new device enrollment URL to present to the user, instead of the one that is sitting in their inbox.

I greatly appreciate any help you can provide.
Mike Frank

If your Duo admin means that they have a policy applied to the IdentityIQ Auth API application that sets “New User policy” to “Deny access to unenrolled users”, then yes, that is why you receive a deny response from /preauth instead of an enroll response.

Okay thanks, that helps a lot to explain things. So probably a question for our admin, but would we have been able to set that as a global policy for the whole test environment, or would each API application have to have that “Deny…” set on it? If it’s just on the IIQ app, then maybe I can get them to temporarily change it for just IIQ, so that I can do some testing with it. I believe it is allowed in our production environment, but for obvious reasons, I can’t modify production IIQ code for testing.

A custom policy with a different “New User Policy” setting can be applied to an individual Auth API integration at the application level for all users, or to selected user groups at the application level, and it overrides the global policy. Learn how Duo custom policy works.