[gptalk] Re: Loopback GPO Deny perms not working consistently
- From: "Alan & Margaret" <syspro@xxxxxxxxxxxxxxxx>
- To: <gptalk@xxxxxxxxxxxxx>
- Date: Wed, 20 Dec 2006 15:31:27 +1100
Hi Robert,
I think I understand what is causing your problem. Your default profile
contains a default registry which is inconsistent with the default
ntuser.pol.
I suspect that when you had created the default profile you did it by
copying over the NTUSER.DAT file from a user who had the restrictions
applied (i.e. Policy Keys in place). However, you did not copy over the
corresponding NTUSER.POL for the same user. Thus the default registry has
the restrictions in place, but policy processing does not know about them
and can't remove them.
You can fix it by either copying the NTUSER.DAT from a user without the
policies applied to the Default Profile area, or you can copy across the
NTUSER.POL from a user who has the restrictions in place. Either should
work.
Alan C
_____
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Robert Tannehill
Sent: Wednesday, 20 December 2006 11:43 AM
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:
