Re: Mulitiple Loopback GPO's and one OU



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

.



Relevant Pages

  • Re: Applying user object policy (filtering based on computer location)
    ... should have the GPO applied via loopback when logging into ... the computers in NY Desktops OU, ... I have a OU called "NY DESKTOPS" - I created a new policy and enabled Loopback processing mode. ...
    (microsoft.public.win2000.group_policy)
  • Re: Applying user object policy (filtering based on computer location)
    ... leave "authenticated users" with read and apply group policy permissions and set deny on NY employees. ... should have the GPO applied via loopback when logging into ...
    (microsoft.public.win2000.group_policy)
  • Re: Hide TS drives from users, but not Administrators.
    ... I took Jeff's suggestion to create a loopback gpo with nothing else in it. ... then created another gpo to deny all users from the servers local drives. ... I want to deny the Domain Admins from applying this policy so I continued ...
    (microsoft.public.windows.terminal_services)
  • Re: Controlling User Policy via Computer account
    ... > (1 and 2 are adding grants of read/apply in the GPO security) ... > 4 place the machines in the OU to which this GPO is linked ... Even with the Loopback policy, ...
    (microsoft.public.windows.group_policy)
  • Re: Loopback Processing and Deny Apply in ACL
    ... To clarify how policy loopback works: ... The computer configuration settings from this list are applied to the ... When the user logs in, different behaviour occurs according to the policy ...
    (microsoft.public.win2000.group_policy)