Password Sync Group when Accounts Created at Different Times

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

We are trying to come up with a solution for a chicken/egg situation.

We have multiple sources in a single password sync group (AD, EBS). The process is as follows:

  1. The AD account is created with a birthright role when a new identity is onboarded.
  2. The password is generated by SailPoint and the user is required to change it after first login.
  3. After birthright provisioning happens, an EBS Request is made (when applicable), and this could be weeks after a user is onboarded and already has their AD account and they know that password.
  4. SailPoint creates the EBS account with a password based on the Create Profile
  5. SailPoint is taking that newly generated password from the EBS Account creation and syncs it to AD because it’s part of the Password Sync Group

The problem we are having is really with #5.

  • SailPoint doesn’t have a way to notify a user of a password it generates, so the user is either forced to reset their password (if SP randomly generated one), or we have to set a password to a known pattern so they can login the first time.
  • The user has already reset their AD password and now it’s either been reset to something no one knows and they can’t get in, or it’s set to a known pattern that is terrible security practice.
  • If their AD password is changed, this is also changing their Entra ID password and the user is not going to be able to login to SailPoint if they don’t know that password and they are going to have to follow a Forgot Password flow to even be able to manage their passwords in SailPoint

SailPoint has indicated that “This would be the expected behavior. When the password is assigned to the account as part of its creation, that is from a technical perspective a password change. There for, the rest of the sync group should pick it up.”.

Does anyone have any good ideas for how to have the password of an already existing account in a sync group to get to any new accounts in the same sync group?

2

The underlying design is that ISC does not store user passwords in an encrypted format which would be needed to be able to set it on an additional source in the sync group. This would be a security concern if an attacker was able to get to the ISC data and decrypt the passwords.

One approach to notifying the user would be to create a workflow triggered based on “Provisioning Completed” to “Send Email” as the action. Then you could inform the user to change their password which would sync to EBS. By having the user reset their own password, you wouldn’t have to communicate a temporary random password or a pattern.

3

Not sure if this would work but is it necessary to provide password while creating EBS account? what happens if you remove password from create profile and try creating EBS account without that?

4

This is an interesting idea, but I’m wondering if instead the user would have to follow the Forgot Password Flow in IdentityNow to essentially reset their password to a known password for the sync group?

  • The creation of the EBS account will cause their AD account password to be updated and they won’t be able to login to IdentityNow without knowing that new AD password.
  • This client is using Password Interceptor which will bring in the newly changed AD password to IdentityNow and sync it out to anything in that Password Sync group.
  • This client is also using SSO and not local passwords to login to IdentityNow.
5

Good idea! We just tried this, but unfortunately the EBS connector requires a password. If it is not included in the plan, the resulting user creation query throws a missing parameter SQL error.