We are having an issue where sailpoint is recently adding old groups back to accounts and even re-enabled some old, disabled accounts. This happens routinely, so it clearly is something that is scheduled to run. Could someone help me try and find where the issue is coming from? I am unsure where the logging is. I have an account to use for analysis, but am unable to find audit logs of how a certain group was added, and why.
Which IIQ version are you inquiring about?
8.1p3 Unsure.
Share all details about your problem, including any error messages you may have received.
We noticed this issue recently and are unsure what is causing it. Our normal Sailpoint admin recently left, so we have little experience.
I did notice that our AD group aggregation task recently had a Pruning cyclical group hierarchy warning.
If possible, pause all tasks and run an IIQ refresh on a single identity cube to determine if it’s the source of the issue. Often, the refresh task is the primary culprit. Enabling logging can provide visibility into which specific operation might be causing the issue. In environments with multiple concurrent operations, it can be challenging to isolate the root cause, especially since the order of operations in these tasks can affect how the identity cube is reflected.
To enable logging, refer to the SailPoint IdentityIQ documentation, which outlines the steps for configuring detailed logs. This will help you track task executions and pinpoint the operation causing the issue.
Check the AD logs to verify that IIQ is the one enabling the user.
Review the identity cube to see if the user has a role that enables a user. Roles assigned to users may revert any changes made directly in AD.
Review the scheduled tasks looking for custom tasks running any rules. If they are any rule-based tasks, search for the actions you mentioned in the code.
Review your task results to see what completed around the time of the last modified date of the affected user.
@erbrown
First thing, there is nothing to do with below
I did notice that our AD group aggregation task recently had a Pruning cyclical group hierarchy warning.
Now coming to your issue, below are important things you have to check, For the instances where this is happening the check the provisioning transaction of the user and see what is the source of provisioning transaction
If you are storing the transaction data in your system, you should be able to see the complete plan , source and what is causing this
Im almost positive i narrowed it down to one specific application as i can see the permissions that get re-added everytime being listed on the identities application account on it.
Check to see what assigned roles that user has and if any of them contain an entitlement related to group in AD. If so, every time you do an Identity Refresh in IIQ that would provision the user back into the group.
The purpose of the assigned roles is to ensure that nobody does a rogue modification directly in the target source. This is related to the second bullet I mentioned earlier.
Here’s one example. This entitlement has been re-added by sailpoint multiple times during this issue. I checked the users roles and this entitlement is not associated with any of them. Yet, it keeps getting added during aggregation.
In your codebase, do you have any references to “ServiceDesk_VPN”? I’m wondering if your developer created some kind of customization rule for a given type of user to add them to this group.
Another thing to check is AssignementAttributes on the affected identity. This will add groups back to an account and even recreate the account if necessary.
**[quote=“Eric Brown, post:1, topic:87430, full:true, username:erbrown”]
We are having an issue where sailpoint is recently adding old groups back to accounts and even re-enabled some old, disabled accounts. This happens routinely, so it clearly is something that is scheduled to run. Could someone help me try and find where the issue is coming from? I am unsure where the logging is. I have an account to use for analysis, but am unable to find audit logs of how a certain group was added, and why.
Which IIQ version are you inquiring about?
8.1p3 Unsure.
Share all details about your problem, including any error messages you may have received.
We noticed this issue recently and are unsure what is causing it. Our normal Sailpoint admin recently left, so we have little experience.
I did notice that our AD group aggregation task recently had a Pruning cyclical group hierarchy warning.
[/quote]
Does anyone know where sailpoint IIQ will store logs on a linux or windows machine by default
**
The point of my statement was that you should place your log files outside of the installation folder, so that if you do future app server upgrades then you won’t have to worry about losing historical logs. For Linux users, I recommend deleting the log folder and creating a symlink to another location.
Please let us know if you find some useful information once you go through your logs.
So I was able to find that were using MSSQL and its pointing to a windows server in our environment. And the Windows server does not have the directory that is listed here. It also seems commented out.
