Scenario
We have a set of 2 AD entitlements that need to be requestable in ISC. One is “Basic Users” and the other is “Licensed Users”. The problem is that a user cannot hold both entitlements or else it causes issues in our system.
Needed Solution
We would like SailPoint to automatically deprovision the old entitlement if the new one is approved so that the user does not hold both. So, if a user has basic and is given licensed, the basic should be removed and licensed added and vice versa.
Thoughts
SoD Policy
No workflow trigger based off of SoD policy
Workflow?
How to trigger?
If anyone has experienced a similar problem and found a solution I would love some help. Thankyou!
I would caution against using the beforeProvisioningRule for this solution. The RemoveADEntitlements action does not remove specific AD groups. It removes all AD groups, and sets only the ‘value’ group as the only group on the AD user object. This can cause unintended consequences of removing all access, not just specific access.
I think Workflows might better help get you what you are looking for. Here is a rough outline of how it could work:
Trigger - Access Request Decision. Filtered on the “Licensed Users” entitlement being approved.
Action - Get Access or HTTP Request search for user and see if they have the “Basic Users” entitlement.
Action - HTTP Request to submit an access revocation request for the “Basic Users” entitlement if they have it
In plaintext, when the access request for the “Licensed Users” group is approved, check to see if the user has the “Basic Users” group and submit an access revocation for the “Basic Users” group.
This alleviates any sticky entitlement issue as the access revocation submission will remove it from both IDN and the source system.
Using before provisioning rule. If the user has requested for Licensed Users group. You can use a sample logic to get the users existing groups by using idn.getAccountByDisplayName. Then you can check if the user has Base Users group and add that group to be removed in the same request.
Account account = idn.getAccountByDisplayName(adAppName, sAMAccountName);
log.debug("AD account: " + account);
if(account != null) {
existingGroups =
Util.filterNulls(Util.asList(idn.getRawAccountAttribute(account, "memberOf")));
} else {
log.debug("Identity does not have AD account");
}
Use ConnectorAfterModify connector rule to identify if the request has a Licensed Users group and trigger an external script to remove base users group.
In this option, since the entitlement would be removed in the BeforeProvisioning Rule, would both entitlements remain on the SailPoint Identity? I am concerned that the entitlement would be removed on the target source, but since entitlements are “Sticky” it would be reprovisioned later.
The hope would be some sort of birthright assignment. For this specific entitlement set, I think it could be achieved with LCS or automated role assignment. If there is another way it can be done that would allow this functionality, I would certainly be open to it.
We also may run into a similar situation where each of the options are requestable (with no birthright access to either), but a user can only have 1.
If you can have “Basic Users” in a role with assignment logic of Entitlement from AD not equals to “Licensed Users”, then that should address the assignment and revocation of “Basic Users”. But the timing is the issue here…you need to trigger process identity “after” Licensed User is provisioned (From a workflow with Provisioning completed trigger). This momentary overlap is not ideal.
In this scenario you would assign the requested entitlement and remove the other one. Your logic has to be correct. If you are assigning the entitlement using APs then it will not assign. If you have assigned the entitlement using Role then yes it will assign the entitlement back.
If you have ServiceNow…
Set a spare field on the sys_user table to ‘Basic’ as default.
Uplift/downgrade to/from ‘Licenced’ user is done through a SNow form.
Create two roles in Sailpoint based upon this attribute and assign the entitlements accordingly
Or, use the afterModify rule. Pick an unused attribute on AD to specify basic/licenced user.
Create an Identity attribute that uses a static transform based upon the requested entitlement
PS script on the IQ server then adds/removes the entitlement accordingly
Or, Create an Identity attribute that uses a static transform based upon the requested entitlement
Create two roles in Sailpoint based upon this identity attribute and assign the entitlements accordingly
@seth_hexum
Just one thought you can try this use case with creating one identity attribute say e.g. “Access”. Its value you can populate on the basis of some condition like job code or cost center as ‘basic’ or ‘licensed’. Or default you can update value as ‘basic’ on identity creation. On the basis of role assignment criteria you can provision/deprovision respective AD groups or you can trigger workflow on the value of this identity attribute to assign and remove AD group. I hope this way we can automate this use case.
