I am not a GPO expert nor fan, I could be wrong with things here. If I am, be sure to comment and correct me. I do know for a fact however that the steps outlined will result in being able to use local machine policies while the machine is in a domain; I tested it yet again this evening just to verify the exact messages and screens that are displayed. 🙂
Â
When a machine is in a domain, there is a specific order in which you get your policies, I am not going to outline them here because it is well documented but the summary is that you will get your local machine policy info from GPO settings defined in the domain (or on the site). Anything defined in the domain based GPOs will override anything you have configured locally.
The usual way around this is to beg the Domain Admins to give you a new OU level GPO for you to configure things that you want or to undefine in the domain policies the things you want to configure locally[1]. Normally Domain Admins will tell you to piss off for either. At least they should because Domain Admins shouldn’t be running around making AD HOC changes just because someone feels they need it[2]. The Domain Admins job is to keep the environment running well for everyone and NOT to make sure every individual person gets everything their heart desires… If those two things work out together then that is great, but usually that is not the case by a long shot… Policies in particular should be extremely locked down in how they are changed because while they can really help out they can also cause serious evils and companies that play fast and lose with GPOs tend to experience some level of pain from it.
So, getting back on track, Â it would be really nice if you could override domain policy with local machine policy. This is becoming even more requested with ADAM. People want to set up their ADAM instances to have policies that are different from the domain policy and they often have good reasons for it, but their only supported options for a machine in the domain is either to follow the domain defined policies or not have any policy at all by disabling the password policy in ADAM with ADAMDisablePasswordPolicies=1 in the msDS-Other-Settings attribute of the Directory Service object. This is because ADAM doesn’t support its own policies. It really should, but that isn’t how it was implemented.
There actually is a way to get the local security policy settings to be applied to a machine in a domain. A couple of years ago I found this feature and have not shared it with many folks but we are all friends here right???
So first off, you need to set up a policy the way you want it applied locally. You do this with the Security Configuration and Analysis and Security Templates snap-ins in the MMC.
- Open MMC – type mmc at the command prompt
- Click File | Add/Remove Snap-In
- Click Add
- Click Security Configuration and Analysis | Add
- Click Security Templates | Add
- Click Close | Ok
- Expand Security Templates and C:\Windows\security\templates
- Right Click in the right pane and select New Template
- Enter a name for the template that makes sense to you
- Expand the policy by double clicking it or expanding it in the left pane.
- Walk through all of the policy settings and configure what you would like to configure. Keep in mind that this policy will completely override any policy coming down from the domain so make sure it is not stupid and leaving gaping holes or other security problems.
- Once you have configure your policy, right click it in the left pane and select Save
Ok so now you have created your policy, you want to compare it to what is in place to make sure you didn’t miss anything stellarly stupid.
- Right click on Security Configuration and Analysis
- Select Open Database
- Enter a name for your database, I usually do something like joecurrent or something along those lines, but it is up to you. Â
- Select the template you previously created when prompted
- Right click on Security Configuration and Analysis
- Select Analyze Computer Now
- Click Ok when prompted for the error log path
- Once the analysis is completed, step through it and look for the deltas between what you want and what is currently in place. Make sure you didn’t forget anything silly. If you did, go back and modify the template.
Now if you have played at all, none of that above should be much of a surprise to you. I am expecting more people than I would prefer will have had no idea about any of the Security Configuration stuff, at least that has been my experience when mentioning those snap-ins to folks in the past. But being familiar with it you know that you may set this but then domain policy swings back through and “fixes” it again. So where is the trick you ask??
On the OU that the computer is in you want to modify one attribute; the gPLink attribute. This is the attribute that specifies what policies are applied at this OU level. You want to put some value into the attribute that is less than valid. Say like “[LDAP://cn=blah;0]” (without the quotes) or if you think that your DA’s are looking at the raw attributes of objects you might want something more like [LDAP://CN={31B2F340-1234-5611-8711-00C04FB984F9},CN=Policies,CN=System,DC=domain,DC=;0] which looks like a good valid GPO setting but it isn’t (note the missing value in the last domain component). The value must be invalid, not just a DN of an object that doesn’t exist. From what I have seen in most environments, no one is going to catch the first one let alone the second. Very few DAs who give out too many rights actually doublecheck what is being done unless something comes out and bites them on the ass from whatever was done and then they bumble around looking for the problem and then try to “fix it” and wonder how it could have happened for 10 or so minutes and then promptly forget about it.
Once you have made this change, you will find that your local machine event log (as well as the event log of every machine in the OU)Â starts getting Userenv 1030 Events in the application log. This tells you the feature is working and the policy processing is breaking so the domain policy is not being applied.
Now go back to the MMC and
- Right click on Security Configuration and Analysis
- Click Configure Computer Now
Â
Congratulations, you are now the master of your local machine policy. There may be other mechanisms in which you can block domain policy from applying to your machine that will accomplish the same thing but you won’t hear them from me. Just keep in mind that while the MSFT security model remains the way it currently is, anyone who has physical access to a machine owns the machine and can make pretty much any changes they want to it. If you have administrative rights on your machine no one is even trying to slow you down from doing what you want to do.
Obviously nothing stated here in this blog entry is supported in any way shape nor form by Microsoft or anyone. In fact, depending on how far this entry reaches inside of Microsoft the feature may be removed in a future QFE, SPÂ or OS Version.
  joe
Â
[1] Of course you can’t do that for domain password policy.
[2] Even for you Mr. C*O or Mr. Director or other Mr. Boss (and when I say Mr. I mean Mr., Mrs., Miss, etc); your ideas are just as bad as other non-technical people, possibly even worse.
Â
Joe, but doesn’t this only work if you have permission to modify properties in that AD OU? If so, wouldn’t that mean you are already sometype of admin? And if you were a an admin with this right, you most likely have the right to just put yourself in a new OU anyway right?
I was just thinking you were saying there was a way for someone without access to AD to override AD policy, but according to my understanding of this post, you do have to have access to AD to pull this off?
OK, maybe ignore last post, I think I misread something? Do you mean make a change to the attribute in the error log? Anyway, I can’t try this right now as I have to run, but you can tell me if I’m a bonehead, without trying myself, this post is hard to understand. As you say, most people don’t have much experience with this Security Configuration Analysis Tool, I am one of those people.
Who said you can’t have your cake and eat it too?
Create an OU and put a policy on it, but don’t make it the DAs responsibility…delegate it out. Why do you have to hack when you have delegation?
Jeremiah:
It assumes you have the ability to modify a single attribute on an OU, basically setting the gPLink attribute. Putting yourself in a new OU doesn’t help you if that OU doesn’t have a policy set the way you want/need it. Having rights to make changes on an OU does nothing for your ability to add/modify GPOs. You have to get that right from the DAs or someone else who is handling that aspect of the environment. I am not saying it isn’t possible to override AD Policy without having any rights in AD. In fact I imply it is possible, but I am not going to post directions on how to do it. That is what the last part of the post is about. Why??? Because I myself happen to be an AD Admin type person and while I will help you figure out how to get around certain things, I will only fess up to things that I know I can easily find if people in my environments try to do it to me. 🙂
Also, I am not quite sure why this post is hard to understand…
~Eric:
Say that the DA’s or some other policy maker have decided that your organization of hundreds of thousands of users and machines isn’t going to produce ad hoc policies and in fact there are say 20 defined policies encompassing users and computers and that is all there will be? Or say someone higher up in the OU structure has set their GPO for no override.
The GPO system from what I see sucks for one off configuration and MSFT doesn’t allow for it to be handled in any way but hacking. I should be able to set a policy that says, allow the local machine policy to be the overriding factor but if they don’t have anything defined, use these basic settings. Another great addition would be the ability to say, here are the minimums, if the local machine wants to set the password or lockout policy to be tighter, that is allowed as well or even allow me to specify by section or setting which ones can be overridden by local policy. These are all hard except for just letting local machines override at will and I think that setting scares MSFT a little from a security standpoint because most admins don’t understand GPOs already.
You said:
“I should be able to set a policy that says, allow the local machine policy to be the overriding factor but if they don’t have anything defined, use these basic settings”
But you also said:
“Or say someone higher up in the OU structure has set their GPO for no override”
With those two points at play, I don’t think you can ever be happy.
There is always the “I have more power, override what you say” switch. If someone plays it, your ask for a policy that allows local policy to win can always be overriden (spelling?), and so we are deadlocked. Now, if you want to get rid of no override in it’s entirety, that’s an entirely different conversation.
Jeremiah,
Check out the NSA Guide for security configuration toolset
http://www.nsa.gov/snac/os/win2k/w2k_group_policy_toolset.pdf
Chapter 10 has a nice overview of the security config and analysis tool
The attribute Joe is talking about can be modified several ways but ADSI edit would be an easy way to do it.
If you try this try it do in your lab like Joe did. If you did this in production you would “break” every object in that OU and that would obviously be a bad thing.
This is a neat trick Joe; I’m going to try it this weekend in my lab. Some of the old tattooed polices will still linger around.
I don’t know if I’ll ever be in a position to stand up to Mr. CIO or Mr. Director or in my case General, Admiral, or Secretary. I’m all for having a secure & stable network but I’m also a big fan of paying my mortgage.
“Break” would be defined as not getting domain policy. That may or may not be good from the viewpoint of the server admins and probably bad from the standpoint of the Domain Admins if they absolutely want all machines following their policy.
Anytime someone says something that you don’t feel is right, regardless of who, speak up. You don’t have to say I am going to quit if you do this, but at least point out that you think something is not right.
~Eric: I wasn’t saying that someone higher up saying these can’t be overridden was a good thing. I was giving a reason why this is handy for defeating that. Having the ability to say something can’t be overridden is good, but maybe it should be more granular and not require you to set up multiple policies if you want certain settings to not be overridden and some you don’t care about being overridden. Also the ability to set things at the local level should be allowed as well.
I am not getting your point.
I don’t disagree that per-setting no override would be nice. But that aside, this is not making sense to me:
“Also the ability to set things at the local level should be allowed as well.”
Are you saying that no override should be at play here or not? That sentence tells me that you want a local override that overrides no override. Am I misunderstanding?
~Eric:
I want both. 🙂
As a Domain Admin I want the ability to say all machines will set this specific setting. As a server admin I want to be able to say, screw that, the DA’s are on crack. I want to set this specific value.
However when it gets down do it, the no override should play to the DAs. So doing that at the setting level is probably a better implementation. But also want another setting. The use the lower level (even local) setting unless it isn’t defined then use this setting.
I thought, you will be discussing, less kludgy… “loopback policy” replace mode thingy…
even though its not absolute best.. its still allows lot of local control depending on how paranoid DA is.
But, this is also fine.. 🙂
Now should I check this box for SPAM too 😉
Le’ts play RaymondC style “What ifâ€â€¦..
If we go down this path, we end up with an escalating DCR path…
DA says “I want no override†– in the product today
Server op says “I want ignore no override” – so we DCR this
DA says “I want ‘override ignore no override'”
Etc.
There was a conscious decision made….should DAs (or anyone with higher level privs for that matter) be able to override a server operation if they so choose? The answer they made was yes, but not by default.
If you have a setting that a higher-level power wants to change, they can override you, and this makes sense.
I would file a DCR for per-policy no-override if you think it would help. It would perhaps reduce the # of GPOs you need to create to effectively get the same thing done, but I’m not sure it’s good design w/o thinking about it for a while, which I haven’t yet. 🙂
Thx.
[edited by joe because ~Eric had some issues with his post with greater than and less than symbols]
You might want to take a close look at ACL of “C:\WINDOWS\security\templates\policies”.
Does not block everything, but I am almost sure will do for local password policy of the box.