Right now, We are getting an email to one of our SailPoint experienced People, about making a new distribution list. Most of the time, the email contains most of the information needed, but often a reply or 2 are neccesary to get the details. They then manually make the new distribution list, and setup an access profile in IDN.
I would like to optimize this process with the following:
A form in our ServiceNow environment that collects the required information
A PowerShell script that takes command line arguments and creates a Distribution list.
A PowerShell script that creates a new Access profile using the above.
The access profile has the proper Owner, Entitlement, Request Workflow, etc. and is now usable in the request center.
#1 and #2 are sort of outside this discussion.
My question is around the space between #2 and #3.
I am assuming #3 requires that an entitlement exists in the AD source. However, until an entitlement aggregation occurs, I believe IDN is unaware of the entitlement.
I am assuming that #3 fails without IDN knowing about the entitlement.
Does there need to be a new Step 2.5? Refresh AD entitlements?
We do this exact thing currently using ServiceNow.
There are two “non-automated” steps in this process. First, the identity team gets a task to review the request, because people frequently request distros that already exist (with a slightly different name). The second task is for us to run an entitlement aggregation in IdN.
After that task is closed, the ServiceNow workflow runs a search to check for the presence of the entitlement, then creates the access profile.
I will note that we only use PowerShell for the creation of the distro in AD, and I use Outbound REST Messages in ServiceNow to do all the interaction with IdN.
We could technically automate that second task by either triggering an entitlement aggregation using the API or just set a timer to wait an hour, assuming entitlement aggregations happen hourly. The current number of requests doesn’t really have us wanting to automate this just yet.
You may be able to optimize your submission if you kept a history of previously accepted distro’s and then do a search while the user is filling out the form. It might prevent a few duplicate submissions if people use common knowledge names for distribution lists.
Similar to how SN searches KB while you’re filling out an incident…trying to prevent incidents on things easily solved with KB reading.
I am going to start where you are though with the human review.
I do think I might try and do an API triggered AD entitlement aggregation, have the script sleep 10m, and the create the AP.
I have the workflow perform a check before AP creation by doing a search for the entitlement since I’ll need the Id anyway. If the entitlement exists in search, you can definitely create an AP from it