We onboarded an Azure Entra ID application in IdentityIQ to provision B2B users. The test connection and preview are working fine.
However, when users request access through QuickLink (manager user access / entitlement request), the account gets created successfully, but the entitlement is not assigned properly. Instead, it is being added as a sticky entitlement.
We are also receiving the following error:
ERROR: sailpoint.connector.ConnectorException: Exception occurred. Error message - HTTP not ended OK. Response Code - 403 Error - Insufficient privileges to complete the operation.
Interestingly, after the account is created, if we request the entitlement a second time, it gets assigned successfully.
Has anyone encountered a similar issue? Could you please suggest what permissions or configurations might be missing on the Azure Entra ID side or within the connector configuration?
I remember similar case for Active Directory connector.
When we try to provision or even do test connection for 1 st time, it was taking long time and giving error. But from 2nd time onwards, it was successful.
So for next 30-60 minutes all provisioning was successful.
After around 1 hour, again same problem. test connection used to fail for 1st time, and working from 2nd time.
Later this issue was fixed after checking with AD team. No change required in IIQ. I don’t remember exactly how this issue was fixed. But you can check service account used in IIQ along with permissions and is there any configuration of timeout at target side.
@PydiManiPadmaPriya Could you please enable logs and see what API call IIQ is making to create the account and try the same in Postman. This should let you know if Entra is having some restrictions that is stopping you from assigning entitlements while creating accouunt.
Adding to my colleague’s response — after enabling debug logs in the Before Provisioning Rule, we were able to identify the actual root cause.
During Guest B2B account creation, SailPoint was sending the following attributes in the create account request:
userPrincipalName
password
forceChangePasswordNextLogin
These attributes are used for regular cloud user creation, but they should not be sent for Guest B2B users, since Azure creates guest users through the Invitation API and does not support password-related operations for guest accounts.
Because these attributes were included in the provisioning plan, the Azure connector attempted to execute setPassword(), which resulted in the misleading error:
403 – Insufficient privileges to complete the operation
To resolve this, we added logic in the Before Provisioning Rule to check if accountType = Guest User B2B and remove these attributes from the provisioning plan before the request is sent to Azure.
After making this change, guest account creation and group provisioning worked as expected.
Thanks to everyone for the suggestions — enabling provisioning rule debug logs helped identify the exact issue.
