Re: Access denied to Control Panel applets!

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: 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: folder redirect
    ... Ok, under the account where the redirection works, it shows in the gpresult ... Group Policy was applied from: ...
    (microsoft.public.windows.server.general)
  • 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: Outlook account setup
    ... This appears to have happened when I upgraded to use the group policy snap ... > Hey Iain, ... > Control Panel -> Show only specified control panel applets. ... >> account details at all, but I don't know how to go about doing this... ...
    (microsoft.public.windows.terminal_services)
  • Re: Outlook account setup
    ... Control Panel -> Show only specified control panel applets. ... > As part of my group policy, I ban access to the control panel for all ... > I have been thinking along the lines of convincing outlook that it has no ... > account details at all, but I don't know how to go about doing this... ...
    (microsoft.public.windows.terminal_services)