This post was migrated from an older system. Some links may point to content that no longer exists. Comments were not migrated.
Last night, I ran across a pretty nasty problem with SharePoint 2010's Managed Accounts.
If you delete the underlying account that is referenced by a SPManagedAccount instance, you will lose the ability to execute a variety of administrative tasks. Nothing like being the highest permissioned authority in a SPFarm and be unable to do most anything.
Here's the repro:
- Create local or AD account "test123"
- Create a managed account that references "test123"
- Delete the account (but leaving the managed account intact)
In the above steps, note that I don't use the SPManagedAccount at all within SharePoint. I simply created the account and then created a SPManagedAccount.
At this point in time, your administrative capabilities start to diminish. The severity of the problem is completely dependent upon which product you are using - Foundation or SharePoint Server.
The biggest indication that you've lost control is the following error message that may appear when you try to enter particular pages or execute various actions:
Some or all identity references could not be translated.
Once you're in this state, there is no easy way to back out of the mess. In fact, your experience will degrade over time (in other words, you will be progressively locked out of more of your farm as time progresses). It's painful.
What areas are affected?
In SPF, there does not appear to be much collateral damage. Aside from being unable to delete the Managed Account, it seems you are mostly ok (please note that I spent all of 15 minutes on SPF install trying to get a repro and validating the fix).
In MSS, the problem is super nasty - I was locked out of Manage Service Accounts, Timer Jobs, and few other areas. In the areas where I could reach the configuration page, updates were prohibited. This is where I spent most of my time trying to understand the problem after I ran into it.
In Foundation, there is an unsupported way to remove the reference to the account. One special query and flush of your config cache and you're back to a good state.
In MSS, that same action is useless because the User Profile service is now integrated into practically every call out to a user identity.
After spending the better part of an evening trying to recover my ability to administer a SPFarm, I found the only way to accurately and easily restore admin functionality is to restore the deleted account.
This scenario quite frankly scares me. Why?
Most SharePoint teams don't control their AD accounts. Therefore, it becomes really easy for AD team to clean up accounts that they believe are not in use and unknowingly kill the ability to administer a SPFarm.
Recovering deleted accounts from AD is a pain.
- Note: There may be no opportunity to restore local accounts (this is an educated guess - I don't know enough to say with any authority). However, most installs that go with a Standalone installation never use anything more than what the installer configures; this problem may never appear in those configurations anyways.
- There may be a delay between the time the deletion occurs and you run into the first denial. Therefore, it may be hard to connect the dots.
Aside from the error message that may pop up, how can you tell if your underlying accounts are missing?
Try enumerating the Managed Accounts (via CA or Get-SPManagedAccount). SharePoint will show a blank entry for Last Password Change (or PasswordExpiration).
What is the sure fire way to fix the problem? Restore the account. As soon as the account exists (even if disabled), the authorization routines work and it's like nothing ever happened (sort of - you may need to reset some services like the Claims to Windows Token service).
What is the sure fire way to never get into this problem? The proverbial "duh" is to not delete any accounts that are referenced by SPManageAccount in the first place. :)
Here's to saving someone from a sleepless night...