NotAllowedOnRdn error and adapter export fails and the object is renamed but not updated in AD
Customer PII has been redacted or anonymised in the screen snapshots of this topic.
Initial adapter entity:
I changed the user's first name from "Alarinka" to "Blarinka" and allowed normal processing to occur with the AD import schedule disabled so I could check the adapter entity after export. Here's the failed export to the AD adapter, including a dump of the entity being updated (via a PowerShell reverse transform):
Adapter entity after the update is unchanged:
In AD, the rename was successful but the givenName and displayName update were not:
After a subsequent import on the AD connector (to update the adapter entity) and a Baseline Sync on the outbound locker the AD givenName and displayName details are updated correctly:
Adapter entity after AD connector import:
Baseline Sync log shows successful update:
Adapter entity after Baseline Sync:
I am pretty confident that the code that does the AD object export is renaming the AD user first, then attempting to update its attributes using the old DN rather than the new one. The rename succeeds, but the attribute updates fail.
I suspect this bug has been mysteriously frustrating me for a long long time so if you could fix it then I would be incredibly grateful.
Customer support service by UserEcho
Is this an AD instance controlled by the project or the customer? Wondering if we might be able to reproduce the problem elsewhere to have some more granular control over the investigation, and potentially get access to any available AD logs.
You're correct that the call does the rename operation first, however the update operation is written to use the new DN. We can confirm this with the error message - the code variable used to populate the call to AD is the same one that populates the error message, and we can see that the DN in the error messages matches the DN in your entity dump.
All hosted on our infrastructure, including AD. Details are in LastPass under the UNIFYConnect/customer/environment name.
Sorry was on phone earlier and couldn't write much.
That environment is currently in configuration development (by me) and I can stay out of it for a few days while you work on it if you want. The AD DC is the "AD VM" mentioned in LastPast, hosted in UNIFY's Azure tenant, so you can turn on whatever logging you want. Perhaps the problem is that the rename operation is returning before it completes on the server, and then the update of the new object fails because it's too soon and the rename hasn't had a chance to commit in AD? Maybe swapping the order of the update and rename might help - or possibly just cause a different problem. A standalone .NET exe that invokes the two AD LDAP operations in quick succession might shed some light on the issue, too.
I've determined the cause of this issue, and it is related to the
cnfield not accepting changes, which can be replicated outside of Broker. The move operation does occur first which is why it does succeed, and this updates the
cnfield in AD automatically.
cnfield should be set as
readonly, however I also found that the AD agent still attempts to update changed
readonlyduring an update operation. I've put together a patch for both of these issues, though you'll need to set
readonlymanually, as I can only patch the default setting.
At least on the my Server 2022 AD instance, and an older Server 2019 instance, manually setting the cn field isn't allowed. Perhaps older servers had different restrictions or configurations and allowed this, but I don't have one of those handy to test.
In any case, if simply not setting the CN field is a acceptable workaround for you then, go for it. The patch for the fixes I described above is already with David. Not sure where he's up to with it, but let him know if you'd rather he hold off on its deployment into your Connect instance.
I can confirm that removing all reference to CN and just setting DN works great and solves my problem.
Now I have to go back and update every single UNIFYConnect configuration I've ever built :-(
Thank you Matt and Beau for your help.