My Profile Photo

Gareth Fletcher

Cloud admirer, technology sherpa, visio fanatic, high-functioning madman. Based in Auckland, New Zealand.

Unable to login to Dynamics CRM with a re-created AD account

OK, this has happened before but I forgot to write about it. Consider the scenario where you are running Dynamics CRM with claims based authentication via ADFS and: 1.User account exists in CRM. 1.User leaves company, so their CRM user account gets disabled. 1.User’s account then gets deleted from Active Directory. 1.User re-joins company at a later date. 1.A new AD account gets created. 1.Their CRM user account gets re-enabled and linked to their new AD account. 1.User cannot login though via claims.

The error we ere getting is this:

Access Error – The system could not log you on. This could be because your user record or the business unit you belong to has been disabled in Microsoft Dynamics CRM. Try this action again. If the problem continues, check the Microsoft Dynamics CRM Community for solutions or contact your organization’s Microsoft Dynamics CRM Administrator. Finally, you can contact Microsoft Support.

This is happening because there’s some tables within CRM’s configuration database, MSCRM_Config, that links the user account to the CRM user.

If we have a look at the SystemUserAuthentication table within MSCRM_Config. For each user account there is are two records with Authinfo in this format: 1.W:S-1-5-21-814435214-361273581-2648185537-51837 – the user’s AD SID 1.C:[email protected] – the claims user (likely will be the user principal name).

Thanks to the [blog][] from Atrio systems, we can use the query they wrote to see what’s wrong

SELECT sub.SystemUserId, sub.fullname,
       sub.ActiveDirectoryGuid, sua.AuthInfo,
       sua.UserId, sub.IsDisabled
FROM org_MSCRM.dbo.SystemUserbase sub
INNER JOIN MSCRM_CONFIG.dbo.SystemUserOrganizations suo ON
       suo.CrmUserId = sub.SystemUserID
INNER JOIN MSCRM_CONFIG.dbo.SystemUserAuthentication sua ON
       sua.UserId = suo.UserId
WHERE sub.DomainName = 'domain\userid'

The result we get is just one record, with the w:sid W:S-1-5-21-814435214-361273581-2648185537-51837. We can look at the UserID field from above, and fix up the SystemUserAuthentication table (of course take a backup beforehand. And THIS IS UNSUPPORTED, DONT ACTUALLY EDIT CRM DATABASES DIRECTLY):

UPDATE [MSCRM_CONFIG].[dbo].[SystemUserAuthentication]
SET UserID = '0194DE20-EB2F-F245-80C6-00233E523815'
WHERE AuthInfo = 'C:[email protected]'

Where the UserID 0194DE20-EB2F-F245-80C6-00233E523815 is from the previous query results.

Then voila! It should work.

I’ve also had another circumstance, where we had to update the W:SID record instead (opposite of above).

An issue with the CRM for Outlook Add-in

This reminds me of another issue I’ve had relating to the SystemUserAuthentication table, where a user exists in multiple CRM organizations (multi-tenant CRM deployment, lots of UAT/test orgs exist). When they go to configure the CRM for Outlook Add-in, they only see a subset of the organizations they belong to. This also was caused by the AD account being recreated.

After some poking around in the Config DB (in a true unsupported fashion of course) we managed to fix.

We could see with profiler that CRM was running the stored procedure p_GetDefaultOrgFromAuthInfo. We can look at this stored procedure to see how the records are related. In this case, it was returning two results (!!):

SELECT DISTINCT suo.OrganizationId as OrganizationId
	FROM SystemUserOrganizations suo
	JOIN SystemUserAuthentication sua on (suo.UserId = sua.UserId)
	JOIN Organization o on (suo.OrganizationId = o.Id)
	WHERE sua.AuthInfo = 'C:[email protected]'
	AND (suo.IsDisabled is null or suo.IsDisabled = 0)

In this case, our issue was caused by something screwy in our config DB. Our user had duplicate entries with in the SystemUser table. There should be only one of these records for each user. The related records, in SystemUserOrganizations and SystemUserAuthentication were then pointing to two different records in SystemUser rather than both pointing to a single record.

The fix, since we could see some organizations while configuring the Outlook Add-in, we updated the SystemUserOrganizations and SystemUserAuthentication records relating to the organization’s we couldn’t see, to point to the same SystemUser record from the working organization.