[gptalk] Re: Loopback GPO Deny perms not working consistently
- From: Robert Tannehill <rtannehill@xxxxxxx>
- To: gptalk@xxxxxxxxxxxxx
- Date: Tue, 19 Dec 2006 16:42:36 -0800
Hi Alan,
Excellent explanation, and your policy reporter is a great program..it
really beats going through text files - wish I had it a while back, thanks
so much. Now that I understand, through your thorough explanation, what
the NTUSER.POL file is doing, here's what I'm seeing:
#1. If the user has a profile with data in the NTUSER.POL (42K in my case)
AND is IN the DENY group, the policy is properly removed.
#2. If the user does not have a profile, therefore creating a new
NTUSER.POL (42K) and is NOT IN the DENY group, then the policy is properly
applied.
#3. If the user does not have a profile (new logon to this server), AND
the user is IN the DENY group, then the policy is "semi" applied - meaning
I see some of the policy affects. The NTUSER.POL was empty (showing 1K)
and the DENY could not Delete any Registry entries.
To fix #3., I take the user OUT of the DENY group, have them logon (with
their profile in tact), which then applies the policy (NTUSER.POL now has
42K again). Then add them again to the DENY group, and it behaves as #1.
Since these are Citrix servers, we delete all profiles left over each
night and therefore, the I'll have situation #3 each day. Is #3 aborent
behavior and is just a design flaw I'll have to live with?
Thanks so much for all your help!
Robert
_____
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Alan & Margaret
Sent: Saturday, December 16, 2006 1:15 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Loopback GPO Deny perms not working consistently
Hi Robert,
Just realized that what I should have said in my last post was that the
bit of the Userenv log that you are looking at is not where the policy is
being applied, but rather where the policy is being "unapplied". i.e it is
describing removal of the non tattooed policies from the previous
application of policies, not applying the current policies.
Alan C.
_____
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Alan & Margaret
Sent: Sunday, 17 December 2006 7:41 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Loopback GPO Deny perms not working consistently
Hi Robert,
In the first case, the system has detected an NTUSER.POL file that
contains all of the "non-tattooed" policies, ie. Those in the
"Software\Microsoft\Windows\CurrentVersion\Policies" key and in
"Software\Policies". This means that the last time policy processing ran,
these policies were applied to the user.
In the second case, the system has detected an NTUSER.POL file that
contains no "non-tattooed" policies. This means that the last time policy
processing ran, these policies were not applied to the user.
In the first case, (assuming the policies were not applied), the
NTUSER.POL should be rewritten as an empty file and so the next time
Policy processing runs, it should behave the same way as the "Not
removing" case.
So what I would expect to see is that for a "normal user" they would go
through all of the processing and decide to apply the policy. Applying the
policy means first deleting all of the Tattooed polices (as found in the
Ntuser.pol") and then reapplying them.
For an Admin user, they would go through all of the processing and decide
not to apply the policy. Not Applying the policy means first deleting all
of the Tattooed polices (as found in the Ntuser.pol"). But assuming the
Admin had not got the policy last time, the NTUSER.pol would be empty. It
would be worth checking whether the "working properly" case behaves the
same way next time it runs. If so, it suggests that the ntuser.pol file is
not being rewritten correctly
The fact that it has not worked for all of the admins could be that they
had the policy applied some time in the past, but they did not have an
NTUSER.pol that reflected this. This means that it will never get removed
properly. This would mean that if you fixed it up manually (i.e. removing
the registry settings), then the keys will not reset. You could also try
changing the policy so that they get the settings (this will create a
correct NTUSER.POL) then change it back and the NTUSER.POL will remove the
settings. A short cut to this is to copy across an NTUSER.Pol from a
normal user to the admin. If you force the Policy to reapply, it will
then clear out the keys you want removed.
It is not clear from the Userenv extract that you have shown what exactly
is gong on in each case, but you should be really looking at the section
of the Userenv log that works out what policies to apply. I have a free
program that you can use to help you view and interpret the log.
http://www.sysprosoft.com/index.php?ref=activedir
<http://www.sysprosoft.com/index.php?ref=activedir&f=policyreporter.shtml>
&f=policyreporter.shtml
Alan Cuthbertson
Policy Management Software:-
http://www.sysprosoft.com/index.php?ref=activedir
<http://www.sysprosoft.com/index.php?ref=activedir&f=pol_summary.shtml>
&f=pol_summary.shtml
ADM Template Editor:-
http://www.sysprosoft.com/index.php?ref=activedir
<http://www.sysprosoft.com/index.php?ref=activedir&f=adm_summary.shtml>
&f=adm_summary.shtml
Policy Log Reporter(Free)
http://www.sysprosoft.com/index.php?ref=activedir
<http://www.sysprosoft.com/index.php?ref=activedir&f=policyreporter.shtml>
&f=policyreporter.shtml
.
_____
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Robert Tannehill
Sent: Saturday, 16 December 2006 12:04 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Loopback GPO Deny perms not working consistently
Hey All,
Here's my problem. I have a loopback GPO applied to some Citrix servers,
which locks down the users. The admins, however, need "normal" access to
the servers through RDP, so, per Darren's recommendation, I created a
group for the admins which I permission with a Deny for the Apply Group
Policy. This has worked, but not for all the admin accounts for some
reason.
I ran a USERENV.LOG to compare the an account that was properly having the
GPO apply denied, and one that wasn't working as prescribed. In the logs,
both are indicating that the GPO "is not getting applied" and is skipped.
However, there is a point in the USERENV.LOG where it shows the GPO
entries being backed out for the working one, and not being backed out for
the non working one.
For example:
Working properly:
USERENV(28c.165c) 17:20:51:094 ParseRegistryFile: Entering with
<C:\Documents and Settings\goodGPOuser\ntuser.pol>.
USERENV(28c.165c) 17:20:51:094 DeleteRegistryValue: Deleted
Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoWindowsUpdat
e
USERENV(28c.165c) 17:20:51:094 DeleteRegistryValue: Deleted
Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\MemCheckBoxInR
unDlg
USERENV(28c.165c) 17:20:51:094 DeleteRegistryValue: Deleted
Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoStartMenuMor
ePrograms
USERENV(28c.165c) 17:20:51:094 DeleteRegistryValue: Deleted
Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoNetworkConne
ctions
... 150 more lines...
USERENV(28c.165c) 17:20:51:344 DeleteRegistryValue: Deleted
Software\Policies\Microsoft\WindowsMediaPlayer\Protocols\MMS\ProxyPolicy
USERENV(28c.165c) 17:20:51:344 DeleteRegistryValue: Deleted
Software\Policies\Microsoft\WindowsMediaPlayer\Protocols\MMS\BypassProxyLo
cal
USERENV(28c.165c) 17:20:51:344 ParseRegistryFile: Leaving.
USERENV(28c.165c) 17:20:51:344 ResetPolicies: resetting shell autorun
value for server.
USERENV(28c.165c) 17:20:51:344 ResetPolicies: Leaving.
Not removing policy:
1. USERENV(28c.1630) 17:31:57:812 SetRegPermissionsOnPoliciesKey:
Resetting permission on the policy key
2. USERENV(28c.1630) 17:31:57:812 ParseRegistryFile: Entering with
<C:\Documents and Settings\badGPOuser\ntuser.pol>.
3. USERENV(28c.1630) 17:31:57:812 ParseRegistryFile: Leaving.
4. USERENV(28c.1630) 17:31:57:812 ResetPolicies: resetting shell autorun
value for server.
5. USERENV(28c.1630) 17:31:57:812 ResetPolicies: Leaving.
Notice that between lines 2 & 3, there are no "DeleteRegistryValue" lines,
and so.... the policy is still in play.
Thanks for any comments/clues/"where to goes to see what the heck is going
ons"
Robert Tannehill
Sr. Computer Engineer
Computer Sciences Corporation
Other related posts:
