Ok folks, let me see if this is even possible. Got a 2008 Domain (current functional level is at 2003). There is an account that a former contracting company (before my time) created an account, that was basically meant to be a domain admin account. Over the years, this account got migrated from the NT 4.0 network, to 2003, then now to 2008. I cannot delete the account no matter what I try. ADUC gives me this: I then went to my trusty ADSIEdit to remove it. But once again, thwarted: So, is there no recourse to resolve this issue? Thanks, James

The reason you can't delete built-in accounts is that you wouldn't be able to re-create them. The SIDs of the old and new accounts wouldn't match, and the permissions and privileges of these accounts would be lost. Because of this, Windows NT doesn't let you delete built-in accounts. http://technet.microsoft.com/en-us/library/cc722455.aspx Santhosh Sivarajan | MCTS, MCSE (W2K3/W2K/NT4), MCSA (W2K3/W2K/MSG), CCNA, Network+ Houston, TX http://blogs.sivarajan.com/ http://publications.sivarajan.com/ This posting is provided "AS IS" with no warranties, and confers no rights.

Yep, makes perfect sense however, I still have several objects I need to remove. The "old" domain account carry-forward I mentioned earlier, a folder I created yesterday in that folder which is now "all of a sudden" telling me I cannot remove that folder, and a distro list that is carrying the same attributes of non deleteable. So, there has got to be some way to remove these things that are not "critical" but the system thinks they are. Thanks, James

Ok, i would look at the following first to try and detemine where the issue lies. 1) Verify the SID of the account is not any of the built-in SIDs. This can happen if someone (before you arrived) renamed the real administrator/guest/etc account to this account name. Try PSGETSID or the GETSID utilities from Microsoft. If the SID is a built-in, DO NOT DELETE, you should rename back to the original name, get rid of the duplicate account. Renaming accounts was a very common practice in NT4. 2) Check SID History for built-in SIDs. When migrating from Domain, to domain, you don't want any built-in SIDs listed here. If all reminent of the domain are gone you can safely delete. If the domain still exists you can delete only if you are willing to deal with any reprecussions. MS has a VBScript for reading the SID History of an object. Not sure about deleting, but can't be too hard. Ok, i have never attempted the following, and i do not recommend this...so use this info at your own risk. 3) If none of the SIDS from above are built-in, then the next step is to verify/change the IsCriticalSystemObject attribute set. Use ADSIEdit and browse to the object to be deleted, check the IsCriticalSystemObject attribute. If this is True, (i think you can) manually change it to false and then delete the account. Never attempted, so i'm not sure. If you can manually change, maybe someone before changed this setting on this object. Good luck.

Please paste the SID info from one of the accounts. You can use ADSI edit to get the SID info. Santhosh Sivarajan | MCTS, MCSE (W2K3/W2K/NT4), MCSA (W2K3/W2K/MSG), CCNA, Network+ Houston, TX http://blogs.sivarajan.com/ http://publications.sivarajan.com/ This posting is provided "AS IS" with no warranties, and confers no rights.

1) So here isthe SID of the account in question: S-1-5-21-1788761602-66662078-903097961-500 1b) Not sure how to determine if the SID is a built-in. 2) Not sure how you would check the SID history. 3) IsCriticalSystemObject on all the items I wish to remove are labelled as TRUE. Unfortunately, I cannot modify this attribute, get the following error: . I even went as far as hitting the security tab, making domain admin full rights, taking ownership, etc, still did not work.

For a domain SID, In general the ending value, 500 in this case, will tell you if it it well-known sid or not. Compare against this KB http://support.microsoft.com/kb/243330 Looks like someone renamed the Administrator account like i said. SID: S-1-5-21-domain-500 Name: Administrator Description: A user account for the system administrator. By default, it is the only user account that is given full control over the system.

Very nice, and very useful. That's a great article. So, here is the results of what I have found: S-1-5-21-1788761602-66662078-903097961-500 - EBanks - Original Administrator account S-1-5-21-1788761602-66662078-903097961-501 - DMCGuest - Original GUEST account So, where would we Normally see these accounts? I did a PSGetSid on the word "Administrator" to see what came up, it gave me this: S-1-5-21-1788761602-66662078-903097961-1903 which doesn't seem to match the above. Finally, the folder I inadvertantly called "Temp" under the disabled folder, I cannot delete. No SID associated to that, I get the following: Thanks again Guys. James

It was common practice for admins to rename the real Administrator account and create a fake Administrator account typically in an attempt to mislead attackers. It was also common place for people to rename the Administrator account to their user id, as what appears to have happened here. Because of well-known SIDs we can tell exactly what occured here, but not why....not that it matters anyway. I would rename the built-in accounts back to their proper names for future reference, or at least document for future reference what is what. As for the folder, you should be able to use any user account that is listed on the Owner tab, or that has Full Controll and take ownership of the folder then delete it. But that is a separate issue. Off course it could be that a file or folder has a lock preventing the deletion, in this case the easiest thing is to reboot, and stop the Server Service, then try the delete.

Thanks. Have a good weekend guys...