I think there has been an update in the certifications API we are using the change the due date. Try switching the Request URL from /beta to /v3 and let me know if that fixes the problem. I’ll also test this as soon as I can.
Edit: I was able to move past the errors identified by updating the variable to be a time of now+10m, using that for the deadline update action, then also adding in a wait action of 12 minutes before moving onto the revoke campaign action.
Original:
I’ve been trying out different concepts for removing leaver access and particularly liked this one as a potential solution for now. In attempting this though in three runs I’ve only had one successful. The other two have failed during the update campaign deadline action step.
Admittedly, I haven’t had a chance to deep-dive campaigns/certifications yet, let alone the api - is this potentially due the time? Looking at the below, the time it would have used for the deadline was a few minutes in the past. I’m going to try it with adding a few minutes to the time variable.
| 2024-03-28T16:37:55.242474864Z | {displayName:Update Campaign Deadline,input:{authenticationType:OAuth,basicAuthPassword:null,basicAuthUserName:null,csvRequestBody:null,formRequestBody:null,headerAuthName:null,headerAuthValue:null,jsonPatchRequestBody:[{op:replace,path:/deadline,value:2024-03-28T16:35:53.392Z}],jsonRequestBody:null,method:patch,oAuthClientId:,oAuthClientSecret:v,oAuthCredentialLocation:oAuthInHeader,oAuthScope:null,oAuthTokenUrl:https://-sb.api.identitynow.com/oauth/token,requestContentType:json-patch+json,requestHeaders:Content-Type:application/json-patch+json,suppliedInlineExpression:{jsonPatchRequestBody:[{\op:\replace,\path:/deadline,\value:{{$.getCurrentTimestamp.now}}}],url:https://-sb.api.identitynow.com/v3/campaigns/{{$.createLeaverCampaign.id}}},textRequestBody:,url:https://-sb.api.identitynow.com/v3/campaigns/5fefa5f235854abeb5cc96b296ec7bcc,urlParams:null},stepName:updateCampaignDeadline,task:sp:http} |
|---|---|
| 2024-03-28T16:37:55.299944972Z | {attempts:1,displayName:Update Campaign Deadline,stepName:updateCampaignDeadline,task:sp:http} |
| 2024-03-28T16:37:55.663904737Z | {displayName:Update Campaign Deadline,error:request failed,stepName:updateCampaignDeadline,task:sp:http} |
| 2024-03-28T16:37:55.80416089Z | {error:task failed: activity error (type: sp:external:http:v2, scheduledEventID: 29, startedEventID: 30, identity: 5ca125b0-f675-49bf-9f56-bd82e67ec6af): request failed (type: HTTP Response Returned a Client Error, retryable: false): request failed: 400 - 400 Bad Request - {\detailCode:\400.1.1 Illegal update attempt,\trackingId:\df616460256a4d51b01b6a21cf6c52c4,\messages:[{\locale:\und,\localeOrigin:\REQUEST,\text:\Illegal attempt to modify \\campaign\\ field.},{\locale:\en-US,\localeOrigin:\DEFAULT,\text:\Illegal attempt to modify \\campaign\\ field.}],\causes:}} |
3 Likes
I’ve been getting similar feedback from other customers about intermittent failures with the step that sets the due date and/or completes the campaign. They seem to all revolve around timing somehow.
I will post an updated workflow next week with the following changes:
- Changing all used APIs to the /v3 equivalent
- Change the due date calculation & add some waiting time between these steps
- Also create a concise single workflow option which does not require a parent/child design for those that want a simple straight forward solution.
3 Likes
Just curious, have you had a chance to finish the updates you were referring to? Also to echo Ashish Kumar’s question, what would be the best approach to exclude certain applications or sources? Thank you.
I updated the post with a new set of workflow definitions including a simplified option just using an Access Certification option.
2 Likes
@LynchD the challenge with excluding certain applications would be with Roles, as they can span different sources/applications and there isn’t an easy way from the workflow to check this without looping a lot.
I’m interested to understand your use-case. Why exclude certain apps?
Could you not make the to-be-excluded access into a birthright role which would not be revoked by the campaign by design?
I have used the updated workflow (Leaver-Simple-Remove All Access).
I have tried both beta and v3 to update the deadline.
I have also used now+10 mins for deadline.
I have had some luck in the past, however today its not even working once and its fails while updating deadline.
This is very strange as it never once failed in my environment.
Can you try this slightly enhanced version and let me know if you have any luck?
Leaver - Simple - Remove All Access - Extra Wait.json (5.0 KB)
2 Likes
Thank you for the modified workflow. This is working for me. Had 2 successful executions already.
One question: Is there a way to filter access by application (read only app) for Identity certification while creating campaign? Auto revocation is failing for accesses with read only applications.
1 Like
Personally I’m not familiar with a way to filter any access from the identity campaign type, but something to consider if your sources are truly “read only” (AKA no provisioning needed to them at all) is that you could remove those features from the source config, and then SailPoint will instead create Tasks (work items) to the source owner instead of trying to remove something and failing. This is what we did for some of our Active Directory and other sources that we had setup to pull data in, but weren’t ready to provision to.
We personally haven’t experienced any issues with this yet, but it will depend on your use cases.
You can see the feature values and their brief explanations on the API page.
put-source-schema | SailPoint Developer Community
3 Likes
Thanks for the feedback @sagarkc2023! I’ve now updated the workflow attached to the main post with the new one that includes a short wait step.
One filtering access out, what comes to my mind is:
- Instead of using the “Create Certification Campaign” step, we could probably just call the Certification Campaign API directly using a HTTP Request step.
- This would allow us to create an “Access” type campaign with a search filter - targeting only the access you want to remove - and hardcoding a manual selection of one identity (the leaver)
The one issue I see with this is when Roles come in play. What happens if the leaver is a member of Role X which grants a mix of access across different sources/applications (some to be removed and some excluded)?
As of such, I think fixing the reason behind needing to exclude some sources - as @JRDensmore suggested - is your best way forward.
1 Like
“Leaver - Simple - Remove All Access - fix”
I am noticing weird behavior when removing SailPoint provisioned AD Groups from a workflow using certifications.
Workflow is removing all removable accesses, however SailPoint provisioned AD Groups are re-provisioned by the system.
Sticky entitlement is probably not the cause because native identity (distinguishedName) of the user has not changed.
Also, when I trigger the same workflow second time, it removes the re-provisioned groups without any issues (system is not trying to re-provision).
Maybe setup campaign filter to exclude our application Using Campaign Filters - SailPoint Identity Services
I got lucky our access profile for application have a good naming convention so I was able to just include them for targeted certifications
Potentially leverage access model metadata flags, maybe…if naming convention can’t be used. But I guess that would mean you have metadata lifecycle to managed then.
1 Like
@mostafa_helmy Hello, one thing I have noticed is with the Workflow 1 where all access items are removed, one type of access is not being removed, which are roles with a revocation approval required settings. Is there any to bypass this and remove this role also?
Correct, one of the side effects of using the Access Request approach is that it will go through the revocation approval process.
This is why I would recommend using the Access Certification approach to remove access without requiring extra approvals (the workflow completes the campaign).
You could explore having another scheduled workflow to check any pending approval decisions, check the comment on the request to see if it was from the leaver process, then auto-approve that request.
1 Like
Thank you for the quick response, I am trying out the certification route (the Simple Leaver Workflow) and the roles do get revoked and are removed, but the entitlements still remain in the access list in the idenity cube, any idea as to why this is so? It is not revoking all access items, only the roles.
When you say not removed, do you mean they included in the generated campaign and marked as revoked but the connector did not actually remove the access?
Or do you mean they were not even included in the campaign itself?
Hey @mostafa_helmy with this issue I am getting the following error:
Error(s) reported back from the IQService - Error occurred while setting group membership CN=Domain Users,CN=Users,DC=corp,DC=com. The server is unwilling to process the request. The server is unwilling to process the request. 0000055E: SvcErr: DSID-031A124C, problem 5003 (WILL_NOT_PERFORM), data 0 0000055E: SvcErr: DSID-031A124C, problem 5003 (WILL_NOT_PERFORM), data 0 . HRESULT:[0x80072035]
I do have a campain filter excluding this Domain Users group but still getting this error, but despite this I am still getting the above error when the cert campaign sends a revocation request.
The service account you are using with the IQ service either does not have permissions, or there is a policy on the AD side that is restricting this operation.