Trigger Error in BeforeCreate Connector Rule

Hi everyone. Using an IDN Connector Rules (On Prem Active Directory), I’m attempting to fail a provisioning request at the “Before Create” stage so an account is never created but is tried again later.

I’m able to do this somewhat successfully by modifying the RequestObject XML and clearing out all the values. This works and keeps the account from being created, but IDN still shows a “success” in the GUI and takes awhile to get its bearings and eventually try again. (Have to reaggregate, etc.)

Because the ResultObject is not writeable in the BeforeCreate context, is there some way for me to kill this request at this early stage?

When I write errors to the ResultObject in my AfterModify the errors show up as red flags in the UI. However, if I write these types of errors in my AfterCreate script (trying to tell IDN that the account create failed) it’s doesn’t clue the UI in and it still thinks everything went great.

As evidence it seems somewhat happy, I noticed in Workflows my “AfterCreate” ‘major error’ is just considered a warning.

"warnings": [
            "Create operation is successful but post script execution failed : Major test error encountered!"
        ]

Any ideas? Thanks!

Hi @mdewallnc,

Just to get the background of the use-case why you want to fail the request once provisioning is started, why not simply block the request for let’s say some specific user if that is your use-case.

Let me know your thoughts.

Thanks

Hi @ashutosh08,

Sure! Right now my primary use case is an IT admin moving a user’s account in AD. Because IDN still doesn’t take kindly to user accounts moving, it may try to provision a second account until such time that I can run a full unoptimized aggregation.

To get ahead of that use case (we aren’t in a place where I can simply ban admins from moving accounts just yet) I want to do a pre-emptive directory search (in my BeforeCreate rule) to ensure that a duplicate account isn’t being provisioned (by searching for employeeId in the directory first). If I detect this is a duplicate account, I want to fail the request and then trigger an unoptimized aggregation on the AD source.

While I’ll be using the sanctioned approach of a “before provisioning” rule to place the person in the right spot on creation or state changes, this is purely to address unsanctioned moves until such time I can restrict access and enforce policy in our environment. Even then, mistakes happen.

Matt

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.