[gptalk] Re: Loopback GPO Deny perms not working consistently
- From: "Darren Mar-Elia" <darren@xxxxxxxxxx>
- To: <gptalk@xxxxxxxxxxxxx>
- Date: Tue, 19 Dec 2006 18:22:25 -0800
Robert-
This sounds like a timing issue more than anything else. I'm a little
curious about the statement of profile vs. non-profile. There is never an
instance, that I'm aware of, where the profile is unavailable before policy
runs. Indeed this would be rather impossible since the HKCU hive is
ntuser.dat, which has to exist before policy could even think about running.
So, it is interesting that it takes two logons to see the proper operation
but I think something else is going on here.
Darren
Darren Mar-Elia
For comprehensive Windows Group Policy Information, check out www.gpoguy.com
<http://www.gpoguy.com/> -- the best source for GPO FAQs, video training,
tools and whitepapers. Also check out the Windows
<http://www.amazon.com/gp/product/0735622175/qid=1122367169/sr=8-1/ref=pd_bb
s_1/104-1133146-9411929?v=glance&n=283155> Group Policy Guide, the
definitive resource for Group Policy information.
Download the new GPHealth Reporter trial version at
http://www.sdmsoftware.com/products.php
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Robert Tannehill
Sent: Tuesday, December 19, 2006 4:43 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Loopback GPO Deny perms not working consistently
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\NoWindowsUpdate
USERENV(28c.165c) 17:20:51:094 DeleteRegistryValue: Deleted
Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\MemCheckBoxInRun
Dlg
USERENV(28c.165c) 17:20:51:094 DeleteRegistryValue: Deleted
Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoStartMenuMoreP
rograms
USERENV(28c.165c) 17:20:51:094 DeleteRegistryValue: Deleted
Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoNetworkConnect
ions
... 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\BypassProxyLoca
l
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:
