We have our identity profile configured. Login is to Active Directory - on-prem. When we invite users it is sending them to a blank login page instead of asking them to create the initial password. The URL is auto-generated by ISC. Do we need to open a ticket. This seemed to work for the first couple of weeks but then stopped working.
We don’t have test accounts and have to reuse our accounts. I had my account deleted in AD and deleted my identity account. Next I ran a full aggregation and my account is back. I did this using a second admin account I have. It does not share the same email with my employee account.
Does the blank page occur in multiple browsers? Have you tried to open using private window whether link is working to reset the password? or link is navigating to source, and after that it is showing as blank?
We did not make any changes when it stopped working. We were resetting users and resending the invite as we worked through trying to set up password sync to AD. We changed from SailPoint as the login app to AD and back and forth a couple of times. We finally settled on having to use AD. Use case is current SSPR app is going away and they want to use SailPoint with Security questions. If I copy the url there is no userid attached and it has login in it. I have created a second link that ends in /r/default/reset-password?username=${__recipient.alias}. This will work but would rather use the OOTB path.
Hello Lawrence, the blank login page may be partly expected with PTA, but the full picture depends on your specific setup. When PTA is set to Active Directory, ISC does not prompt users to create a password during registration because it expects them to authenticate with their existing AD credentials. The Inviting Users docs mention that configuring PTA prevents users from being prompted for a password during registration.
Your custom reset link looks like a reasonable workaround. SailPoint documents the reset path as /passwordreset/default/reset-password, with ?username=<username> supported to prefill the user field (Advanced Password Management Options). Your shorter /r/default/reset-password?username=${__recipient.alias} path may work as a redirect, but I would compare it against the documented path if you see inconsistent behavior.
I would verify:
The identity profile is using the intended AD pass-through configuration.
The AD source has Password Management enabled with a password policy associated.
Security questions and password reset options are enabled as expected.
Since the sign-in method was switched between SailPoint and AD a few times, I would open a support ticket. The PTA docs warn against changing the authentication source after users are already in the system without consulting support, so they can confirm whether the ${registrationUrl} behavior is expected or if something got out of sync from the toggling
If ISC will not email user’s their passwords then I believe we have to use the alternate email as you described. It would be nice if a default email for that use case was provided in the email templates.
You have a new user and want them to change their password the first time they sign in to Identity Security Cloud.
A user has forgotten their password and can’t use any of the self-service password reset methods.
A user’s network password has expired, but they usually work outside of the corporate domain or on a computer that doesn’t allow them to change their domain password.
In these cases, you can set a one-time password for your user within your authenticated source and configure them to have to change their password at the next login.
But ISC does not set passwords. So do we need something outside of ISC to set the initial password. The best thing would be to send the user to a reset password link which will update their AD password.
ISC won’t generate or email initial AD passwords, that part is right. But it can reset AD passwords through Password Management. When the AD source has the PASSWORD feature enabled and a password policy associated, the reset page pushes the new password back to AD through the VA and connector. So you don’t need anything outside ISC for this.
The custom email template with a reset link is the right approach for this AD PTA onboarding case. The documented reset path is: /passwordreset/default/reset-password?username=<username> (Advanced Password Management Options)
I would confirm:
AD source has Password Management enabled.
Password policy is associated with the AD source.
The user has a valid email or alternate email to receive the reset link.
The AD-side password policy doesn’t conflict with the ISC password policy.
And yeah, agreed, it would be nice if SailPoint provided a default email template for this use case out of the box.
Another feature I want to turn off. I have the password reset working, however it gives me the option of putting in my userid. I do not want that option allowed. I want that to be greyed out and I am only confirming it.
For the username field, ?username=<username> can prefill it, but I have not seen a documented option to make that field read-only or greyed out. The Advanced Password Management Options doc only covers auto-populating the username.
For the token-based reset link, that is a separate flow. The reset token is generated when the Reset Password action is triggered for the identity. The invite email template does not appear to have a variable that can generate that same reset token directly.
So for a direct token based experience, I would not use the invite email for that part. I would either use the documented reset password URL with the username prefilled, or trigger the Reset Password action separately for the new user if you need the one time token link
Thank you for all your help. In the invite email ?username= did not work for reset. This did work - username=${__recipient.alias}. Seems strange a user can change the id. And the strangest thing is I can put someone else’s id in there and it will send them a code. Then I can successfully change their password if they give me the code. Seems like this should not be allowed. Not a feature
I agree. Being able to initiate a password reset for any username from a prefilled link doesn’t seem ideal. I would suggest raising it with SailPoint Support as a potential security concern rather than just a feature request.