2

I have a large-ish AD setup, where one of the already fired admins, for reasons unknown deleted the subject group.

Been googling for a while, but besides explanations what the group is for and warnings not to delete it I couldn't find anything.

The SID is known, so I wonder if I create a new group with the same name and SID, will that be enough to un-break the setup, or could the group deletion cause AD schema wreckage?

A set of steps on fixing this (besides finding the genius who did it and causing severe injuries) is more than welcome

Thanks

2
  • 1
    Is the AD restore bin an option?
    – Rob Moir
    Sep 22, 2014 at 16:04
  • The change is over 180 days old
    – dyasny
    Sep 22, 2014 at 19:21

2 Answers 2

8

You can't delete the 'NT Authority\Authenticated Users' (SID S-1-5-11) group.

You also cannot view this group in AD Users and Computers, which would explain why you can't see it using that tool.

It's not a "real" security group the way that "DOMAIN\Domain Admins" is, for instance. The membership of "Authenticated Users" is dynamically generated and represents everyone who has authenticated to do the domain.

Edit: Actually you can view it as a Foreign Security Principal in the ForeignSecurityPricipals container. It was wrong of me to bluntly state that you just can't see it in ADUC. But keep in mind that this FSP is not the actual object itself. You can even delete that FSP too... I just did so in my lab to see what would happen. But deleting a FSP is not the same as deleting the object it represents. You can still resolve the SID to name, you still get NT AUTHORITY\Authenticated Users in your token when you log on to a server (whoami /groups,) and you can still assign the Authenticated Users group to ACLs. All computers understand that well-known SID. Nothing seems to be breaking in my test domain...

I was able to recreate the Foreign Security Principal by adding it to a group. (I added it to the "Users" group for instance.) The act of referencing it caused the Directory Services Engine to automatically recreate the FSP in the ForeignSecurityPrincipals container where it belongs.

I realize that this probably no longer has anything to do with your actual problem - I'm off in the weeds now - but I thought this was neat. Here is me in my domain in which I have deleted the "Authenticated Users" foreign security principal, and rebooted both my DCs. I am still able to translate the SID S-1-5-11 even though the FSP is long gone:

Translate SID

(Then I recreated the FSP by adding it to a group as mentioned above.)

4
  • you are correct, I've tried to assign a GPO to auth users and that worked. Could have sworn I've seen the group in ADUC before... I'll close this one off, formulate a better question. Thanks!
    – dyasny
    Sep 22, 2014 at 19:26
  • 1
    @dyasny I see "NT Authority\Authenticated Users" in dsa.msc, with "Advanced Features" checked, under the Foreign Security Principals container.
    – jscott
    Sep 23, 2014 at 0:40
  • 1
    @jscott Edited my post for clarification... you rabble-rouser.
    – Ryan Ries
    Sep 23, 2014 at 3:36
  • Thanks guys, the new guy who replaced the previous one (who will end up with all his limbs after all) raised an alarm, and it's my fault for not checking things thoroughly myself before coming here, guess I'm not that much of a MS tech connoisseur
    – dyasny
    Sep 23, 2014 at 13:47
0

I will post this as an answer, because it's the standard way of doing things. It is not the fix (and I hope someone does post a good technical answer, and they should get the checkmark), but it is a guaranteed way to get the fix and is definitely something that future readers should know is an option.

Open a ticket with Microsoft PSS. It will be worth the $125 or so.

/Edit - Ryan makes a good point, that it's probably not deleted. You should describe more-fully the problems you're seeing and what troubleshooting that you have done so far.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .