NotAllowedOnRdn error and adapter export fails and the object is renamed but not updated in AD

Hi Adrian,

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.

Hi Adrian

I've determined the cause of this issue, and it is related to the cn field 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 cn field in AD automatically.

The cn field should be set as readonly, however I also found that the AD agent still attempts to update changed readonly during an update operation. I've put together a patch for both of these issues, though you'll need to set cn to readonly manually, as I can only patch the default setting.

Via email

I have often updated CN from UNIFYBroker in other configurations I’ve built – so long as the value being set for CN matches the first (CN=) element of the distinguishedName. Indeed, trying to set distinguishedName from UNIFYBroker *without* also setting CN has not worked for me in the past, so I’m concerned that if I stop setting CN I’ll see that behaviour and it won’t work at all.

Can you confirm that you have a tested UNIFYBroker config where a change to just distinguishedName – and not CN – works correctly (i.e. an entity rename with other attributes changing at the same time works, without error)?

Now that Voice is back up I can see the screen snapshot you attached, and the text you wrote now makes better sense to me.

I’m happy to go ahead and try updating just the DN, to see if CN updates automatically as you believe it will. If that works then there shouldn’t even be a need for a patch – just a note made that we should never change the CN attribute from UNIFYBroker configs, and only ever update DN instead.

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.