System.Security.Principal.IdentityNotMappedException: Some or all identity references could not be translated – Trying to access Configure Service Account in SharePoint 2010

***UPDATE 29/06/2011 ***
I’ve just noticed that Microsoft have resolved this issue in Service Pack 1 see item 284 in the following spread sheet provided by Microsoft Download the Microsoft SharePoint 2010 and Office servers Service Pack 1 Changes.xlsx.

Following on from a previous blog where I was testing the access a sandboxed service account needed to run the service I created a test account to figure this out. Following on from this I wanted to tidy up my install and delete any unused accounts.
From AD I deleted the account from the service accounts OU. Now afterwards this is easy to realise but what I should have done is delete the service account from the Configure Managed Accounts section first but I didn’t on the assumption I could do this afterwards (In honesty I forgot!).
So a couple of hours passed not thinking about this I tried to access Configure Service Accounts in central admin but was prompted with a nice error as shown below.
I spent about 1/2 day trying to figure out what was causing this asking myself what had been changed since this error appeared, its also worth noting that the error didn't start appearing straight away which leads me to think its a timer job that triggered the change. On a side note I also noticed that the Forefront Identity Manager Service and the Forefront Identity Manager Synchronization Service had both stopped.
I couldn’t find anything of any significance on the web regarding the error ‘Some or all identity references could not be translated’ most of the entries out there referred to either password changing or starting again.
Checking the logs (default location C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS) and noticed 2 lines related to my Correlation ID error.
06/11/2010 10:33:45.80     w3wp.exe (0x1434)                           0x01D4    SharePoint Foundation             Runtime                           tkau    Unexpected    System.Security.Principal.IdentityNotMappedException: Some or all identity references could not be translated.    at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)     at System.Security.Principal.NTAccount.Translate(Type targetType)     at Microsoft.SharePoint.Utilities.SPUserUtility.AccountNameToSid(String accName)     at Microsoft.SharePoint.Utilities.SPUserUtility.IsLocalAccount(String loginName)     at Microsoft.SharePoint.ApplicationPages.FarmCredentialManagementPage.HandleLocalAccounts()     at Microsoft.SharePoint.ApplicationPages.FarmCredentialManagementPage.OnLoad(EventArgs e)     at System.Web.UI.Control.LoadRecursive()     at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPo...    1e9a974d-66a0-42ca-b2ac-28b864d42f0a
06/11/2010 10:33:45.80*    w3wp.exe (0x1434)                           0x01D4    SharePoint Foundation             Runtime                           tkau    Unexpected, Boolean includeStagesAfterAsyncPoint)    1e9a974d-66a0-42ca-b2ac-28b864d42f0a

There was also a warning in event viewer logged as Event ID 1309.
As I mentioned earlier I suspected a Timer Job was running that caused the delay in me receiving this error and as part of my testing I attempted to manually run the timer job ‘Password Management’ but this logged an error in the event logs as shown:
The Execute method of job definition Microsoft.SharePoint.Administration.SPPasswordManagementJobDefinition (ID cc5a6873-5ab6-4475-b0e8-b385c3b1618c) threw an exception. More information is included below.
Some or all identity references could not be translated.
Scratching my head I thought what if it is down to an account that I deleted from AD that isn’t running any services but is part of the Managed Accounts?
I tried to delete the account from the managed accounts page but received the same error prompt.
I recreated the account in AD (obviously appreciating that it would have a new SID) and cheekily tried (running an IISRESET first) to see if this would resolve the problem (knowing that it probably wouldn't) it didn't!
So my next thought was to try assign the newly recreated account and SID with the one referenced in SharePoint and ran the command:
stsadm –o migrateuser –oldlogin domain\serviceaccount –newlogin domain\serviceaccount -ignoresidhistory
**NOTE** Making sure that the oldlogin and the newlogin were exactly the same user and domain.
After running the stsadm command and re-running ‘Password Management’ timer job, followed by a user profile import (incidentally I had to restart the user profile import service on the server) I was finally able to access the Configure Service Accounts section with no error.
I appreciate this may not happen often in the field however I’m sure when the AD guys are looking to clear up unused service accounts this may have an impact.
I have managed to recreate the error and logged with Microsoft – will keep you posted.
*** UPDATE 07/09/2010 ***
After various discussions with Microsoft support they were unable to replicate the exact error. The error found in MS test environments was a little more user friendly but still it proves there is an issue.
The error received from Microsoft when performing the action is shown below:
“An error occurred while getting information about the user user1 at server The user name could not be found”
Ok so my thoughts were (and I shared this with Microsoft) is yes the error is a little more user friendly however you still receive an error when trying to access the managed service account page that will not allow SP admins to perform modifications to managed service accounts after an unused account is deleted.
The outcome was that as Microsoft were not able to replicate ‘the exact’ error message a formal bug is not going to be raised although the issue has been submitted to the Microsoft SharePoint product team.
I’ve since recreated this error to match the one Microsoft have experienced on their environment and I still suggest this is a bug with SharePoint 2010.
I haven't tested this with either June 2010 or August 2010 cumulative updates to see if this has been fixed under the radar – feel free to leave me a comment if you find anything further.


Anonymous said...


I'm haveing exactly the same problem. What about deleting the account using ps' command remove-managed account?

By the way, how am I supposed to know what account has been deleted from AD but still a managed account? Browsing AD's (one by one) accounts and comparing them with the managed ones?

..Thanks for the post :)

Paul Grimley said...

Hi, Thanks for the comment, re PowerShell I imagine you can I havent tried it, please do keep me posted so to help others if you get chance. As regards which account this was my whole point to MS that a SP Admin won't know which account would have been deleted or even that an account has been deleted causing them to scratch their heads wondering what has changed on the SP environment (which in this case is nothing - directly anyway). The only way to find out would be to run a report on AD and see what account have been deleted. Great fun I know! Thanks Paul

Anonymous said...

Hi again.

I think yo can fix the problem through PS. In my case, it didn't work because, when trying to remove the managed accoun (through PS), I'm getting the following error:

Remove-SPManagedAccount : The account MyDomain\myusr was not found.
At line:1 char:24
+ Remove-SPManagedAccount <<<<
+ CategoryInfo : InvalidData: (Microsoft.Share...eManagedAccount:
SPCmdletRemoveManagedAccount) [Remove-SPManagedAccount], InvalidOperationE
+ FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletRemoveMa

I get this error eventhough I can see the managed account when i run the command get-spmanagedaccount.

It's weired ... dunno what to do :(

Paul Grimley said...

Thanks for the update. As regards what to do raise it with MS :) The more people who report it the better. I simply didnt have time to continue the support call as I wasn't getting anywhere fast as the error the had (and thye did have an error) didn't match my error and therefore could not replicate the issue! If you have a consistent failure and can capture all the issues please do raise the issue. I wanted this fixed to help SP admins (Especially new adopters of the technology) not to fall into these querky traps. Thanks Again Paul

Anonymous said...

Hi Paul,

after 1 day searching what the workaround could be, we finally fixed out the problem.

We solved it sniffing the queries that were done when accessing "configure service accounts" (just before getting the "some or all identities could not be referenced" error). So we deleted from the db (sharepoint_config) the managed account and all of its dependencies.

Thanks a lot for your support.


Paul Grimley said...

Hi Gabriel, thats great but...... You can't delete directly from the SharePoint SQL DB's as its not supported and any future issues you have with your farm would not be supported by MS as you've tampered with databases. Thanks Paul

Derek said...

Hi Paul

It's errors like this that always take up the most time, so thanks for the post. A client had a similar issue today whereby trying to access various parts of Central Admin (Manage Service Apps, Backup etc) gave the error “specified user or domain was not found” and looking in the logs pointed to "System.Security.Principal.IdentityNotMappedException".

After some digging around it turned out that earlier they had renamed the original administration account in line with new naming convention. Renaming it back to original seems (so far) to have resolved the issue.


Paul Grimley said...

Hi Derek, thanks for sharing and glad it helped its always pleasing to see. Thanks Paul

Mark Stokes said...

Hi Paul.

Thanks for this. You have just saved my skin.

I was amalgamating some Application Pools and deleted the service account for a now disused application pool straight from AD rather than through the Managed Accounts Central Administration page.

The migrateuser opertation sorted it out for me.

Thanks mate.


Paul Grimley said...

Thanks for the comment Mark. Glad to see this is helping others avoid the issue.


Anonymous said...

This allowed me to access the Service Accounts again! THANKS!

Anonymous said...


Anonymous said...

I'm having this same error in a claims based authentication environment that I set up. I added a super user and super reader account using Powershell and then did an iis reset. I was able to log in once using the farm account and after that consistent Event ID: 1309's. Does anyone 'really' know what's causing this? I would appreciate any help that You can get.

Paul Grimley said...

Could be cache related? I've seen similiar issues resolved by clearing the cache

Anonymous said...

it has been taken to account by Microsoft.
in SharePoint 2010 SP1
just delete the account in managed account

Paul Grimley said...

Hi, you must have missed my update on the 29th June 2011(start of the blog post) highlighting this had been resolved in service pack 1.

Carlos J Sosa M said...

Hi everyone:

In some cases this error is because the username has more than 20 characters (SharePoint uses the pre-windows 2000 username). Using accounts wirh 20 or less characters works. Read more at:


Post a Comment