Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1880
  • Last Modified:

Cannot remove an account from an SBS

Using Windows SBS 2011...
I have a user that was a former administrator on the network.  They have since left, and I have not been able to delete the account from the Standard or Advanced Console.  The process starts, and asks to remove folders and mailbox, but then I get an error saying that "Access is Denied".  I was able to change the users status to a Standard User, and was also able to Inactivate the account.  But I cannot delete it.   I'm guessing that something is holding onto it somewhere, but I have no idea where to go look.  I'm logged in with the main domain administration account.
0
Firemedic41
Asked:
Firemedic41
  • 6
  • 4
  • 2
  • +3
2 Solutions
 
MutogiCommented:
Have you tried the Local Adiminstrator account?
0
 
Firemedic41Author Commented:
So we thought about this, but can't seem to find a local account at all.  If we try to activate the User Manager snap-in, we get the message that the SBS is the Domain Controller and doesn't allow local accounts.
0
 
MutogiCommented:
ouch this one is really deep now, hope another expert can help....Sorry.
0
 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

 
Firemedic41Author Commented:
Further Update:
Tried to delete the user from Active Directory with the Domain Administrator account, and got this message:
"You do not have sufficient credentials to delete Android$androidc353617071, or this object is protected from accidental deletion."
0
 
Larry Struckmeyer MVPCommented:
Hello:

Try this:   In the Group Policy MSC, click view > advanced features and go to the user's properties > object tab and make sure 'protect from accidental deletion is unchecked'.
 
Then move the user to that OU and try deletion again.
 
If that does not work, it may be that the object's permissions are messed up. To correct them, right click on the user object and go to properties > security > advanced tab  and place a checkmark by Include inheritable permissions...
 
Click OK and you should be able to delete the user object.
0
 
Davis McCarnOwnerCommented:
Do you have any reason to believe the server was infected at some point and/or Windows was reinstalled?
0
 
CoralonCommented:
I'd pull out ADSIedit and start looking at the permissions on the account.  He likely changed the permissions on his account object so that it cannot be deleted.  

Coralon
0
 
David Johnson, CD, MVPOwnerCommented:
actually protect from accidental deletion is something that you should use liberally and is a best practice. it requires a two step process to delete an account.
0
 
Firemedic41Author Commented:
@fl_flyfishing - Thanks for this, but it didn't work.  I had also seen a step-by-step guide with these same instructions.  Accidental deletion wasn't checked, and the inheritable permissions was checked.  I did place a check in there for accidental deletion, applied it, and then unchecked an applied it.  But that didn't change anything.

@DavisMcCarn - No I don't think that's possible.  We're a very small Fire Department and something like that wouldn't have gone unnoticed.

@Coralon - I've never used ADSIEdit, and he wouldn't have been able to really change his properties like that himself.  he never touched the server, he was just given Domain Admin privileges to have the ability to add users and computers to the Domain by following a given set of instructions.

So, still Access Denied.  :(
0
 
CoralonCommented:
It is still most likely a permissions issue on the object itself.

Assuming you have the AD tools loaded, just run ADSIEdit.msc.  From there, you will be able to view the permissions pretty easily.  

Look for an Everyone:Deny permission (that is the 'prevent accidental deletion' that gets added with the checkbox).  

Coralon
0
 
Firemedic41Author Commented:
Ok...so I'm apparently blind.  I do not see an Everyone group.

Here's where I'm at, and I apologize for the apparent need for handholding.  I'm a firefighter/paramedic first, CCNA second, and never a SBS Admin.  ;-)

I went into ADSI edit, and connected.  
I see OU-MyBusiness > OU=Users > OU=SBSUSers

I then found the problem user and right-clicked him, selected Properties, chose Security.  UNder Everyone...there are no Deny checkboxes.  I also don't see "prevent accidental deletion" here.  Moving on, I  then clicked on the Advanced button on the Security tab.  In the Permissions tab, there are no DENY statements.  Again though, I don't see anything about preventing accidental deletion here either.

I might be in the wrong place.  I don't know.  Sorry!
0
 
CoralonCommented:
You're in the right spot.  :-)

Can you delete him from inside ADSIedit?

If you don't mind, can you attach a screenshot (or multiples if needed) to show the permissions?  (The Advanced view will give more detail that would be usable).

Coralon
0
 
Firemedic41Author Commented:
So...
This is kind of interesting!  I did as you asked, and finished taking 13 screenshots before I attempted to delete the user.

I then attempted to delete him in ADSI and got this error message:
problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

So then I looked this up and began sifting through a myriad of responses at : http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/6331f602-4a21-43cb-af71-b5b1c4fcb140/ until I found this:

"I just thought I'd come back to this one as many people have this same problem.  We had this issue for a number of our IT staff and it took a bit before I realized that it was a permissions issue.  After fixing the permissions (turn on inheritance) the moves went fine, but the issue was why was the permissions set to not-inherit.  Secondly, I noticed that the permissions reset BACK to not-inherited, and where wrong again.  What the....?

After a bit of digging, I realized that all these problematic mailboxes were either Domain Admins or Backup Operators.  If you know anything about AdminSDHolder, then you know exactly what the problem is.

Active Directory has a built in feature that manages ACLs for protected accounts.  By being a member of a protected group, the AD user object gets it's AdminCount property set to "1".  If they do get changed, they will automatically be reset every hour.  A background process runs every hour (unless the frequency has been changed) to reset the permissions on objects with AdminCount=1 to match that of the AdminSDHolder AD object.  The distinguished name of the AdminSDHolder object is "CN=AdminSDHolder,CN=System,DC=yourdomain,DC=com".

What's really stupid is; if you remove a user object from a protected group, their AdminCount property does NOT get changed back.  You, as an AD admin, will have to modify it manually and turn inheritance back on.

If you have an really old AD (ours has gone through many upgrades since NT 3.51), the permissions on AdminSDHolder, may not match your current requirements (i.e. Exchange 2010 permissions).

If you want to see who has AdminCount turned on runs this query from the command line

dsquery * domainroot -filter "(&(objectCategory=User)(adminCount=1))" -limit 0

Hope this is usefull.  Good luck."

I knew I had seen the Admin Count attribute set to "1" on his account in ADSIEdit.  So, I edited that attribute, and then simply "cleared" the entry.  The attribute changed to "not set", and I quickly attempted to delete him again in ADSI before something could flip it back.

Voila!  OU deleted!

Thanks for the help, and staying with me!
0
 
CoralonCommented:
You're welcome.  I don't however see the points awarded?  If a moderator would please check :-)

Thanks!

Coralon
0
 
Firemedic41Author Commented:
Thanks to all the Experts who chimed in to help, and especially to Coralon for hung in there the whole time!
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 6
  • 4
  • 2
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now