Identify users in SailPoint IIQ whose Active Directory group memberships were assigned externally, bypassing the IIQ provisioning process

IdentityIQ (IIQ) IIQ Discussion and Questions
,
1

Hi All,

We have enabled the provisioning of certain Active Directory groups to users through SailPoint IIQ. However, we have observed that some users are being added to Active Directory groups outside the SailPoint provisioning process. Could we identify these users whose Active Directory group memberships were assigned externally to SailPoint during the account aggregation process?

Thanks,
Hemant

2

Hi @nailwalnavistar ,

You can enable the Native Change Detection option in the Active Directory application to identify users whose Active Directory group was added outside of SailPoint.

image
image871×313 8.92 KB

For more details refer the link

3

@nailwalnavistar
Is Native change detection enabled at application level?

4

You can also look at the IdentityEntitlement table and get more information around the state and source of that entitlement assignment to the account. I’m thinking there is an attribute called ‘isAssigned’ or similar that might help figure out which of these went through SailPoint vs. native change

5

Not yet, we are exploring the possible solutions to identity group membership assignment external to SailPoint. We will explore native change detection option.

6

We are looking for an automated process for identification so that we can remove users from Active Directory groups.

7

@nailwalnavistar
If you don’t have NCD it is tough to identify. we cannot rely on the source column of spt_identity_entitlement table

Couple of approaches you have is if at all you are looking for a recent groups added in AD and you are retaining provisioning transactions in Sailpoint you can check against those transactions if group is provisioned via Sailpoint

But once you enable native change detection, this should be simple to identify the rogue memberships added outside SailPoint.

8

Hi @nailwalnavistar

For these kinds of situations, it is preferable to enable native change detection at the application level.

OOTB gives you many options for managing native changes.

For instance, When a native change is implemented, SailPoint can be configured to request approval (for example manager), and depending on the decision, it can either keep the users in the group or remove them from the assigned groups.

9

Thank you for your response. we have reviewed our use case it can be achieved through Native Change Detection.