?
Solved

Cannot remove an account from an SBS

Posted on 2013-06-05
17
Medium Priority
?
1,686 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 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
Threat Trends for MSPs to Watch

See the findings.
Despite its humble beginnings, phishing has come a long way since those first crudely constructed emails. Today, phishing sites can appear and disappear in the length of a coffee break, and it takes more than a little know-how to keep your clients secure.

 

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 22

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 43

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 25

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 82

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 25

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 25

Accepted Solution

by:
Coralon earned 2000 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 25

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

Featured Post

When ransomware hits your clients, what do you do?

MSPs: Endpoint security isn’t enough to prevent ransomware.
As the impact and severity of crypto ransomware attacks has grown, Webroot has fought back, not just by building a next-gen endpoint solution capable of preventing ransomware attacks but also by being a thought leader.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Recently, Microsoft released a best-practice guide for securing Active Directory. It's a whopping 300+ pages long. Those of us tasked with securing our company’s databases and systems would, ideally, have time to devote to learning the ins and outs…
Let's recap what we learned from yesterday's Skyport Systems webinar.
This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…
This Micro Tutorial hows how you can integrate  Mac OSX to a Windows Active Directory Domain. Apple has made it easy to allow users to bind their macs to a windows domain with relative ease. The following video show how to bind OSX Mavericks to …
Suggested Courses

765 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