Hi Team,
Did anyone fixed the below error in SailPoint ISC.
We are getting below error only in stage while AD disable operation.
["Error(s) reported back from the IQService - Error occurred while setting group membership CN\u003dDomain Users,CN\u003dUsers,DC\u003dSJX2,DC\u003dCOM. Access is denied. Access is denied. . HRESULT:[0x80070005], After script returned non zero exit code : 1 : "]
Even though from error, it seems that its permission issue but actually, it’s due to the fact that you are trying to add Domain User group to the user which technically is not needed. The Domain Users is default primary group and its derived from the primaryGroupIDAttribute not from the member attribute like normal groups. So, try removing that logic and see if that works then.
You can refer to this post. It has a similar use case to yours.
IN my client environment, we are assigning Domain Users to the identities to create their AD accounts with no access. It does not give any issue like Access Denied. So, cehck with your AD team if any permission issue is present or not.
Domain user is not configured as requestable product or assigned to any of the birth right roles. Could it be issue with provision policies?
also In IQ server log says only below groups are getting removed.
<AttributeRequest op="Remove" name="memberOf">
<Value>
<List>
<String>CN=ITS-APP-WORKVIVO-USERS,OU=Security,OU=IDM,OU=Groups,DC=ABC,DC=COM</String>
<String>CN=confluence-users,OU=Security,OU=IDM,OU=Groups,DC=ABC,DC=COM</String>
<String>CN=jira-users,OU=Security,OU=IDM,OU=Groups,DC=ABC,DC=COM</String>
</List>
</Value>
</AttributeRequest>
Hi @bsayya01 Do you have remove all access set on your lifecycle state? If so, there are a number of posts in the forum on the subject. For example, Getting error while removing all AD groups while user offbaording - #5 by Krishna_55
Hello Baji, based on the IQ log you shared, I don’t think this is coming from requestable access or birthright roles.
The plan is removing only these 3 groups:
But the error is pointing to Domain Users, which is not in that AttributeRequest. I think that usually means Domain Users is getting picked up somewhere else in the Stage disable flow, most likely from a Before Provisioning rule, IQService after script, or some custom group cleanup logic.
Domain Users is normally the default primary group in AD. It is controlled through primaryGroupID, not like a normal memberOf group. So it should not be removed like a regular AD group during disable.
I would check the user’s primaryGroupID in AD and also compare the Stage AD source/rules/scripts with Prod. The important clue is this line: After script returned non zero exit code
So my first test would be to temporarily disable/comment the Stage after script and retry. If the disable works, then the script or custom cleanup logic is touching Domain Users. Exclude Domain Users / primary group from the remove-group logic, and the disable should go through.
In my IQ server log I can find this Does it coming from prov rule defined in SailPoint AD connector or some where in the IQ scripts?
[2026-07-03_09-04-59] RequestObject for user sailpoint.Utils.objects.AccountRequest
[2026-07-03_09-04-59] RequestAsString for user <AccountRequest application="Active Directory ABC [source]" op="Disable" nativeIdentity="CN=Agile,OU=Users,OU=Accounts,DC=ABC,DC=COM">
<Attributes>
<Map>
<entry key="uuid" value="{cf81721b-ed75-4404-af26-e021611ff07a}" />
</Map>
</Attributes>
<AttributeRequest op="Add" name="msExchHideFromAddressLists">
<Value>
<Boolean>true</Boolean>
</Value>
</AttributeRequest>
<AttributeRequest op="Set" name="AC_NewParent" value="OU=Inactive Accounts,DC=ABC,DC=COM" />
<AttributeRequest op="Set" name="memberOf">
<Value>
<List>
<String>CN=Domain Users,CN=Users,DC=ABC,DC=COM</String>
</List>
</Value>
</AttributeRequest>
This RequestAsString log tells us that the memberOf Set with Domain Users is already in the request when it reaches IQService. So this is coming from the ISC cloud side, not from the IQService native scripts. I’d check the cloud-side plan generation first. The stronger areas to look at are the AD source provisioning policy for the Disable operation and any Before Provisioning Rule attached to the Stage AD source.
The problem is that op="Set" on memberOf with only Domain Users. That effectively tells AD to replace the user’s current group memberships with just Domain Users. That’s a common leaver cleanup pattern, but Domain Users shouldn’t be handled through memberOf. In AD, Domain Users is the user’s default primary group, managed through primaryGroupID, not through the memberOf attribute. And you don’t actually need to set it. The user is already in Domain Users through primaryGroupID, and it stays even when every other group is removed.
Since this only fails in Stage, I would compare the BP Rule, the provisioning policy for Disable, and the source connector config between Stage and Prod. Whatever is injecting that memberOf Set exists in one but not the other. That diff should point right at it.
The fix I would try is to remove that memberOf Set from the disable plan entirely, or change the cleanup logic to issue individual Remove operations for each non-primary group instead. The msExchHideFromAddressLists and AC_NewParent parts of your plan look fine. It’s just the memberOf Set that needs to go.
I would still keep IQService native before/after scripts as a secondary check, but this log points more strongly to the operation being built before IQService processes it.
Looke like you are using native rule, check whether there is enough permission for the log on user for the IQ service
@bsayya01 try using a different group for birth right provisioning. As domain users is added by birth
HI @bsayya01 As the error says its coming from the script deployed in the windows server. And the group doesn’t have the permisssion to remove from the domain users. Get this checked fromt he AD team itself first and then try it later once the specific group have permissions.
Check: