Random AD Password generation

Hi Everyone,

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.

Thanks.

Hello Saurav!

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.

Hello @sauravkumar,

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).

Here’s the doc : Before and after operations on source account Rule | SailPoint Developer Community

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.

Good luck!

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?

Thanks.

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 :neutral_face:

3 Likes

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?

Thanks.

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.

@WhiteBat Ok, can you tell me whether I should use BP rule or Attribute Generator rule for same.

Thanks

You can’t see it using a before provisioning rule so the only way to go is Attribute Generator.

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?

Thanks.

Yes Saurabh, you deploy the script in the IQService and have it call it using the native rule which is AfterCreate.

Check this for more details. Let me know if you still need any help on the same

1 Like

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?

Rule attached to AD source:

After Create Rule:

{

"description": "Executes PowerShell commands on the IQService component after a source account is created.",

"type": "ConnectorAfterCreate",

"signature": {

    "input": \[\],

    "output": null

},

"sourceCode": {

    "version": "1.0",

    "script": "$logDate = Get-Date -UFormat \\"%Y%m%d\\"\\r\\n$logFile = \\"C:\\\\SailPoint\\\\Scripts\\\\Logs\\\\LogScript\_$logDate.log\\"\\r\\n$command = \\"C:\\\\SailPoint\\\\Scripts\\\\Provisioning_AfterCreate_Password_Manager_Notify.ps1\\"\\r\\n$enableDebug = $true\\r\\n\\r\\n#====================-------Helper functions-------====================\\r\\nfunction LogToFile(\[String\] $info) {\\r\\n    $info | Out-File $logFile -Append\\r\\n}\\r\\n\\r\\n#====================-------Get the request object-------====================\\r\\nTry{\\r\\n    if($enableDebug) {\\r\\n        LogToFile(\\"Entering SailPoint rule\\")\\r\\n    }\\r\\n\\r\\n    Add-type -path utils.dll;\\r\\n $sReader = New-Object System.IO.StringReader(\[System.String\]$env:Request);\\r\\n $xmlReader = \[System.xml.XmlTextReader\](\[sailpoint.utils.xml.XmlUtil\]::getReader($sReader));\\r\\n $requestObject = New-Object Sailpoint.Utils.objects.AccountRequest($xmlReader);\\r\\n    $requestAsString = $env:Request\\r\\n\\r\\n    if($enableDebug) {\\r\\n        LogToFile(\\"Request as XML object is: $requestAsString\\")\\r\\n    }\\r\\n\\r\\n    #Call the client script\\r\\n    $command = -join ($command, \\" -requestString '$requestAsString'\\")\\r\\n    Invoke-Expression $command\\r\\n\\r\\n}Catch{\\r\\n $ErrorMessage = $\_.Exception.Message\\r\\n   $ErrorItem = $\_.Exception.ItemName\\r\\n   LogToFile(\\"Error: Item = $ErrorItem -> Message = $ErrorMessage\\")\\r\\n}\\r\\n\\r\\nif($enableDebug) {\\r\\n    LogToFile(\\"Exiting SailPoint rule\\")\\r\\n}"

},

"attributes": {

    "ObjectOrientedScript": "true",

    "extension": ".ps1",

    "sourceVersion": "1.0",

    "disabled": "false",

    "program": "powershell.exe",

    "timeout": "300"

},

"id": "xxxxxxx",

"name": "AD_Password_After_Create_Rule",

"created": "2025-10-05T18:32:12.473Z",

"modified": "2025-10-15T11:13:06.165Z"

}

I have created below folders and script in IQService Server: C:\SailPoint\Scripts\Provisioning_AfterCreate_Password_Manager_Notify.ps1

C:\SailPoint\Scripts\Logs - folder for logFile

I checked the utils.dll file exist in C:\SailPoint\IQService

Thanks.

Hi Saurav,

In certain scenarios dll files may be restricted or blocked due to restrictions on client side. You can try following:

  1. Check if all the dll files in IQService Folder are blocked?
  2. 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.
  3. 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.

Thanks.

@pradeep1602 - Also I have unblocked the dll files as well.

Thanks.

Hi Sourav

Once you have unblocked all the dlls you need to restart iqservice also.

Additionally can you make sure you have attached your rule to the source correctly as well?

Thanks
Pradeep

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

$triggerTest = “C:\SailPoint\Scripts\script_triggered.txt”

$currentTime = Get-Date -Format “yyyy-MM-dd HH:mm:ss”

“Script triggered at ${currentTime}” | Out-File $triggerTest -Append

#log file information (define early so we can log immediately)

$logDate = Get-Date -UFormat “%Y%m%d”

$logFile = “c:\SailPoint\Scripts\Logs\LogScript_$logDate.log”

$enableDebug = $true # Debug mode enabled for testing

# Early logging before any module imports

“[$currentTime] Script execution started” | Out-File $logFile -Append

#include SailPoint library

try {

Add-Type -Path "c:\\SailPoint\\IQService\\Utils.dll"

$loadTime = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

"\[$loadTime\] Utils.dll loaded successfully" | Out-File $logFile -Append

} catch {

$loadTime = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

"\[$loadTime\] ERROR: Failed to load Utils.dll - $($\_.Exception.Message)" | Out-File $logFile -Append

throw

}