AD account provisioning fails during Access Request

Identity Security Cloud (ISC) ISC Discussion and Questions
, , ,
1

Hi everyone,

I’m facing an issue with Active Directory provisioning in SailPoint ISC.

Scenario

We are trying to provision an Active Directory account for an identity along with AD group entitlements through an Access Request.

What works

When access is provisioned through RBAC role assignment, it works successfully.

Example:

Identity attribute = Coordinator
↓
Role automatically assigned
↓
AD account + entitlement provisioned
↓
Success

The AD account and the corresponding AD group are provisioned without any connector errors.

What fails

When requesting the same access through an Access Request / Access Profile, provisioning fails.

Connector logs show the following error:

image
image1351×503 44.3 KB

Operation: GetObject
LDAP error code 32 - NO_OBJECT
Ensure that account CN=Caius.Navarro,CN=Users,DC=TestAd,DC=local exists

Another log entry shows the DN formatted as:

CN=Caius.Navarro\\CN=Users\\DC=TestAd\\DC=local

Additional info

Example aggregated AD account looks correct:

distinguishedName
CN=Liora McKellen,CN=Users,DC=TestAd,DC=local

Create Account mapping for DN:

CN=$(firstname).$(lastname)$(uniqueCounter),CN=Users,DC=TestAd,DC=local

Observed behavior

Scenario Result
RBAC role assignment Works
Access Request / Access Profile Fails with GetObject NO_OBJECT

Why would RBAC provisioning succeed but Access Request provisioning fail, even though both should modify the same AD account?

From the logs it appears that the connector is performing a GetObject operation to locate the AD account, which fails with LDAP error code 32 (NO_OBJECT). The logs do not show any Create or Add entitlement provisioning operation being executed.

2

Did the access request to existing account which was created through RBAC? Or it is creating a new account?

If it is a former case, then it is an update and it may be due to the AD cannot locate the Account to update. It may be due to various reason majorly when you have multi DCs where the account may not replicate in all DCs by the time when you are update it.

Check whether multiple DCs configured in your AD source. If so, keep one server and try it again if it is sandbox. If it is Prod, your AD team needs to implement a load balancer.

3

Hi Suresh,
Thanks for your response.

This is a Test AD environment and we only have one Domain Controller, so replication between multiple DCs should not be an issue.

In our setup, when a new identity is created from HRMS, an RBAC role gets automatically assigned based on an attribute, and that role provisions the AD account and entitlements successfully.

The issue occurs when an identity that does not yet have an AD account tries to request access through an Access Profile, direct entitlement, or role containing AD entitlements.

In that case, the logs show the connector performing a GetObject operation, which fails with LDAP error 32 (NO_OBJECT), and we do not see any Create account or Add operation being executed.

4

@Siddharth60,

Is the user created in AD? have you checked in AD whether the account is created or not ? Cause the error is getting for getObject operation post creating the user.

5

Hi Suraj,
I checked in AD and the account is not getting created when the access request is executed.

Also, this is not specific to one user. I tested with 3–4 different identities requesting the AD access profile, and the same issue occurs for all of them.

6

@Siddharth60,

Can you try DN as below:
CN=$(firstname).$(lastname)$(uniqueCounter),OU=Users,DC=TestAd,DC=local

1 Like
7

Hi Suraj,
I tried updating the DN mapping to CN=$(firstname).$(lastname)$(uniqueCounter),OU=Users,DC=TestAd,DC=local as suggested and tested again. However, the issue still remains the same.

8

Hi @Siddharth60 I suspect that log entry could be unrelated. It looks like a uniqueness check on the constructed dn.

9

Hi Jeremy,

Here’s the full log attached below.

ad_provisioning_failure_logs (33.4 KB)

10

HI @Siddharth60 My point is that the ccg logs may not be your first point of diagnosis. A get-object is not part of the provisioning task, it’s either a pre-provisioning task (uniqueness checking) where you would expect it to fail, or a post-provisioning task, where you would expect it to succeed. If it is a post-provisioning task failing then provisioning has already failed or its a scheduling issue. Either way it’s not the root cause of your issue. We don’t think it’s a scheduling issue as you have said the account was not provisioned at all.

I would check the ISC Provisioning Logs prior to looking at the CCG logs. If there’s nothing in there then your issue is more likely to be configuration

11

Hi @Siddharth60 , please try the below.
In the Distinguishname please add like below.
CN=$(firstname) $(lastname)$(uniqueCounter),CN=Users,DC=TestAd,DC=local

Also, in the Create Provisioning Policy can you please remove

sourceCheck:true and try to create user ?

{

“name”: “distinguishedName”,

“transform”: {

“type”: “rule”,

“attributes”: {

“name”: “Create Unique Account ID”

}

},

“attributes”: {
"sourceCheck": true,
“template”: “CN=$(firstname) $(lastname)$(uniqueCounter),CN=Users,DC=TestAd,DC=local”,

“cloudMaxUniqueChecks”: “50”,

“cloudRequired”: “true”

},

“isRequired”: false,

“type”: “string”,

“isMultiValued”: false

}
12

Hi Rakesh, I tried updating the DN as suggested. Regarding sourceCheck:true, I checked the configuration but it wasn’t present in the generator policy in the first place, so there was nothing to remove.

image
image789×312 8.19 KB

13

Hi Jeremy,

I checked the ISC provisioning logs as you suggested. I’m sharing the account activity JSON file which was generated using CLI for the access request.

AccessRequest.json (3.3 KB)

From what I see, the workflow shows “Workflow was terminated early” and “Manual Task Created”, but I’m not seeing any manual task in the UI to complete.

14

Can you please add sourceChec:true in your Provisioning Policy how I have added ?

Also, can you also check if your connector has Provisioning Enable ?

15

Hi @Siddharth60 Seems you’re getting closer to the issue. Without your config, I can’t diagnose, but have a look at the Access Profile. Check Entitlements and compare to your successful Role assignment. I take it you are requesting an AP?

16

Hi rakesh,

I have added the sourcecheck:true and yes the provisioning is ebaled for the source

“enableProvisioningFeature”: true,

17

Hi Jeremy,
One more thing I observed is

requesting the role directly also fails with the same response.

The only scenario where the AD account gets created successfully is when a new identity is created from HRMS and its attribute matches the role assignment criteria, which triggers RBAC automatically. In that case the role is assigned and the AD account is created without issues.

I’ve attached the AD source configuration, role configuration, and access profile configuration for reference.

AD_Source configuration (6.8 KB)

Role configuration (2.0 KB)

Access profile configuration (1.2 KB)

18

You appear to have different Entitlements in your Role than you do in your AP?

19

Yes, the role contains one JDBC entitlement and two AD entitlements, while the Access Profile contains two different AD entitlements.

However, I also tried adding the same two AD entitlements that are present in the role to the Access Profile and tested again, but the behavior remained the same and the request still failed.

20

Have you been able to make any successful access requests? Is the tenant enabled for access requests?