I struck a problem at a custom and the impact, while it seemed minor on the surface, was actually a big deal for their migration project. In fact, the large team they had assembled to migrate users from one forest to a new forest had stopped while this issue was investigated.
It relates to SID History and the way Windows queries for and caches Name-to-SID and SID-to-Name lookups from AD. This cache was causing SharePoint to think that a user who wanted to logon was actually a user from the wrong domain, and would create that person a new identity for that person within SharePoint for them.
The scenario is actually very close to this one:
But the workaround that we found would resolve the problem while they were migrating was pretty cool, so I thought I’d save it for all eternity here as a blog.
It boils down to this:
The LsaCache stores the previously looked-up domain user names and their SIDs. By asking a DC which has users that have both the new SID and the migrated SID on them at the same time, the DC always links the migrated SID to the new user name, not the old user name. If we can artificially fill the LsaCache with mappings for OLD USERNAME = OLD SID in our servers, then we can act as though no resources have migrated yet.
Here’s the scenario where users were migrated with SID History from child1.domainA.com to domainB.com
So we can see from the picture above that the LsaCache (the table in the bottom right of the drawing) has a mapping for NEW USERNAME = OLD SID but we want OLD USERNAME = OLD SID
So, let’s warm up the LsaCache so it looks the way we’d like it to:
Ah ha! Now our cache looks the way we’d like it, where OLD USERNAME = OLD SID. This way when a query for OLD SID is made, the result from cache will return OLD USERNAME.
The important step here is the red X where there IS NO STEP. What I mean is that the SharePoint server never talked to the DC to get the OLD SID lookup to return a result, meaning that we relied totally on the warmed up cache on the SPS alone.
This relies on the LsaCache on the SPS server ALWAYS having the entry for the SID from the CHILD1 domain matching the CHILD1 username, and never matching the DOMAINB username. The only way to ensure this is:
To view the actions as they are performed by LSA Lookups, add these 2 DWORDs to the registry under HKLM\System\CurrentControlSet\Control\Lsa\:
These keys are explained here:
So, all in all a little complicated, but the workaround to increase the value for LsaLookupCacheMaxSize and constantly running a script on the SPS server to query for the SID for usernames in CHILD1 (with a filter to target only users which had been migrated to domainB) worked well for the customer.
When you say the process that must be run to constantly query for the SID of CHILD1 users, what do you mean by "constantly"? Just long enough to keep them in cache? What if you have an environment where a lot of lookups are done? I think I am having this same problem on one of our customer's SharePoint farms, during a long-timeframe domain migration. There are disabled accounts in the new domain due to Exchange migration. I currently have an open Premier support case for this. Can you help?
@Brandon: Yes, the idea is to keep the cache flooded with the entries you want, so "constantly" is up to you to decide.
If you point the people who are working on your Premier case to this blog and give them my name, I may be able to help them along if needed. I won't be able to help directly just now though.
How horrible. Why are customers not asking Microsoft to fix this issue in SharePoint rather than applying dodgy hacks like this?
@Bruce - Would you like to contact me so you can be that customer and start that process up?
This is covered in the August 2012 CU.
The Product Group has added a command line that changes the behavior of this scenario. When you run this command:
stsadm.exe -o setproperty -propertyname "HideInactiveProfiles" -propertyvalue "true"
It will bypass the disabled accounts and query the active domain. The underlying issue is still unsupported (duplicate SIDs) but SharePoint now has more flexibility to deal with these situations.
That is great news Brandon. Thanks for sharing it. I've let my customer know that the stsadm tool has been updated with this workaround.