Orphaned SharePoint Foundation User Profile

Question

I am curious about the effects of user profiles after an employee leaves an organization. If former employee John Doe had a domain account of acmeinc\jdoe and his replacement, Jane Doe, also had the domain account of acmeinc\jdoe, how does it impact user permissions in the environment? Since SharePoint sees that they are the same domain account (despite being separate users), is it smart enough to create a new user profile for Jane?

In a recent project, I imported 200 new users into an existing environment; 2 of the imported users cannot access the SharePoint site. When I look through the _layouts/userdisp.aspx?ID= parameter value for these 200 uers, I see a number much lower than it should be for the 2 users without access. This makes me wonder if the import just overwrote a former user for these 2 people instead of creating a new user profile account.

Before anyone says it is a permissions issue, Jane Doe is added in the default "Site Members" group for the site. This, of course, was the first thing I checked.

User profile is synced through Bamboo Solutions.

Answer 1

If your site cleanup job is running, and your users are deleted from the directory source (Bamboo or AD?), then the old obsolete profile should be deleted. That means that a new user with the same domain\username as the old user, then SharePoint would create a new user profile, and not migrate the old.

But if the old user wasn't deleted from the user information list, the new user can't be imported correct, and gets an orphaned account instead. Check if that's true with

$upa = Get-SPServiceApplicatin <identity>
Set-SPProfileServiceApplication $upa -GetNonImportedObjects $true

If you see a list of users here, and you want to get rid of them, just

Set-SPProfileServiceApplication $upa -PurgeNonImportedObjects $true

Out of SharePoint these orphaned users go and you can sync with the directory again to import your new profiles.

Reference: SharePoint 2010–User Information Lists and User Profile Cleanup

Answer 2

Juan and Benny,

User profiles, site permissions and the user information list are three very diferent things, and will behave in a completely diferent way when a user gets deleted.

It's also important to mention that SharePoint Foundation (2010 & 2013) don't have user profiles as they don't feature the User Profile Service Application.

SharePoint server 2010 & 2013 both have the User Profile Service Application and can offer user profiles, which have nothing to do with permissions and security.

When using SP Server and the User Profile Sync Service (based on FIM) to sync user profiles with AD, when a user is deleted from AD the profile is deleted from SharePoint. When a user is created it is created in the user profile DB, even if they both have the same username.

Once again, let me repeat: this has nothing to do with permissions.

When a user is deleted from AD, it stays in the User Information List of the site collection and when you create a new user with a login that existed in the past, SharePoint will actually resolve the username to the previous user. This is quite odd and not what you want.

To solve this you need to delete the user from the site collection, by browsing to: http://<server>/_catalogs/users/simple.aspx

This will let you delete the user and then when you try to resolve the new username it will resolve to the correct user.

What happens at the DB level is that SharePoint will mark the old user as deleted and will create a new row in the UserInfo table for the new user, with the same username but diferent user ID and SID.

This means that the new user, even though it has the same username of a previous user, won't get the same permissions because the user has a diferent SID in AD and SharePoint uses the SID to identify the user and a lower level.

This is very important, not only because of permissions, but because you need to know who created and modified content. When a user is deleted from AD or the site collection, it can't be deleted from the DB. The user will always exist in the DB to maintain database referential integrity.