We are testing our termination process in a lower environment. Currently, the system has 2 AD Environments and a JDBC Connector configured. The 2 AD Environments are existing, and we are testing the JDBC Connector.
For testing, we terminated the user in the HR system, and the termination was aggregated in correctly. The disable process in the Lifecycle state change kicked off and called the disable for both ADs and the JDBC. Both Disable AD events succeeded, but the Disable JDBC failed. When looking at the error for this, the error message was from AD stating error with AC_NEW_PARENT and that the Disable OU did not exist (This was a legitimate error.) What is odd is that this error message is showing up under the wrong Connector Event. When looking at the event, the Disable JDBC did not occur on the downstream system.
Has anyone else seen something similar occur? This seems like it could be a big issue if the errors are not reporting with the correct events. This is in a Sandbox environment, so not sure if this would occur in Production or now.
We faced a similar situation where I refreshed a user manually to have a role assigned and grant database access. It resulted in a failure related to an AD account creation failure as some of the mandatory attributers are missed for the user in sandbox. However, the part which I was suprised as well is failure showed up in the database request placed.
Hence, my observation is, when there is an event occurred such as leaver, process identity or any other which causes a refresh of identity, the failure occurred as part of the refresh task is registered for the entire identity though sometimes not directly relevant to the specific application provision.
Thanks for confirming that you are also seeing this issue happening as well.
However, I don’t believe that what you describe is the correct behavior. THe AC_NEW_PARENT should be processed in the AD Request, or in a Before or After Provisioning rule, all which should execute as part of the AD Event. It should NEVER show up under the JDBC Event, since they do not overlap.
In my case, it is causing the AD Event to succeed (Which it should not if the AC_NEW_PARENT fails) and the JDBC Event is Failing, even though in my case it sets a single attribute using a stored procedure that has been tested working many times.