I am having a requirement to generate random password for AD account provisioning with some criteria -
Minimum of 12 Characters
Must contain uppercase & lowercase letters
Must contain Numbers
Must not contain consecutive Numbers
Must contain Symbols
Must NOT use previously used password for the last 24 months.
I have created a Before Provisioning Rule for that and tested the JAVA version of it, which works fine. I have to apply it on password attribute (maybe as Generator, I am not sure on that) in Create Account of AD. Should I do it via Rule Transform or at Source level or any other approach is there after ES deploys it?
Also if I have to send this generated password to user’s manager via email notification on AD account creation, what would be the criteria and how is it possible?
PS- We don’t have any password management module.
You can’t set a password using a generator while still having the ability to email it. You’ll need to create an afterProvisioning rule for AD, and in that rule you’ll need to generate a password that meets your criteria, set it on the account, and then send an email to the manager.
Hey @sup3rmark - do we have after provisioning rule in ISC? Also, I am thinking of using Attribute Generator Rule now as it is required in Create Account. BP rule will not be a good practice here, i guess.
I believe Mark is referring to the After Operation Rule (After Creation Rule) which is a PowerShell Scripts used to perform specific operations like the one in your context. Because a random password generation + sending it using email isn’t possible through the provisioning policy Create (Create Account).
If you don’t want to use PowerShell, you can use the semi-dynamic password, like password that have a static part + contain identity attributes that you can load post AD creation using workflows to regenerate the password and email it to the manager, something like : SailPoint_21<DAY+MONTH_START_DATE>#A95<HR_IDENTIFICATION_NUMBER>!SpW.
Hi @WhiteBat Thanks. Can we use something like using Attribute Generator Rule to generate random password and then using some identity attribute lets say tempPassword to store it? Then for Notification via Workflow, reference the tempPassword to be sent to manager?
You can technically do that, and it will work, but that’s not a recommended approach as any admin can see the generated password and from a security perspective that’s not so pretty. Security audits will be brutal
Hey @WhiteBat - only admins will have the capability to see it right? I just want to make sure, once it it sent to manager, immediately using some Rule if i can delete it. Is there a way to limit the access for others to see it?
You might need to check the user level matrix, but anyone who has access to search and to the identity list can indeed see it (typically non-end-user identities).
You can do some conditions to check if the identity has an AD account and then clear it, but the identity history would remain for few months.
Attribute Generator Rule on an Identity Attribute does not guarentee same value if user is refreshed 2-3 times.
An important consideration with IdentityAttribute rules is whether generation logic that includes uniqueness checks is acceptable. While not explicitly disallowed, this type of logic is firmly against SailPoint’s best practices. When calculating and promoting identity attributes via a transform or a rule, the logic contained within the attribute is always re-run and new values might end up being generated where such behavior is not desired. Additionally, the attribute calculation process is multi-threaded, so the uniqueness logic contained on a single attribute is not always guaranteed to be accurate. For this reason, SailPoint strongly discourages the use of logic that conducts uniqueness checks within an IdentityAttribute rule. The recommendation is to execute this check during account generation for the target system where the value is needed.
I would recommend using an AfterCreate Powershell rule. We did the same and it is working fine without any issues.
Hi @RAKGDS , thanks for the insights. So, for my scenerio, do I have to create a powershell script for random password generation and attach it to After Create rule? Also for email notification, you suggesting same?
Hi @RAKGDS Thanks. I have created the powershell script and using AfterCreate Rule to trigger it. I have also attached the Rule to AD source, but when AD account is getting created in joiner scenerio, I am not seeing any log in IQService folder which I have created from ps script. I believe the script is not getting triggered. Can you help on this?
In certain scenarios dll files may be restricted or blocked due to restrictions on client side. You can try following:
Check if all the dll files in IQService Folder are blocked?
Someone AD account replication takes a little time. So Add a wait of about 30 seconds in your powershell script and then first try to get the user if the user exists or not then change the password.
Try to create a user from ISC and then run the powershell commands manually as an admin to make sure all the commands are working fine
Additionally its not a good idea to send the password from ISC because then mails are being sent via ISC’s mail server and all the mail data is available there. So it is better you set the password through Powershell and then send the password as well using your powershell script.
Additional you can enable the trace level logs and share the logs with us that will help us able to identity the issue and guide you better
Hi @pradeep1602 Thanks. I manually mocked the functions introduced in PS script in my local all worked fine such as Generate Random Password, Create SNOW ticket from ps script if there is a failure in password generation. The issue I think is the script is not getting triggered, I introduced logs at start of script as well that will create an evidence file immediately when script gets triggered, it is also not getting generated along with logFile.
I have pasted the Rule above and attached it to AD source as well.
May be try putting all the commands in the native rule itself. I feel you might be missing some import statements or something is wrong with your code in native rule.
@pradeep1602 - I have tested this script in my local with mocked functions it is working, my main concern is even i have introduced this before importing anything so atleast if the script is getting triggered it should generate this file - # TRIGGER TEST - Create evidence file immediately to confirm script execution