Solved

Cannot remove an account from an SBS

Posted on 2013-06-05
17
1,326 Views
Last Modified: 2013-06-17
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
Comment
Question by:Firemedic41
  • 6
  • 4
  • 2
  • +3
17 Comments
 
LVL 3

Expert Comment

by:Mutogi
ID: 39223353
Have you tried the Local Adiminstrator account?
0
 

Author Comment

by:Firemedic41
ID: 39223558
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
 
LVL 3

Expert Comment

by:Mutogi
ID: 39223594
ouch this one is really deep now, hope another expert can help....Sorry.
0
 

Author Comment

by:Firemedic41
ID: 39223625
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
 
LVL 21

Expert Comment

by:Larry Struckmeyer MVP
ID: 39231802
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
 
LVL 42

Expert Comment

by:Davis McCarn
ID: 39231843
Do you have any reason to believe the server was infected at some point and/or Windows was reinstalled?
0
 
LVL 23

Expert Comment

by:Coralon
ID: 39231950
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
 
LVL 78

Expert Comment

by:David Johnson, CD, MVP
ID: 39232307
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
 

Author Comment

by:Firemedic41
ID: 39238049
@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
 
LVL 23

Expert Comment

by:Coralon
ID: 39239380
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
 

Author Comment

by:Firemedic41
ID: 39239518
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
 
LVL 23

Accepted Solution

by:
Coralon earned 500 total points
ID: 39239611
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
 

Assisted Solution

by:Firemedic41
Firemedic41 earned 0 total points
ID: 39242082
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
 
LVL 23

Expert Comment

by:Coralon
ID: 39242723
You're welcome.  I don't however see the points awarded?  If a moderator would please check :-)

Thanks!

Coralon
0
 

Author Closing Comment

by:Firemedic41
ID: 39252587
Thanks to all the Experts who chimed in to help, and especially to Coralon for hung in there the whole time!
0

Join & Write a Comment

Article by: btan
The intent is not to repeat what many has know about Ransomware but more to join its dots of what is it, who are the victims, why it exists, when and how we respond on infection. Lastly, sum up in a glance to share such information with more to help…
Resolve DNS query failed errors for Exchange
This tutorial will walk an individual through the process of configuring their Windows Server 2012 domain controller to synchronize its time with a trusted, external resource. Use Google, Bing, or other preferred search engine to locate trusted NTP …
With the advent of Windows 10, Microsoft is pushing a Get Windows 10 icon into the notification area (system tray) of qualifying computers. There are many reasons for wanting to remove this icon. This two-part Experts Exchange video Micro Tutorial s…

744 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

9 Experts available now in Live!

Get 1:1 Help Now