Hi everyone,
I am facing an issue with RACF provisioning through SailPoint.
During Disable operation, SailPoint is attempting to remove the user’s default RACF group. However, RACF does not allow removing the default group unless another default group is assigned first, causing the provisioning operation to fail.
Error received:
ICH03014I $$TPUSER IS DEFAULT GROUP, identityLogin NOT REMOVED.
RC(4)
USA-API operation failed (rc = FATAL)
Full log snippet:
PreScript Message:
ActualMsg:
2026/05/07 20:01:56 CTS1411I R Delete User identityLogin from group $$TPUSER in Connector MVCGTCR by USER () SIID 432951595:
2026/05/07 20:01:56 CTS3016I R >>> "CTSAEXC REMOVE identityLogin GROUP($$TPUSER)"
2026/05/07 20:01:56 CTS3016I R ICH03014I $$TPUSER IS DEFAULT GROUP, identityLogin NOT REMOVED.
2026/05/07 20:01:56 CTS3016I R +++ RC(4) +++
2026/05/07 20:01:56 CTS1434I R USA-API operation failed (rc = FATAL)
PostScript Message:
What I need is a way to remove this Remove Group operation from the ProvisioningPlan before execution, specifically when the group being removed is the RACF default group.
Has anyone implemented logic to prevent this type of removal?
What would be the recommended approach for handling this scenario?
Thanks in advance.
Hi @lucassilvaasper - you will want to use a BeforeProvisioning Rule to accomplish this. The logic would be looking at the account request, checking the operation for disable and if there is an attribute request within it to remove the default group, then remove it from the plan. This would be a beanshell rule that would need to be submitted to SP for review and deployment.
Rough example:
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Rule PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Rule name="Example Before provisioning rule" type="BeforeProvisioning">
<Description>Add or remove items from plan</Description>
<Source><![CDATA[
import sailpoint.object.*;
import sailpoint.object.ProvisioningPlan.AccountRequest;
import sailpoint.object.ProvisioningPlan.AttributeRequest;
import sailpoint.object.ProvisioningPlan;
import java.util.Iterator;
for (AccountRequest accountRequest : plan.getAccountRequests()) {
if (accountRequest.getOp().equals(ProvisioningPlan.ObjectOperation.Disable)) {
// Remove any attribute requests that would remove the default group
Iterator attrIterator = accountRequest.getAttributeRequests().iterator();
while (attrIterator.hasNext()) {
AttributeRequest attrRequest = attrIterator.next();
// Check if this is removing the default group
if (attrRequest.getOp().equals(ProvisioningPlan.Operation.Remove) &&
attrRequest.getName().equals("whatever default group is")) {
attrIterator.remove();
}
}
}
}
]]></Source>
</Rule>
Try service standard before provisioning rule instead to avoid writing your own code and managing it
Which method in service standard before provisioning rule can i use?
Hi @lucassilvaasper
I don’t remember on the top of my head and don’t have access to rule currently. but there is a method if you read the documentation in the standard rule you will be able to idenfity it.
Probably you can share it here and I can help
Regards,
Pradeep
@lucassilvaasper there is another option like @pradeep1602 mentioned. You can have SP deploy a “One size fits most” rule that is managed with a JSON config file on your tenant. ISC Sample BeforeProvisioning Rule
Original pdf - https://global.discourse-cdn.com/sailpoint/original/2X/8/8939f8dddee417ecf55262549102a40748115e1a.pdf
@lucassilvaasper
I just checked, I think you might have to write your own rule only.
Sorry for the confusion
Yes, we have ISC Sample deployed.
My question is which method i can use to remove an attribute request of the plan. I dont know if there’s one for that.
There is not one, so for this use case you would need to go with your own rule. The example I posted should be pretty close to what you need with a few tweaks. Caveat is you will be responsible for maintaining it and any updates will have to be submitted for review and deployment.
Hello @lucassilvaasper , You can use it on Modify and Disable Operations
import sailpoint.object.*;
import sailpoint.object.ProvisioningPlan.AccountRequest;
import sailpoint.object.ProvisioningPlan.AttributeRequest;
import sailpoint.object.ProvisioningPlan;
import java.util.Iterator;
import java.util.List;
for (AccountRequest accountRequest : plan.getAccountRequests()) {
ProvisioningPlan.ObjectOperation op = accountRequest.getOp();
boolean isDisableOrModify =
ProvisioningPlan.ObjectOperation.Disable.equals(op) ||
ProvisioningPlan.ObjectOperation.Modify.equals(op);
if (isDisableOrModify) {
List attrRequests = accountRequest.getAttributeRequests();
if (attrRequests != null) {
Iterator attrIterator = attrRequests.iterator();
while (attrIterator.hasNext()) {
AttributeRequest attrRequest = (AttributeRequest) attrIterator.next();
if (ProvisioningPlan.Operation.Remove.equals(attrRequest.getOp()) &&
"defaultGroup".equals(attrRequest.getName())) {
attrIterator.remove();
}
}
}
}
}
Thanks,
@SivaLankapalli
I think an idea should also be submitted for this.
Similar to how domain users group can’t be removed for AD as well