How to find more information on the generators

[ywu11 (Yun Wu)]

Is there a place or an API that can help to get more information on the generators?

I’m currently using this “Create Password” generator to create a temp password during account creation. Wonder if there’s a way I can send end user an email that contains the temp password information.

Some restrictions:

1. the connector we are using for this integration is not a JDBC connector, not a WebService connector or AD connector
2. After the temp password is set in the target system, there’s no way to get it back from the system
3. Due to the security requirement, we want a fully random strong password, that can not be guessed by anyone.

Any suggestions and ideas are appreciated.

[gourab (Gourab Sadhukhan)]

Hi @ywu11
There are three recommended practices for handling password generation on new account creation:

1. Static Password - A single, uniform password that all users use for their first login
2. Dynamic ’Known’ Password - A static password created from a combination of known user attributes, such as (e.g. <name>-<dept>-<1234>)
3. Dynamic ’Unknown’ Password and Password Reset - Randomly generated unknown password

Find more here:
https://community.sailpoint.com/t5/IdentityNow-Articles/Best-Practices-for-Provisioning-with-Passwords-in-IdentityNow/ta-p/75459

Generators in IDN

Hi all, in IDN create profile of sources we have generators by default we have four generators i.e create Unique LDAP attribute — it takes pattern to generate get manager LDAP DN create Unique Account ID – same takes pattern create password – it does not taking pattern so how this password was created when account is provisioned does it use source’s password policy in that case when user need to login to target source user need to know the password to login to source but IDN does not allow t…

You can use option 1 or 2 to send the password to the user after account is created

[JackSparrow (Theja C)]

“Create password” generator uses the default password policy defined in SailPoint. It can be changed accordingly. You can go to admin–>password mgmt–>default–>edit.

Do you have any email templates defined for new accounts provisioning? If yes password can be added over the same email with other account details and user can reset their password on the first login.

[ywu11 (Yun Wu)]

Thanks for quick reply. So if we want a random strong password, there’s no way to send user the temp password?

The target application, doesn’t support user to initiate reset password without a current/expired working password first.

[gourab (Gourab Sadhukhan)]

Hi @ywu11
Custom solution can be used here.
Once an account is created, you can utilize Account After Create rule(Before and After Operations on Source Account Rule | SailPoint Developer Community) to trigger a PowerShell script. This script can be used to:

Generate a password—>Force set the password in target system directly–>sends email to manager using SMTP
but this approach depends on the target system you are using. For AD it is doable.

[ywu11 (Yun Wu)]

Thanks. Unfortunately, the source is not AD type.

I’m using IBM i connector, which seems not support any connector rules.

[gourab (Gourab Sadhukhan)]

Hi @ywu11
Another theoretical solution could be to use event trigger . I saw “source account created” trigger is now available Source Account Created | SailPoint Developer Community
We can use this event trigger to trigger custom script residing on server.

Note: This approach needs to be tested

[ywu11 (Yun Wu)]

Thanks. But at that time, how can I retrieve the temp password used to setup the account?

[ywu11 (Yun Wu)]

I do see we have the following custom email template:

Email Template: New Account Provisioned

However, it seems not triggered automatically when the account is created.
What settings do I need to make sure this email is triggered when new account is provisioned?

[ywu11 (Yun Wu)]

Figured out the way to trigger the email notification.

However, the temp password was not replaced in the email.

[JackSparrow (Theja C)]

Do you have the password variable defined over the body?

Note: Printing password over email is not a recommended way.

[gourab (Gourab Sadhukhan)]

you can’t print password in email. incase static password as it already known you can hardcode it or for dynamically known you can show by combining id attributes

[VijayMaripi]

HI @ywu11 ,

We have similar requirement to send the password over an email and also the requirement is to send password only from IDN not even through after create rule/powershell script which can be triggered on IQ server.

And yes we cannot access password in workflow which is generated during create operation also printing password over an email is not a recommended approach.

But still we need to satisfy the requirement. So we have proposed following approach with dynamic random string + user known String:

• We had to create an identity attribute and mapped to random alpha numeric transform which only be generated during his joining date and once the ad account is created, this attribute will be turned to null after some time
• In create profile of source, we are passing dynamic random string + known string (Example employeeid 2 chars + joining year last two digits)
• And we are triggering a workflow, once AD account is created and sending this dynamic random string by accessing identity attribute to his manager email.

Note: This random string is still visible in audit logs like access history, Identity attribute change events but not on identity attribute. Also we are making sure not to change this random string for every refresh with in the transform during the time of ad account creation and triggering email to manager via workflow.

And this password can only be used by user to reset the password for first time login.

May be you can see this solution not specific to AD but if you want to implement for IBM i connector, it should work, but make sure that this is not a recommended approach.

I hope this helps.

Thanks,
Vijay Maripi

[ywu11 (Yun Wu)]

Thanks for providing the thoughts, making it visible in audit logs won’t be accepted here.

We’re shipping audit logs to splunk, and it will also be wide open to the organization users.

But I do appreciate the ideas and the detailed explanation of the design and reasoning.

[ywu11 (Yun Wu)]

Currently my thinking is in the BeforeProvisioning Rule (cloud executed rule), looks like that might be the only place I can have code to access the temp password.

However, since it is before provisioning, I don’t know whether the account is successfully provisioned or not.

So I’m thinking this solution:

send out an email to user with temp password from that BeforeProvisioning Rule, but state words like “If your account is created successfully, your temp password is ********”

And after the account is created successfully, send a different email (triggered not from that cloud rule), saying “Your account is created successfully, and please use the temp password you received from previous email”.

And if account is not created successfully, send another email to ask user to ignore the previous email that contains the potential temp password.

[VijayMaripi]

Hi Yun Wu,

I don’t think we can access password in before provisioning rule as well. Last time when i tried, I was not able to retrieve the secret even from the plan.

But feel free to try it again.

[ywu11 (Yun Wu)]

You’re 100% correct.

The outbound call from the cloud rule is blocked, and their pipeline blocked my rule from deploy.

I think we need to use the

Option 2 - Dynamic ’Known’ Password from their published best practices

Thank you all for the discussion, it’s a good learning.