Re: Mulitiple Loopback GPO's and one OU
- From: Rick K S <RickKS@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 1 Nov 2006 10:33:02 -0800
I tested what you've indicated..interesting...it reads from my first policy,
as it should, that loopback is implemented and then it ends up applying the
user policies from the higher priority policy (which the computer has no
rights to) since loopback is turned on (by the first policy.) I have
confirmed that, in fact, it is not seeing the loopback setting in the policy
in which it should not have access to machine settings (i.e. the GPO it is
"denied" on.) So, even though I don't like it, this behaviour is technically
correct. Thanks helping me understand this.
Anyway, I've more or less accepted that, due to this behaviour, we'll have
to go with different OU's for the different computers and link the distinct
loopback GPO's to the appropriate container.
With regards to your preference for "Whitelisting"...I would agree but I had
to go with the blacklisting approach because it appears that a computer
policy applies to any Domain Computer by default--that is, you do not have to
explicitly apply computer settings in a GPO via a security filter...they seem
to apply to every domain computer by default (even though I cannot see an
entry in the Security Filter/ACL for the GPO that would indicated how it
should apply.) At least with User policy, you can simply remove the
"Authenticated Users" from the ACL and just go with Whitelisting to a
particular group. I would have assumed there was would have been "Domain
Computers" (or something similar) in the ACL/Security Filter on a GPO that
said "Read and Apply", but there was no entry.
How do you change this seemingly inherent "Read and Apply" for computers so
I can go with a Whitelisting approach, just like users?
Thanks,
Rick
"Mark Heitbrink [MVP]" wrote:
Hi,.
Rick K S schrieb:
I'm interested in your thought, though, why the computer part of the
loopback policy is even read on the GPO that has an explicit Deny on it?
Because Loopback processing is activated. After that your Userobject
reads the User configuration from that "Computer GPO".
The Computer isnt allowed to read it, because of "deny", but the
User still can.
It doens´t matter how often you activate Loopbackprocessing, it´s a
singel flag, that enables that behavior. So, if Loopback is active, the
user will read the settings _from_ the Computer GPO.
But IMHO your contruct is a little bit to complex. I prefere simple
solutions, that are much easier to handle. I would work with different OUs.
Filtering by security groups combined with "deny" are exceptions, that I
try to avoid, because of easier troubleshooting.
Instead of deny, you can remove "authenticated users" and add only the
security groups, that are allowed to read and apply. (users + computers).
That should make it simpler, if you don´t like to work with 2 OUs.
I prefere "Whitelisting", only add groups, that are allowed. Why deny
something, where the object doesn´t even have a permission on?
Mark
--
Mark Heitbrink - MVP Windows Server - Group Policy
Homepage: www.gruppenrichtlinien.de - deutsch
Blog: gpupdate.spaces.live.com - english
- Follow-Ups:
- Re: Mulitiple Loopback GPO's and one OU
- From: Mark Heitbrink [MVP]
- Re: Mulitiple Loopback GPO's and one OU
- References:
- Re: Mulitiple Loopback GPO's and one OU
- From: Mark Heitbrink [MVP]
- Re: Mulitiple Loopback GPO's and one OU
- Prev by Date: Re: GPO won't apply to OU
- Next by Date: Re: Mulitiple Loopback GPO's and one OU
- Previous by thread: Re: Mulitiple Loopback GPO's and one OU
- Next by thread: Re: Mulitiple Loopback GPO's and one OU
- Index(es):
Relevant Pages
|