UPN not being created in AD

We have multiple connectors into AD. One connector is working just fine in generating the UPN for accounts. The other is not. The creation profile is the same for both for the creation of the UPN. It is using a rule. I have validated through vscode that the parameters match up to what is being done in the other connector.

In events on the Identity, I don’t see any errors. However if I go and search using: @accountRequests(*) && “Users_Last_Name”, I do see an error.

ADLDAPConnector Failure. Account created but some attributes are nto updated properly. Account created but failed to modify: A constraint violation occurred.

It suggests to refer to the remediation status report.

Where do I find this report?

The service account for both connectors is the same, so it shouldn’t be a rights issue. The rule is doing a search against each AD Connector, so it should be finding any UPN that exists and doing an incremental.

Is there a way to see what the output is on the initial creation attempt, to see what UPN is being attempted? I don’t see a debug option to set on the AD Connector. If I have it set on the VA, will that be sufficient? Waiting for access to the VA’s, to look at the logs on the VA.

Hi @ts_fpatterson ,

If account has been created but failed to update few attributes that might be due to the attribute uniqueness. Please check if the provision attributes like UPN, Email, SamAccount values are unique. Also I would suggest to check if mandatory attributes are available on create profile page.

To check the failure, kindly Go → Search → Report → Provisioning Report it will provide the error state with the message.

In depth if you want to check the generated attributes values. Please enable the CCG logs on VA and find the more details. Below provided link for enabling CCG logs - CCG Enable Debug Log by Connector - Compass.

I hope it will help.

2 Likes

I’ve observed this error and this scenario once before, so I can shed some light into what the issue was in my case and I hope it helps you identify the issue on your side.

If you’re connecting to different ADs here, it might be that the problematic AD has some constraints on the attributes on the AD side, nothing wrong with how you’ve set it up. I’d say check the attribute constraints for all the ones involved in account creation/updates with the AD admin and identify the constraints put on this AD.

However if your AD is the same for both sources, then this is some spooky business. Do you have different DCs in that case? If you are certain that there are no native rules, or if there are, they are identical, and everything else is virtually the same, then you will have to deep dive with expert services here.

It is the same AD domain, once I get ahold of the CCG logs I hope to see the attribute values being sent and rule or identify the issue. We have multiple connectors to the same AD domain as we have multiple types of personas for the same person. Example would be privileged.

Hi Fred,
If it it is the same AD, but you need to create different types of account due to factors being imported from the HR source, surely it would be simpler to use just the one connector, but factor those differences into the CREATE profile? Possibly using firstValid transforms?

Hi @ts_fpatterson,

Could you please check the list of attributes being set during provisioning? Also it would be great if you can let me know whether while AD account creation are you able setting the manager?

If so could you please confirm if the shared details for Manager is their DN value?

Rest to get more info. in depth kindly review the CCG logs.

If I remember correctly, if you have entitlements assigned to an employee, but they also have a different account as a privileged user with the need for some of the same entitlements, you must use a different connector.

Should we not being following the principal of least privilege?
No privileged user accounts, but use PIM instead to elevate the ONE account when needed and only for as long as need. Having admin accounts alongside normal accounts is a very old way of managing the business

Customers are in different phases of progression towards best practices. Expecting them to achieve to the best practices all at once delays the progression they are currently able to achieve or work towards.