We’re experiencing an unexpected issue with our Active Directory integration and would appreciate any insights from the community.
Our AD provisioning process has been configured and operating successfully for a long time. The current expected behavior is:
Access requests are submitted and approved within SailPoint.
SailPoint automatically provisions the requested changes to Active Directory.
No manual intervention is required.
Recently, we’ve started observing a different behavior. Instead of the provisioning being executed automatically, SailPoint is generating manual work items with the following message:
Manual Changes requested for User: “…”
As a result, the requested changes are not being provisioned automatically to Active Directory and require manual handling.
What makes this particularly confusing is that:
As far as we are aware, no recent changes were made to the provisioning configuration.
The behavior appears intermittent rather than consistently affecting all requests.
Automatic provisioning had been working correctly before this started occurring.
Since AD is a read/write connector, I wouldn’t expect IIQ to generate manual work items for normal AD provisioning.
I’d compare one successful request with one affected request under Administrator Console → Provisioning and check the application, channel, operation, and transaction details.
The manual item normally means that part of the compiled plan ended up in the unmanaged plan, so I’d also check whether the affected requests share a particular entitlement, account, logical/proxy application, or operation.
I’d verify the AD Application configuration as well as any Plan Initializer/provisioning customization, rather than focusing only on the provisioning policy.
If you can share a sanitized ProvisioningProject/plan from one failed request, that should make it much easier to see why IIQ is routing those specific requests to manual processing.
One additional point to what @amrdodani mentioned: the “Manual Changes requested for User…” title does not identify which application caused the manual action.
Could you open one of the affected work items and check the application and operation shown on each line item? If the original request included multiple applications, possibly through a role, AD may have provisioned successfully while another part of the request was routed for manual handling.
Sharing the sanitized work-item details will help us narrow it down.
Does this happen with all AD group or only with specific groups or fulfillment paths. For example, groups requested directly versus groups granted through a role?
Can you test the same group through both request paths? That would help determine whether the issue is with the group itself or with how the access is being assigned.
@tmamouros I don’t think this is happening repeatedly and also believe is not easily reproducible. I have also seen this behavior in our environment. I don’t exactly recall the pattern or troubleshooting we did.
Let me check if there are anything, that i can share here.
@tmamouros I checked.. in the past we have been told to look into our custom modules, that if nativeidentity or account resolution is working properly or not.. otherwise it may go to unmanaged plans. If you already have one, can you please share few things:
I am also facing this issue manual work items are getting created in my environment (IIQ 8.5p2) when an AD account is created because of role assignment.
I went ahead and completed the work item. The create account operation failed. I attached the provisioning transaction. I observed native identity for AD set as SamaccountName instead of dn.
The AD account creation failed initially because it used an invalid username format (“Vamsee” instead of a full Distinguished Name).
IdentityIQ improperly retained the assigned permissions on the user’s profile despite the account never being created.
A scheduled identity refresh task detected these lingering permissions and automatically attempted to recreate the missing AD account.
Because the account creation policy requires manual review, the background task could not process it silently and instead generated a work ticket for an admin (spadmin) to complete.
You might want to see why it failed at the first please where the native identity was wrongly generated.
I agree with Neil that the nativeIdentity could be the key issue here.
I would suggest comparing one successful transaction with one failed transaction and checking the nativeIdentity, along with the memberOf DN being sent to AD.
If there is any difference between the two, especially in the nativeIdentity or DN, that could help identify why IIQ is generating the manual work item instead of provisioning automatically.
Due to company policy i had to redact a bit of the information.
Hope its enough…
From my brief analysis seems like Ihe workflow is taking the Manual Actions path because project.getUnmanagedPlan() != null. What could cause the requested item to remain in the unmanaged plan?
@tmamouros are you using a direct AD connector or logical connector? Found references of APPLICATION_LOGICAL_A?
Also during re-compilation in Process Approval Decisions, IdentityIQ compiled the plan for GROUP_PRO_A without a target connector integration (targetIntegration = null).. Possibly, because targetIntegration was not populated, IdentityIQ marked the modification as unmanaged. The condition evaluated to true, bypassing direct provisioning.
do you have any customization in your LCM flow that modifies plan?
The workitem is not of type ManualAction it’s of type Form and the description states Complete provisioning form for Vamsee Gadagottu which confirms that it’s a provisioning form.
In your environment AD application provisioning policy named “Account” has fields with ‘Review required’ option checked, which is why this form is showingup to review and submit the form with those fields’ values.
If you no longer need to review the provisioning policy calculated values you can remove the option from the fields in the policy and the form would no longer showup.