SharePoint People Picker shows old domain account during Active Directory migration

You may have experienced a problem with SharePoint PeoplePicker during Active Directory migration of users.  The scenario looks something like this:
 

Environment
You have 2 domains DomainA [the Source Domain] and DomainB [the Target Domain].  Users are in DomainA and are being migrated to DomainB.   The SharePoint farm is in DomainB.  There is a two-way Trust between the domains.  The domains are in separate AD Forests.   Users have been migrated to DomainB with SIDHistory from DomainA.  The DomainB accounts may or may not be disabled.  Users are still using the accounts from DomainA and want to access resources in DomainB, specifically SharePoint.

Problem

When you use SharePoint PeoplePicker to add users to SharePoint resources the name resolves to the DomainB user.  Even if you added the permission before the migration the name resolves to the DomainB user.

Cause

This is caused by the SID being used to tattoo the resource within SharePoint.  Just like on an NTFS file system resources are permissioned with unique identifiers called SIDs.  The domain where the resource is located, in this case DomainB (SharePoint), the SID is resolved by a local domain controller with the domain that the resource is a member of.  The Domain is authoritative for all SIDs in its Active Directory.  Even in the case of SIDHistory.  When you migrate a user from DomainA to DomainB with SIDHistory, the new account has a new SID in it originating domain and an AD Attribute that is populated with the SID from the account in DomainA.  Because the DomainB domain controller knows that this SID in attributed to an account in its own AD it will resolve that SID to the account in DomainB.   It will consider itself the authority for that SID.  It see no need to resolve this SID to another Trusted domain.

Here is how SID to Name resolution works:

The LookupAccountSid function attempts to find a name for the specified SID by first checking a list of well-known SIDs. If the supplied SID does not correspond to a well-known SID, the function checks built-in and administratively defined local accounts. Next, the function checks the primary domain. Security identifiers not recognized by the primary domain are checked against the trusted domains that correspond to their SID prefixes.

Pasted from <https://msdn.microsoft.com/en-us/library/aa379166(VS.85).aspx>

There is a misconception that if you set the LDAP query property in SharePoint it will use this to resolve user names.  This is not correct.  PeoplePicker may temporarily resolve the name correctly but the SID will not change and therefore the underlying issue is still going to manifest itself.  PeoplePicker is just SID to User Name resolution much in the same way DNS resolves IP addresses to host names in DNS.  To continue with this metaphor, you would essentially have 2 DNS servers with different host names that resolve to the same IP address.   You will get inconsistent name resolution.

Furthermore because the SID does not change you will have other issue that do not involve PeoplePicker, like Alerts, Workflows, and MySites issues.  These SharePoint technologies use the SID and not PeoplePicker.  An example would be if  the account in DomainB is disabled you may see an error trying to provision a MySite. 

Resolution

From a SharePoint point of view there isn't much you can or should do to relieve the PeoplePicker issue.  This is only a temporary behavior (during the migration) that will not persist once the migration is complete.  At that time you will want the default behavior.  So making changes will have to be reversed and they will not affect other issues with the SID.  The underlying cause is that you have duplicate SIDs in your environment.  This is not supported and is in fact unsupportable.   Each account needs to be unique.  To ensure this you need to remove the source account as soon as you migrate it, by disabling the account.  Users should use the new DomainB account.  If this is not feasible you may need to rethink your AD migration strategy. 

Another solution would be to have SharePoint remain in DomainA until the migration is complete and then move it.  This will cause other problems and is more complicated than just migrating user accounts.

Example of a SID (Security Identifier)

objectSid: S-1-5-21-123456789-123456789-123456789-747766;

sIDHistory: S-1-5-21-9876543210-9876543210-9876543210-1315

https://technet.microsoft.com/en-us/magazine/2005.05.migration.aspx

General information

Alert users to the fact that their user accounts are scheduled to be migrated to a new domain. Point users to a Web page or internal resource where they can find additional information, and view a migration schedule.

Inform users of their new domain name. Be sure to let them know that their account passwords will not change. Let them know that the original domain account will be disabled immediately following the migration, and the disabled account will be deleted after a specified period of time.

Pasted from 14_CHAPTER_11_Restructuring_Active_Directory_Domains_Between_Forests.doc p.493

Comments

• Anonymous
  January 01, 2003
  Hi All, Today we migrated some of our test users with a new domain, then we ran the search with full crawl. The user profiles are migrated successfully, but are not displayed in sharepoint search. We can add those migrated users to a group, etc, with the help of people picker, but those users do not show up in sharepoint search like the other users. Pls help !!!!!!!!!!!!!!! thanks in advance……….

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  July 07, 2010
  Aside from Mr. Klindt's Trans Am logo this is a good blog to describle the migrate user command in stsadm

• Anonymous
  February 22, 2011
  Have you tried "stsadm -o setsiteuseraccountdirectorypath" It solved it for me!

• Anonymous
  January 02, 2013
  Another good explaination of this is here: blogs.technet.com/.../sharepoint-and-sid-history-not-playing-well-together.aspx