Ensure exports that we expect to fail actually fail

Patrick Johannessen 11 years ago in UNIFYBroker/Aurion updated by anonymous 9 years ago 1

Here's an obscure one;

At Aurion Corp we terminated a user and placed them in to a container that wasn't managed by the AD connector. As such, when we re-hired them it couldn't find their first account and provisioned another with the same sAMAccountName.

They and I both understand that ALL users should be contained in the scope of the AD connector for this reason, but all the same I would have expected the export to fail with an "Object Already Exists" LDAP error... only it didn't. It created it in a "half finished" state, so when you clicked on the account tab it said it was corrupt or something and needed to be recreated.

Just wondering if we expected this - it's possibly that when we add userPrincipalName it will correctly pick up the duplication, not sure. Maybe we should look at picking up an error if we can get it throw one then retry with 2 or 3 revisions of the account name? Might be difficult.

This should be covered by the AccountNameExists methods checking the AD instance. A rule in the PowerShell script is already adding increments to the account name until it finds a new user.

Marked as resolved, to be confirmed in testing