Group Policy

Yeah, I actually had wanted to do that in the past (diffrent account policies for OUs) and found myself in this impass...

In a way I kind of find it a good thing, however, forcing everyone on the domain to have the same strength passwords and such gives you a technical excuse for not letting directors and boss's have easier passwords!


Ammo

Ammo: See above...

[Edit]

All of which raises the question, (since I can't be bothered to go back through the entire thread),.... Are his users logging in locally or as domain users... Because then only the computer policy would apply IIRC...

[/Edit]

Err, I'm confused now, is your final stance that what I said (AND microsoft referenced) is right or do you still dispute that?

[edit]btw, I'm in no way contesting that GPs are applied hierachically, inherited, and etc.; what I'm saying is that the account polices are special and are not respected by windows the way you might expect, just like I said and referenced in post #18.
[/edit]


Ammo

Ammo:

This is one of those situations where I need to reread the _whole_ thread... assimilate the original question, the responses and then the "truth".... This isn't going to happen in short time... I have a meeting tomorrow where I have to "sell" something so my thoughts are on that.... But this whole issue is worth revisiting..... If only my Alzheimer's will let me go for a day or two... :eek:

Someone.... Anyone... Keep posting just so that I keep getting the reminders that I need to respond to this thread..... Please..... :) It's an important issue and needs to be put in "English" for all to understand.....

Ok, you are both probably right, the exception to Tigers statement is like Ammo says, at least through the testings I've now done, it doesn't apply to the Account Policies.

A few examples:

1. Domain GP - no OU GP = Domain GP wins
2. Domain GP - conflicting OU GP = OU GP wins
3. Domain GP (Account Policy) - no OU GP = Domain GP (Account Policy) wins
4. Domain GP (Account Policy) - conflicting OU GP = Domain GP (Account Policy) wins!!
5. Domain GP (Account Policy) - conflicting OU GP, with Block Inheritance = Domain GP STILL wins!!

Doesn't make much sense, but that seems to be how it works.. !

Found a pretty good link that explains the "Blocking" and "Enforcing" as well:

http://www.microsoft.com/technet/pro...542d06b2c.mspx

Quote:

---

This order means that the local GPO is processed first, and GPOs that are linked to the organizational unit of which the computer or user is a direct member are processed last, which overwrites settings in the earlier GPOs if there are conflicts. (If there are no conflicts, then the earlier and later settings are merely aggregated.)

---

Source

coupled with:-

Quote:

---

GPO processing is based on a last writer wins model, and GPOs that are processed later have precedence over GPOs that are processed sooner. Group Policy objects are processed according to the following order:

1. The local Group Policy object (LPGO) is applied.

2. GPOs linked to sites.

3. GPOs linked to domains

4. GPOs linked to organizational units. In the case of nested organizational units, GPOs associated with parent organizational units are processed prior to GPOs associated with child organizational units.

---

Source

Both of which being preceded with language similar to, and assuming that by using the term "Account policies" we are talking about "User Policies":-

Quote:

---

To apply the settings of a Group Policy object (GPO) to the users and computers of a domain, site, or organizational unit

---

Now, to me, this clearly implies that the final policy set on a computer or user is that of the last OU in the tree of OU's which are below the domain in the tree by default. This means to me that if the last OU in the tree says that the user, (account(?)), can't run Word but the domain policy says he can then the OU policy overwrites the domain policy's setting in the local security policy, (because that's the only policy there really is and the domain etc. policies simply "adjust" that policy), then the OU "wins" because it is set later and therefore alters the previous setting of the domain policy.

Now, I need to explain that I _believe_ that the default link order is as written in the MS documents, thus it goes Site - Domain - OU - nested OU. I could be wrong but I don't see why they would write the docs in one way for this and then have the default order be different... But then it wouldn't be the first time on complex issues MS' documentation either is wrong or they have multiple documents that contradict each other.... :rolleyes:

To avoid conflicts and problems the traditional advice has always been that you apply the least restrictive policy at the domain level, (this assumes that you forget about local policies and site policies though in certain infrastructures site policies may be relevant but that setting the local policy is always pretty irrelevant in a domain environment). This is where you set things like a lockout policy for example... You want all users, anywhere in the domain, to be locked out for an hour if they fail login three times.... Then at the basic OU level you choose that no-one in OU A can run the command prompt but users in OU B can so in OU A you set the policy that no user, (account(?)), in the OU can run cmd.exe but in OU B you don't even set the policy, (leave it disabled). In the case of OU B the local policy "wins" with regard to running cmd.exe because neither the domain policy nor the OU policy set the policy. However, in OU A, the local policy "loses" because, even though the domain policy did not overwrite the policy with a "deny cmd.exe" policy the OU policy did. In a situation where the domain policy states that cmd.exe is blocked and the OU policy is disabled then the domain policy wins because the OU policy did not overwrite the local policy after the domain policy did - remember, there's only one policy. But - if the domain policy said that cmd.exe is blocked and the OU policy says that the policy is enabled, (this might not be a great example but run with it...), and denies no executables then the OU policy "wins".... (But I think that this is where the issue is based... Does an "enabled" but with no parameters set overide a parameter that has already been set? ie: if I say at the domain level that cmd.exe is denied but at the OU level I change the setting from "not set" to enabled but put no parameters in there do I overwrite the change in policy that the domain policy previously set?.... Dunno....)

This is all very complex and can be affected very subtlely if the policies aren't in a logical and "increasing" fashion from the domain downwards. The conventional advice was given because it was difficult to determine and comprehend the accumlating policies, (and where they were set from), set in a domain environment easily so the advice was given to try to simplify the management of a domain for the admin.

Ammo et al... I'm not arguing here... I'm trying to find the "truth". I think when the combined minds and talents here do we should summarize the whole thing into "common" language so that it can benefit all.....

Thoughts, comments, expertise are gratefully accepted.....

Ok, I think I see what's going on here:

When SawPer and I are refering to "Account Policies", we are refering to the policies (in gpedit.msc) under "computer configuration | Windows Settings | Security Settings | Account Policies" under which are defined the "password policy", "account lockout policy" and such.

I believe that you took it to mean the "User Configuration" (as opposed to the "Computer Configuration") section of policies.

Did I get you right?


Ammo

Ahhhh... doncha just love terminology.... and how, if you aren't accurate with it you can waste a whole lot of time.... :eek:

I got on the wrong track about 200 posts ago in the thread thinking we were discussing "user account policies" , akin to "computer account policies", in a domain rather than what the entire rest of the world has been discussing. Apologies for being a dolt.... :o

But it made me think and revisit some things that might have been overdue.... Thanks all....

Quote:

---

Originally posted here by ammo
Ok, I think I see what's going on here:

When SawPer and I are refering to "Account Policies", we are refering to the policies (in gpedit.msc) under "computer configuration | Windows Settings | Security Settings | Account Policies" under which are defined the "password policy", "account lockout policy" and such.

I believe that you took it to mean the "User Configuration" (as opposed to the "Computer Configuration") section of policies.

Did I get you right?


Ammo

---

Yepp, heh!!
It is really confusing with the "Account Policies" settings only being effective from the Domain level. I wonder if you don't set any "Account Policies" settings at all on the Domain level, if you then can set them on the OU level??? That might be a good workaround to be able to set different settings for different users?!? :)

Or maybe you can ONLY set the "Account Policies" on the Domain level period??

Don't know if I wanna test that on my network.. heh.. ?! Anyone got a lab to test this? :)

Well, gald we finally all cleared things up!

Quote:

---

Or maybe you can ONLY set the "Account Policies" on the Domain level period??

---

AFAIK the latter is correct.


Ammo