Loopback Processing and Deny Apply in ACL

  • Thread starter Thread starter Brian Higgins
  • Start date Start date
B

Brian Higgins

I have a 2003 terminal server on a 2003 domain, I have configured my GPO
for the terminal server (which is in it's own OU, and enabled loopback
processing in replace mode. everything works exactly as I would like, for
the users, but there is a software developer that needs full, un-restricted
access (he does not get domain wide, just local, admin access) to this
server to maintain and update some custom software running on the server.

I have followed the steps in Q315675 and applied the same principal of
setting the deny apply gpo setting in the acl to the user account of this
developer (actually a security group that he is a member of), I waited for
plenty of time for the group membership and the ACL to propigate, I then ran
gpupdate /force on both the machine I was running the RSOP (planning mode)
and on the terminal server (for when running RSOP in logging mode) and both
RSOP datasets show that the user gpo is still applying to the user who is
listed in the ACL with a deny entry in the apply setting.

What am I missing in regards to allowing this (and any other user in the
future) the ability to logon to the terminal server without getting locked
down by my terminal restrictions gpo?

Any help here would be apprecieated.

Thanks.
- Brian
 
Do you mean that the policy is still being actively applied, or that the
policy setting has not been reversed? Most policies are Not Configured by
default. If you Apply the policy to a user (with the loopback) then Deny it,
you do not end up back at the default setting, you stay on the last one that
was configured. Try deleting the user's terminal services profile and
recreating it.
We Deny the loopback policy to the people administering the terminal
servers, and it works fine.
Anthony
 
Hi

To clarify how policy loopback works:

1. When the computer boots, the list of GPO's for the computer is gathered
based on it's location in the Active Directory. This is it's SOM or Scope
of Management. The list includes GPO's linked to OU's at each level in the
heirarchy from the OU in which the computer resides all the way up to the
domain.

2. The computer configuration settings from this list are applied to the
computer provided the computer account has permissions to the GPO's.

3. When the user logs in, different behaviour occurs according to the policy
loopback settings:

A. Loopback off - the SOM for the user is calculated and then user
configuration settings applied according to user permissions. The location
of the user account in the AD decides entirely which user configuration
settings are applied.

B. Loopback merge mode - the SOM for the user is calculated as in A. The
user configuration settings from this SOM are applied but at a lower
precedence to the user configuration settings in the computer SOM. Once
again, user permissions allow or prevent application of these setting
regardless of whether they came from the user or computer SOM.

C. Loopback replace mode - the SOM for the user is not considered. The user
configuration settings are applied from the GPO's in the computer SOM
provided they have user permissions.

+++++++++++++

So in your case, you should find that the user who has been denied Read and
Apply for this policy, goes unrestricted. As Anthony suggests, get the
permissions set correctly first and then start with a clean profile and
logon. If you're still having problems, log in as that user and gather a

gpresult /z

This will tell you where policy settings are applying from and what's being
filtered out by security.

Kind regards
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: (e-mail address removed)

Please note you'll need to strip ".online" from my email address to email
me; I'll post a response back to the group.

This posting is provided "AS IS" with no warranties, and confers no rights.
 
The actual group policy is being applied to the user logon, even when I am
setting a deny apply setting in the acl, which mode of AD are you running in
where it is working? is is not just a matter of not configuring a otherwise
applied policy...
 
is it possible that the RSOP dataset would show something different in
regards to the GPO's getting applied (planning mode) then what will actually
get applied at logon in regards to loopback policy's and setting the deny
entry in the ACL?


Mark Renoden said:
Hi

To clarify how policy loopback works:

1. When the computer boots, the list of GPO's for the computer is gathered
based on it's location in the Active Directory. This is it's SOM or Scope
of Management. The list includes GPO's linked to OU's at each level in
the heirarchy from the OU in which the computer resides all the way up to
the domain.

2. The computer configuration settings from this list are applied to the
computer provided the computer account has permissions to the GPO's.

3. When the user logs in, different behaviour occurs according to the
policy loopback settings:

A. Loopback off - the SOM for the user is calculated and then user
configuration settings applied according to user permissions. The
location of the user account in the AD decides entirely which user
configuration settings are applied.

B. Loopback merge mode - the SOM for the user is calculated as in A. The
user configuration settings from this SOM are applied but at a lower
precedence to the user configuration settings in the computer SOM. Once
again, user permissions allow or prevent application of these setting
regardless of whether they came from the user or computer SOM.

C. Loopback replace mode - the SOM for the user is not considered. The
user configuration settings are applied from the GPO's in the computer SOM
provided they have user permissions.

+++++++++++++

So in your case, you should find that the user who has been denied Read
and Apply for this policy, goes unrestricted. As Anthony suggests, get
the permissions set correctly first and then start with a clean profile
and logon. If you're still having problems, log in as that user and
gather a

gpresult /z

This will tell you where policy settings are applying from and what's
being filtered out by security.

Kind regards
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: (e-mail address removed)

Please note you'll need to strip ".online" from my email address to email
me; I'll post a response back to the group.

This posting is provided "AS IS" with no warranties, and confers no
rights.



Anthony Yates said:
Do you mean that the policy is still being actively applied, or that the
policy setting has not been reversed? Most policies are Not Configured by
default. If you Apply the policy to a user (with the loopback) then Deny
it,
you do not end up back at the default setting, you stay on the last one
that
was configured. Try deleting the user's terminal services profile and
recreating it.
We Deny the loopback policy to the people administering the terminal
servers, and it works fine.
Anthony
Click to expand...
Click to expand...
 
Hi Brian

I haven't looked at it that closely. Is that what you're seeing?

Kind regards
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: (e-mail address removed)

Please note you'll need to strip ".online" from my email address to email
me; I'll post a response back to the group.

This posting is provided "AS IS" with no warranties, and confers no rights.

Brian Higgins said:
is it possible that the RSOP dataset would show something different in
regards to the GPO's getting applied (planning mode) then what will
actually get applied at logon in regards to loopback policy's and setting
the deny entry in the ACL?


Mark Renoden said:
Hi

To clarify how policy loopback works:

1. When the computer boots, the list of GPO's for the computer is
gathered based on it's location in the Active Directory. This is it's
SOM or Scope of Management. The list includes GPO's linked to OU's at
each level in the heirarchy from the OU in which the computer resides all
the way up to the domain.

2. The computer configuration settings from this list are applied to the
computer provided the computer account has permissions to the GPO's.

3. When the user logs in, different behaviour occurs according to the
policy loopback settings:

A. Loopback off - the SOM for the user is calculated and then user
configuration settings applied according to user permissions. The
location of the user account in the AD decides entirely which user
configuration settings are applied.

B. Loopback merge mode - the SOM for the user is calculated as in A. The
user configuration settings from this SOM are applied but at a lower
precedence to the user configuration settings in the computer SOM. Once
again, user permissions allow or prevent application of these setting
regardless of whether they came from the user or computer SOM.

C. Loopback replace mode - the SOM for the user is not considered. The
user configuration settings are applied from the GPO's in the computer
SOM provided they have user permissions.

+++++++++++++

So in your case, you should find that the user who has been denied Read
and Apply for this policy, goes unrestricted. As Anthony suggests, get
the permissions set correctly first and then start with a clean profile
and logon. If you're still having problems, log in as that user and
gather a

gpresult /z

This will tell you where policy settings are applying from and what's
being filtered out by security.

Kind regards
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: (e-mail address removed)

Please note you'll need to strip ".online" from my email address to email
me; I'll post a response back to the group.

This posting is provided "AS IS" with no warranties, and confers no
rights.



Anthony Yates said:
Do you mean that the policy is still being actively applied, or that the
policy setting has not been reversed? Most policies are Not Configured
by
default. If you Apply the policy to a user (with the loopback) then Deny
it,
you do not end up back at the default setting, you stay on the last one
that
was configured. Try deleting the user's terminal services profile and
recreating it.
We Deny the loopback policy to the people administering the terminal
servers, and it works fine.
Anthony










I have a 2003 terminal server on a 2003 domain, I have configured
my
GPO
for the terminal server (which is in it's own OU, and enabled loopback
processing in replace mode. everything works exactly as I would like,
for
the users, but there is a software developer that needs full,
un-restricted
access (he does not get domain wide, just local, admin access) to this
server to maintain and update some custom software running on the
server.

I have followed the steps in Q315675 and applied the same principal
of
setting the deny apply gpo setting in the acl to the user account of
this
developer (actually a security group that he is a member of), I waited
for
plenty of time for the group membership and the ACL to propigate, I
then
ran
gpupdate /force on both the machine I was running the RSOP (planning
mode)
and on the terminal server (for when running RSOP in logging mode) and
both
RSOP datasets show that the user gpo is still applying to the user who
is
listed in the ACL with a deny entry in the apply setting.

What am I missing in regards to allowing this (and any other user
in
the
future) the ability to logon to the terminal server without getting
locked
down by my terminal restrictions gpo?

Any help here would be apprecieated.

Thanks.
- Brian
Click to expand...
Click to expand...
Click to expand...
 
Back
Top