Wednesday, August 26, 2009

Overcoming the Stupidity of Others

Here’s one for you. I spent a good twenty minutes on this.

Setting the Scene
We’ve been trying to prepare our AD forest for the deployment of Windows 2008, so of course, we’ve run the schema extensions, etc. We got to the domain prep steps and low-and-behold, /gpprep failed in 10 of our domains because some admins, in their infinite wisdom, did wild and crazy things with permissions.
So I’m having to fix the permissions 240 GPO’s in order to complete our prep work.

GPO Clunker
One domain admin, in a fit of brilliance, set DENY ACLS on some GPO’s for NT AUTHORITY\Authenticated Users. Isn’t that nice? The net effect is a clunker GPO that shows up in adsiedit.msc as a little notepad icon instead of the normal folder icon.
And I couldn’t get access to it to fix it through normal means. Fun, fun, fun.
The Fix
The real fix is to remove this joker admin from Domain Admins. However, that isn’t always practical. So all I could do was this:

1) Find the Problem: First, find the problem. Because it isn’t always a DENY for NT AUTHORYT\Authenticated Users. Sometimes other default permissions are diddled and/or removed that prevent things like replication from happening. I have another joker remove SYSTEM and Enterprise domain Controller permission, causing inconsistencies in SYSVOL, etc, because the GPO couldn’t be replicated. There are about 5 default permissions that I hate to see people diddle with, including those for Domain Admins, SYSTEM, Enterprise Domain controllers, etc.

Anyway, to find the problem, dump the ACLS using dsacls and piping to a file, for example:

dsacls “CN={12345678-1234-1234-123456789012},CN=Policies,CN=System,DC=mydom,DC=myorg,DC=top” > badgpo.txt

(Of course, you will subtitute your troublesome GPO's GUID in place of my phoney-baloney one, above.)

2) Review badgpo.txt: Review the contents of the output file to look for any DENY and/or missing ACLS that prevent you from managing the GPO.


3) Reset the ACLS: Once you figure out what’s wrong, then you’ll have to craft a dsacls to put back what is missing/wrong. In my case, where the admin had put in a DENY for NT AUTHORYT\Authenticated Users, I had to remove the DENY. All the other permissions were ok. But because DENY permissions are always evaluated first, even an enterprise admin like moi could not do squat with the GPO.

Here are the steps to fix this particular situation:
a. Log on to the PDC-emulator role holder using an account in Domain Admins
b. Run the following DSACLS (inserting your own GPO GUID info, of course):

dsacls “CN={12345678-1234-1234-123456789012},CN=Policies,CN=System,DC=mydom,DC=myorg,DC=top” /R “NT AUTHORITY\Authenticated Users”

This command will remove the permissions for Authenticated Users.

But wait! You might say, won’t you then lose the ability to mess with the GPO? No. Because I checked the DSACLS output before I did this and saw that Domain Admins still had permissions—it’s just that the permissions were unusable because of the DENY on Authenticated Users.

So much for that problem.

Oops--maybe not.

There are some things you should know about this, because the situation is still fraught with gotchas.

You may or may not know that you should never set permissions outside of the Group Policy Management console (GPMC) on group policy objects because GPOs have several components split between the NTFRS file system under SYSVOL and those maintained in the Systems container in AD. Those two sets of permissions must be kept in sync. The GPMC does that.

But wait! you might say, didn't you just set them in AD only? Yes--but I had to. And now comes the worst task. You have to go back into the GPMC, select the GPO you just mangled and select Edit. If luck favors you, the GPMC will spy the mangling and pop up a box indicating that it found different sets of permissions on the pieces in SYSVOL versus those in AD. It will ask Do you want me to correct this?

The appropriate response is: Yes. We very much want GPMC to fix this. Thank you very much.

Then, you can take any final steps necessary to ensure the permissions on the policy are correct. And if you take my advice, you will ensure all your GPOs have the following set of default permissions always left intact. It will reduce your future pain and suffering 10-fold.

Not only is this the default permission set, but I view the permissions as a failsafe set that will (hopefully) let me bludgeon my way into a GPO if I have to, after an anal admin has messed it up. Yes, there are tons of arguements about removing these permissions, but frankly, I'm not interested. These are a failsafe and the defaults.

Authenticated Users -- Read, Apply (You can remove the Apply if you want to control who/what gets the GPO via granting another security group the Apply permission. But please leave Read. This is a failsafe and for your sanity and protection.)

SYSTEM -- Read, Write, Create all child objects, Delete all child objects

Enterprise Domain Controllers -- Read

Domain Admins -- Read, Write, Create all child objects, Delete all child objects

Enterprise Admins -- Read, Write, Create all child objects, Delete all child objects

Believe it or not, I actually had one yahoo remove System and Enterprise Domain Controllers, Domain Admins and Enterprise Admins permissions. It wrecked havoc with NTFRS replication and was nearly impossible to fix. The only thing left with any permissions was his ID. All I could do was reset the password on his ID to hijack it and then go in and reset these defaults.

Bad thing to do, security wise? Yes. And it was fortunate (in one respect) that he was still with our organization. If he had been gone and his ID deleted already...well...that would have been mighty interesting.

That's why you need the default permissions--they are a failsafe. You don't want to get caught with "junk" on your domain controllers and in AD that can't replicate and causes inconsistencies in SYSVOL (among other things).

So...that's the end of this post!