Bluedog Limited > SharePoint Thoughts > Posts > Deleting the underlying account of an SPManagedAccount wrecks havoc
April 23
Deleting the underlying account of an SPManagedAccount wrecks havoc
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:
  1. Create local or AD account "test123"
  2. Create a managed account that references "test123"
  3. 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...

-Maurice

Comments

It's true!

After spending some hours, I'm got convinced: you are right. Unfortunately, my customer dcpromo'ed the last DC in their domain. So I think rebuild the environment will be faster than repair.

Thank you.
 on 1/22/2013 3:56 AM

Another workaround (unsupported)

In an emergency, you can remove the account via the SP_Config db directly.  Managed accounts are stored as persistsed objects in the objects table of the database.  They are children of the SPFarm object. 

You'll need to find the correct object - start with a LIKE query for records with 'managed-account%'.  Then look in the properties column of each result until you find the culprit.  Proeprties is a serialised SPManagedAccount, so look for the 'LastKnownUserName' that matches your missing account.

Once you have found your object, jot down it's Id.  Then check the dbo.Dependencies table for any dependencies.  If you find some - you'll have to decide what to do about them (remove via sql or find the proper way - if it exists).  Make sure you don't remove something that is actually in use though.

Once there are no dependencies, you can delete the obect from the objects table, and the managed account will no longer exist.  You may need to flush the config cache.

CAUTION:  You are insane if you do this on a production environment as anything but the ultimate last resort. This kind of process is completely unsupported by Microsoft, and frowned upon in the Sharepoint community.  Do so at your own risk.   There are some scenarios however, where it will be necessary - so make sure you test the process and outcome extensively before proceesing.

Cheers,
N
 on 2/6/2013 9:00 PM

Add Comment

Items on this list require content approval. Your submission will not appear in public views until approved by someone with proper rights. More information on content approval.

Title


Body *


captcha

Please verify the text shown in the image

Attachments


© 2004-2013 Okean Solutions
Aptillon, Inc.
Microsoft Certified Master - SharePoint 2010 & 2007
Sign In