One of our clients ran into an interesting issue where a user (let’s call her Sally Jones) could not log into Dynamics CRM (on-premise). Sally had left the company, and her CRM user account had been disabled and her Active Directory user account (DOMAIN\sj1) deleted. She then returned to the company a few years later.
Because her old Active Directory user account was deleted, it was not possible to enable her user in CRM. This is because CRM user records are tied directly to Active Directory user accounts, so CRM would throw an error saying that the AD object doesn’t exist. A new Active Directory user account (DOMAIN\sj2) was created for her as well as a new CRM user, but she was still unable to log in.
We checked the obvious things like Security Roles but everything in CRM was set up correctly. It turns out that both of her CRM user accounts share the same UPN (email@example.com), so CRM was getting confused when she was logging in, thinking that her user account was disabled.
To fix this, we had to go deep into the CRM database and make some unsupported changes.
The first thing to do is to open the enabled CRM user record (DOMAIN\sj2) and change the username to someone else. Note that it must be a username that isn’t already used.
Next, create a dummy Active Directory user and note down their unique identifier (GUID format). We need this later for updates to the database.
Every CRM user record has a field called ActiveDirectoryGuid. This stores the unique identifier of the corresponding user record in Active Directory. Remember that Sally’s disabled user record uses a GUID that no longer exists since her AD user was deleted, so we must update it to use the GUID from our dummy user in step 2 above. We ran the following command.
Update systemuserbase set activedirectoryguid = <GUID from Step 2> where systemuserid = <systemuserid>
Now that DOMAIN\sj1 has a valid ActiveDirectoryGuid, we can enable the user in CRM. After enabling it, we changed the username field to DOMAIN\sj2 (the new user account).
We no longer need the new CRM user so we can disable it.
Now Sally can log into the system with no issues. Even better, because we tricked CRM into updating her old user record, she still has the same Security Roles and records from when she left the company. Although this is a unique issue that I’ve only seen once in the ten years I’ve worked with Dynamics CRM, it’s worth sharing with you all in case you ever encounter it.