Re: Access denied to Control Panel applets!

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: Access denied to Control Panel applets!
    ... You could also try running gpresult /z to get ... track it down if it is Group Policy related but it is not real user friendly ... it reports his user account in the OU you expect and compare his gpresult ... that much - nothing for the control panel etc... ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Access denied to Control Panel applets!
    ... GPO's - making sure to refresh and running gpresult to see which OU it said ... must be a huge f_ck up in active directory group policy - wherever it stores ... indicate a GP is applying those restrictions to his user account. ... that much - nothing for the control panel etc... ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Access denied to Control Panel applets!
    ... Policy settings are applied again so that they will show up in the ... user account though you may need to logon as an administrator when done to ... show that much - nothing for the control panel etc... ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Missing desktop tab in display control panel
    ... The Remove display in control panel policy locks the user ... The problem I have is that the desktop tab has completely ... >Windows 2000 Group Policy Registry Table: ...
    (microsoft.public.windowsxp.customize)
  • Re: Missing desktop tab in display control panel
    ... I haven't tried it.That policy isn't ... it does not restrict the Control Panel. ... >Windows 2000 Group Policy Registry Table: ... >shows the desktop tab but grays out all options. ...
    (microsoft.public.windowsxp.customize)