We have a scenario that I’m having trouble figuring out an answer for.
Problem – We need a ‘Ticket Number’ from an external/disconnected system to be added to the AD ‘Description’ property upon AD Account Provisioning (via Role).
Scenario – Requester requests a role (to provision an AD Account) and the requester needs to supply a ‘Ticket Number’ in the request. The ticket number will need to be added to the newly provisioned AD Account ‘Description’ Property.
I don’t see a clear way to make this happen.
I’ve tried with workflows, interactive forms, modifying the Provisioning Plan from workflow, ‘tempTicket’ Identity Attributes and several other things. Seems like their SHOULD be a way to do this – it just isn’t coming to me.
Are there more ‘advanced’ Workflow actions (Modify Provisioning Plan, Update Identity) that can be enabled/used?
Please, any suggestions would truly be appreciated!
Otherwise, if you are able to pull the ticket number from the external source via SailPoint source connector (Direct or generic or flat file) before the role request then you can map that account attribute to an identity attribute value and refer it in AD description during Account Creation operation.
Thanks for the reply! I tried the Interactive Form/Workflow method - it is just when I get to the point where I need to pass ticketNumber into “something” to get it to AD is stopping me.
Since I can’t update an Identity Attribute via API in my workflow, I can’t use the Identity Attribute method. I was surprised that from the Workflow their was no option to Update Identity or Modify Provisioning Plan.
I’m new to ISC, just switched from IIQ.
Yes, correct. Help Desk get a ticket for an AD Account in Domain X - The Identity already exists and has access/accounts in the MAIN corporate AD Domain, just needs access to another of the Domains.
Help Desk goes into ISC to assign the Role to the existing Identity (so the account gets provisioned) - and hopefully the ticket number gets added to the newly provisioned AD Account Description Property.
I’m gonna use forms and workflows in this circumstance but any external form/workflow system (such as servicenow) can handle this as well.
Create A delimited file source. For this example, we’ll call it “Other domain staging”.
For account ID/name, use an identity attribute like uid (or rather, populate accounts with that Id). Have a second attribute that is the ticket number. Do your tickets have a prefix? For example, servicenow incidents always start with INC, requests start with REQ, etc. if you have that, you don’t need this third field.
If you don’t and you want your AD role assigned automatically instead of requested, create a third attribute called something like “submitted” that’s always going to have a value of “true”.
Since you already have an role, you can either -
Modify the assignment criteria that either says their account in other domain staging has the attribute ticket number that starts with INC (or whatever your prefix is) or has the submitted value of true.
Or
Have your form workflow submit an access request for that role
In order to get that ticket number, you’re either going to need to populate it as an identity attribute pulled from this delimited file source or use a before provisioning rule to go fetch it.
The workflow on the form creates this delimited account with the identity uid, the ticket number, annd optionally the “submitted” attribute. If you aren’t assigning the role automatically, the workflow then requests the role
Is it pretty? No. Welcome to the world of ISC workarounds!
ETA: a downside of the automated role assignment is you have to make sure you delete that “other domain staging” account if you want that role deprovisioned or if the identity is terminated. Requesting it might be the better move
Wow, incredible answer. Going to have to digest/think about this one. We ‘were’ trying to simplify things for Help Desk folks to simply go request a role or fill out a form.
Seriously, just a month into moving from IIQ to ISC - everything is a workaround or a ‘Sorry, not possible’ now.
We may end up going the super simple route - ‘No - you don’t get the ticket in the Description Property anymore!’
