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.


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


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.

  • A few comments here: 1) User profiles do exist in Foundation, but they are not easily managed as they are with SPS. You are correct in saying that there is no UPS. Like I mentioned, there is a Bamboo Solutions sync that exists in this environment to overcome that syncing to AD obstacle. 2) I am well aware that user profiles are not directly related to permissions. But like I mentioned, this was the first thing I checked to acknowledge there was no quick and easy solution. 3) If we delete the user as you suggest, all historical data about old user is gone. May not work for auditing purposes. – JuanTrev Jul 15 '13 at 16:04
  • What I am hoping is to keep the old user in the user profile database table so historical data, like job title, are maintained for list item entries. This way the organization can view details of former users if needed. But, if a new associate with the same domain name is added, a new ID should be created and used instead of using the domain account as the key field. This may very well be an issue with Bamboo's User Profile Sync, so I am researching that too. – JuanTrev Jul 15 '13 at 16:11
  • Juan, there is no such thing as User Profiles in SharePoint Foundation. If Bamboo Solutions tells you so, maybe they did some custom development to implement something like the User Profiles, but these are not User Profiles. – Luis Jul 15 '13 at 20:39
  • They may have written a piece of code to import data from from AD to the User Information List, where SPF keeps the users of each site collection (same goes for SPS) and if this is the case, then they're code is broken as they're using the logon name as the key to join SPF users with AD when they should be using the SID. The SID is always diferent for any AD user, even if the logon name is the same. And SharePoint handles that quite well. If John Doe (domain\jdoe) is fired and Jane Doe (domain\jdoe) is hired, SharePoint will keep a record of which documents where created by each user. – Luis Jul 15 '13 at 20:43
  • It would be a major flaw if it didn't. – Luis Jul 15 '13 at 20:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.