Re: Access denied to Control Panel applets!

Yep you are right, use gpupdate /force. That will make sure that all Group
Policy settings are applied again so that they will show up in the
userenv.log. Otherwise Group Policy settings are not applied unless the
computer detects that a change has been made in a GPO. Then in particular
examine log entries that include SetRegistryValue:for under each
User\registry.pol line and there should be one for each GPO. That is where
you should find the registry setting for the user assuming it is applied by
Group Policy administrative templates. You will need to be logged on as his
user account though you may need to logon as an administrator when done to
view userenv.log or temporarily give his user account read permissions to
userenv.log. The userenv.log entries are timestamped so that you can make
sure you are looking at entries that would apply to his user account based
on the time logged on and running gpupdate /force. --- Steve



"Brad Pears" <donotreply@xxxxxxxxxxx> wrote in message
news:OM2bUwijGHA.4716@xxxxxxxxxxxxxxxxxxxxxxx
Thanks Steve... I will try the debug logging of userenv.log to see if I
can find anything... Also, I assume you meant I should use
"gpupdate/force" as opposed to gpresult/force once logging is turned on -
on his machine?

Brad


"Steven L Umbach" <n9rou@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:Z9CdnevcNbeDkBbZnZ2dnUVZ_rOdnZ2d@xxxxxxxxxxxxxx
That is bizarre. Also verify that this user does not have any logon
scripts assigned to him in his user account properties that could be
applying restrictions that way such as a batch file that contains a .reg
file. I assume that gpresult showed exactly the same Group Polices
applied to all the users you compared. You could also try running
gpresult /z to get verbose output to compare to a couple users but you
would want to pipe the output to a text file using >c:\gpresult.txt
after the command or using whatever filename/path you want. There is a
way that you probably could track it down if it is Group Policy related
but it is not real user friendly and that is to enable debug logging of
userenv.log on his computer and then having him do a gpresult /force
while he is logged on and then going through the userenv.log to see if
you can find that registry entry in question and the Group Policy
applying it. I also suggest you post in the
Microsoft.public.Windows.group_policy newsgoup explaining all that you
have done so far. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;EN-US;221833


"Brad Pears" <donotreply@xxxxxxxxxxx> wrote in message
news:ea$6jALjGHA.1552@xxxxxxxxxxxxxxxxxxxxxxx
Tried everything...

Moved him out of the OU he was in - I tried the default User OU and even
moved him into our administrators OU!!! gpresult reports exactly the
correct OU in each scenario but he still cannot run the control panel
applets.... i.e. nothiong changed! I moved him in and out of a few
other GPO's - making sure to refresh and running gpresult to see which
OU it said he was in. Each time I ran gpresult, it reported the correct
OU but did not change his access... This is strange. I think the only
thing left to try is to delete his profile and then recreate it to see
what happens... There must be a huge f_ck up in active directory group
policy - wherever it stores this crap...

PS... I compared his gpresult with another user in the same OU (logged
onto the same machine) - exactly the same!!!! Yet that user has the
appropriate rights!!!

Another microsoft funny??

Thanks, Brad


"Steven L Umbach" <n9rou@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:8vednZ_QSreQWRTZnZ2dnUVZ_tSdnZ2d@xxxxxxxxxxxxxx
Weird. Try running gpresult on his computer for him as the user to see
if it reports his user account in the OU you expect and compare his
gpresult for user configuration to the other domain user that does not
have the restrictions including the applied Group Policy objects and
group membership. I don't think deleting his user profile will help
because he is seeing the same behavior on multiple computers which
really seems to indicate a GP is applying those restrictions to his
user account . If nothing apparent is found try moving his user account
out of that OU temporarily assuming it is not in the default user
container and putting him in the default user container. Below is an
example of gpresult output for user settings showing in this case that
my user account is in the default users container.--- Steve


USER SETTINGS
--------------
CN=steve,CN=Users,DC=umbach3,DC=com
Last time Group Policy was applied: 6/9/2006 at 12:28:05 PM
Group Policy was applied from: server1-2003.umbach3.com
Group Policy slow link threshold: 500 kbps
Domain Name: UMBACH3
Domain Type: Windows 2000

Applied Group Policy Objects
-----------------------------
Default Domain Policy
Local Group Policy

The user is a part of the following security groups
---------------------------------------------------
Domain Users
Everyone
CERTSVC_DCOM_ACCESS
BUILTIN\Administrators
BUILTIN\Users
BUILTIN\Pre-Windows 2000 Compatible Access
REMOTE INTERACTIVE LOGON
NT AUTHORITY\INTERACTIVE
NT AUTHORITY\Authenticated Users
This Organization
LOCAL
Domain Admins
CERTSVC_DCOM_ACCESS

"Brad Pears" <donotreply@xxxxxxxxxxx> wrote in message
news:emvVSc9iGHA.2188@xxxxxxxxxxxxxxxxxxxxxxx
I was able to run RSOP when logged on as the user. It really didn't
show that much - nothing for the control panel etc... I even tried a
gpupdate/force when logged on as this user - but that didn;t do
anything... It is definately a user policy causing the issue because I
had him log into our domain using another computer and he get's the
same restrictions on that other PC!! I also had another user log into
the domain using his laptop and that user had full rights - so that
pretty much tells me it is a user policy being applied
somewhere...Incidentally, the user that logged onto his machine is in
the same OU as him!!!

This user does log onto our terminal servers from time to time and
these policy restrictions he is seeing are definately applied to the
terminal servers - as the terminal servers are in an OU of their own
so that users logging onto those machines can not play too much! :-)
I don'lt think this is causing the issue though because a few of the
other users in his OU also log onto the term servers from time to time
and none of those users have the same issue he does...

Maybe I should just delete his profile and re-create it to see if that
works... I cannot think of anywhere else to check.

What do you think?

Brad
"Steven L Umbach" <n9rou@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:8sSdnRdnlIkxxRXZnZ2dneKdnZydnZ2d@xxxxxxxxxxxxxx
Try having another domain user logon to his computer to see if they
experience the same behavior or not. Verify that his computer and
user account are in the containers you expect. It definitely sounds
like domain level user configuration Group Policy since it does not
apply to. See if he can run rsop.msc while logged onto his computer
as a domain user to see what GP settings it shows for his user
account and what Group Policy is applying the setting in question. If
he can not run rsop.msc [I am not sure if it will work for a regular
user offhand] then logon as an administrator and run the Resultant
Set of Policy mmc snapin for his user account. --- Steve


"Brad Pears" <donotreply@xxxxxxxxxxx> wrote in message
news:uXC8FPxiGHA.2220@xxxxxxxxxxxxxxxxxxxxxxx
I have a strange issue going on here...

We have a Windows 2000 SBS domain in our company. I have some OU's
set up
and some policies are applied. However, nowhere do I have a policy
set to
not allow access to control panel appletss for domain users of any
OU -
EXCEPT for our terminal server users - who are in a separate OU
altogether.

I have one user on a new XP Pro SP2 laptop who is NOT in this OU at
all, yet
when he tries to access a control panel applet (i.e. Printers and
other
hardware) he gets the following message...

"These Control Panel options are not available. The content of this
Control
Panel Category has been made unavailable by your system
administrator. To
make changes on this area, contact your system administrator."

This user is logged onto the domain, and other users in the same OU
who are
also logged into the domain, have full access to their control panel
applets. His domain account is also listed as local "adminstrator"
on his
laptop. If I log on to his machine using the local administrator
account, I
can access the control panel applets no probs... If he logs in
locally to
his laptop, he can also access the control panel applets. I also
checked the
local policies on his machine - saw nothing there that would prevent
his
domain account access to the applets...

Any ideas on how to maybe rectify this issue?

Help!

Thanks, Brad

















.

Relevant Pages

  • Re: password expiration
    ... I did notice that the security settings for Password, ... etc..., both in the default domain policy and on the OU's, ... >not affect your user account objects in that OU. ...
    (microsoft.public.win2000.active_directory)
  • Re: Group Policy -> Missing Group Policy settings
    ... Install the templates on the Group Policy Management machines, ... Default Domain Policy, with the following settings: ... Permit Acces to the control panel, ... I see the GPO Default Domain Policy is Apllied, and the Administrator ...
    (microsoft.public.windows.server.active_directory)
  • Re: Group Policy -> Missing Group Policy settings
    ... I've checked my ADM files, it seems to be OK, thanks. ... It seems to be the Default Domain policy! ... Default Domain Policy, with the following settings: ... Permit Acces to the control panel, ...
    (microsoft.public.windows.server.active_directory)
  • Re: Access denied to Control Panel applets!
    ... indicate a GP is applying those restrictions to his user account. ... Group Policy was applied from: ... that much - nothing for the control panel etc... ...
    (microsoft.public.windowsxp.security_admin)
  • Re: unable to change the default email address for an account
    ... Open the properties for the user account. ... clear " Automatically update email address based on Recipient Policy ... BTW, my mistake, the default policy priority is marked as 'Lowest' not 0. ... Les Connor [SBS Community Member - SBS MVP] ...
    (microsoft.public.windows.server.sbs)