I’m looking to see if there is a method (as a cloud rule, or maybe a workflow) to see if I can inject an attribute update when a password change happens on an specific account/identity in our tenant. I’ve written rules in the past, for example, where I set a before-provisioning rule to perform an account attribute update during enable and disable operations of accounts. Has anyone done something similar but with the password change of a user? If the before-provisioning rule is not the right approach here, happy to investigate other options, but I seems to be relevant with my use-case.
Also, I reviewed the class libraries ( Generated Documentation (Untitled) ) from the appropriate SailPoint documentation and wasn’t able to find anything that meets my needs. Maybe I missed something, but this is where I’m now stuck.
Any suggestions or directions are appreciated.
Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.
Please consider addressing the following when creating your topic:
What have you tried?
What errors did you face (share screenshots)?
Share the details of your efforts (code / search query, workflow json etc.)?
What is the result you are getting and what were you expecting?
Have you considered using the Native Change Detection feature? You can use this on pwdLastSet to get an audit event, and use the detection to perform various features (like update an identity attribute which syncs to other systems)
Thanks Margo. This sounds like this could be useful, but unfortunately, won’t fit my use-case. This is not an Active Directory, but another flavor of LDAP and does not have the pwdLastSet attribute. Additionally, the attribute I want to set is a date timestamp for when the password change occurs, so there won’t be any attribute on the directory that I can use to trigger via the native change detection, assuming the password itself cannot be used by the native change detection either.
We don’t have a password policy enabled on the directory server instance, so that attribute is not being populated today. We are not sure if we can implement that functionality without impacting our existing password process but I guess if that’s our only path, I can certainly investigate down that path. I was hoping to investigate this as a programmatic change since it sounds like it could be the path of least resistance at this point. Thanks.
That would be tech debt as you would be implementing some additional / custom flow given that your current SDS implementation doesn’t have any data point nor exposed hook for ISC to catch onto. At the very least, you would need the change to be ‘realised’ and stored on the initiating system.
The other (longer) path is SIEM channel. Any password changes would be logged / audited natively on SDS, which would then be sent to a SIEM solution (in near real-time) if your environment has that. You could have the SIEM solution to call ISC. But you’ll need to build that out to be resilient. …which also points back to the first point above (custom flow…potential debt).
Ideally, you want the most natively supported approach, shortest path (less things to break), with no / low coding. Each system should be able to tell / tell you when a password was last changed (LDAP or otherwise)…without external system integration. This should be one of security baseline function.
Thank you for the comparing and contrasting some possible options. It sounds like the best approach would be to look at enabling the pwd policy in SDS and as long as that doesn’t have any negative downstream impacts, we will look to go that route then.
Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.