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.

*** ORIGINAL POST ***
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    ...int, 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 domain.com: 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.