Share all details related to your problem, including any error messages you may have received.
Hello,
We recently saw a strange behavior in our PROD environment. We had manager correlation configured in our authorative source application. We noticed that for some reason that configuration was wiped from the application, due to which manager were not setup on the newly created identities. We have not done any changes on the application.
Has anyone ever experienced such issue or has any idea why it might have been removed automatically?
I would say its highly unprobable that IIQ would remove it just itself.
Usualy this kind of situations happens more or less by intention. Sometimes it may happen that someone accidentaly saves application either in gui or debug and some changes are done.
If you have audit enabled I would check if there is no update event if disabled - I would enable it in a first place.
It is also possible that someone would modify application from Beanshell but it would be definitely intentional.
On a previously functioning installation of IdentityIQ, application configuration settings are suddenly missing. The schema and some identity attributes may be unaffected. Some IdentityIQ users may be unable to log in if the affected application is used to provision their accounts.
Diagnosis
There are three common causes of loss of configuration data:
Using multiple tabs or browser windows when editing applications in IdentityIQ.
Running out of file handles on the OS.
Instantiating a static context somewhere in user-written code.
Ensuring that none of these apply is likely to eliminate most cases of configuration data loss.
Solution
Each potential cause will have different potential solutions:
Multiple tabs
Ensure all users with the ability to edit IdentityIQ applications use only a single tab, window, or browser when making changes. This is stated at various points the IdentityIQ Administration Guide, however it can’t be enforced through IdentityIQ and is difficult to diagnose after the fact.
Running out of file handles
This is uncommon outside of some Linux distributions. Refer to your OS documentation for instructions on determining the current file handle/file descriptor limits. If this number seems low enough that you are plausibly exceeding it, refer to the OS documentation for steps to increase this limit.
Static Context
This is the most common cause, however it can be difficult to locate the problem. If any custom code instantiates a static context, this may be the cause of the symptoms. To determine this, you will need to manually review any user-written code. Searching for lines such as “private static SailPointContext context = null” may locate some examples.
If you are unable to determine the cause of this issue using the above advice, proceed with requesting SailPoint support. You will likely be asked to confirm whether you have verified all of the above potential causes by the support engineer handling your case.