Question

Locked

Open/Explore All Users - disable context the only way to stop it?

By munsch ·
So okay... despite what seem like rational OUs, security groups, user permissions, etc and so forth, anyone can rightclick on the Start button and wander through other users' profiles..?

Yes, i have already implemented a GPO to disable the context menu for start/taskbar/clock, but this seems clumsy and imprecise. Why does this silly rightclick override the permissions present in AD for the groups that are set up?

Is there any way i'm missing that enforces these permissions (or more importantly, the lack of them) when users access that ridiculous menu? Or is disabling the menu the only way? And lastly, is hiding the ability to get that menu simply obscuring or adding a few steps towards that security hole...?

yeeesh,

Rob

This conversation is currently closed to new comments.

10 total posts (Page 1 of 1)  
| Thread display: Collapse - | Expand +

All Answers

Collapse -

Gotta run but

by IC-IT In reply to Open/Explore All Users - ...

sounds like they are local administrators, thats not good.

Collapse -

Don't seem to be.

by munsch In reply to Gotta run but

Even more amusingly, different members of the same OU / Security Group seem to have different levels of access to whose files they see, when doing this.

A full, annoying audit of all policies and group permissions etc. is now underway. But i'm still primarily interested in my original question.

Collapse -

If you have

by Jacky Howe In reply to Open/Explore All Users - ...

standard user accounts setup then these two policy restrictions will slow them down. If they are members of the local administrators group it won't work. I don't know what your environment is but I used to use the no context menu settings in a school environment.
<br><br>
User Configuration \ Administrative Templates \ Start Menu and Taskbar
<br><br>
Prevent changes to Taskbar and Start Menu settings
<br><br>
Removes the Taskbar and Start Menu item from Settings on the Start menu. This setting also prevents the user from opening the Taskbar Properties dialog box.
<br>
If the user right-clicks the taskbar and then clicks Properties, a message appears explaining that a setting prevents the action.
<br><br>
Remove access to the context menus on the Start Menu
<br>
Hides the menus that appear when you right-click the taskbar and items on the taskbar, such as the Start button, the clock, and the taskbar buttons.
<br>
This setting does not prevent users from using other methods to issue the commands that appear on these menus.
<br><br>
<i>Keep us informed as to your progress if you require further assistance.</i>
<br><br>
<i>If you think that any of the posts that have been made by all TR Members, have solved or contributed to solving the problem, please Mark them as <b>Helpful</b> so that others may benefit from the outcome.
</i>

Collapse -

Any way BESIDES disabling context?

by munsch In reply to If you have

Sorry if i wasn't clear.

I have disabled context menus on Start / Taskbar / Clock, and that path is now closed.

What I mean to ask is if that is the only hole involved, and the only way to plug it? Users do not - i've checked - have the rights to browse into each other's profiles and documents normally; but they can anyway by right-clicking on Start. This seems bizarre behaviour to me. Are the user/group objects' security settings really being bypassed, or is there something else going on?

Collapse -

That is a standard configuration for XP and it has carried on to Vista

by Jacky Howe In reply to Any way BESIDES disabling ...

All users will have access to their Profiles folder and they can make changes. If you don't want users to be able to make changes then you would use a Mandatory Profile.
<br><br>
By setting these Registry Keys to a Value of 0 you will be able to have a bit more control over what your users can see. Hiding Files and Folders doesn't mean that the Operating System can't still use them. For example if you hide Documents and Settings the User will still have access to the Profile folder but won't be able to see anyone else. The first one hides all Hidden files and folders and the second one disables makeing changes to the View Hidden files and Folders.
<br><br>
User Key: [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced]<br>
Value Name: ShowSuperHidden<br>
Data Type: REG_DWORD (DWORD Value)<br>
Value Data: ( 0 = Hide Files, 1 = Show Files)
<br><br>
User Key: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\Hidden\SHOWALL]<br>
Value Name: CheckedValue <br>
Data Type: REG_DWORD (DWORD Value)<br>
Value Data: ( 0 = Disabled, 1 = Enabled)
<br><br>
Are the user/group objects' security settings really being bypassed. No it is a standard setting.
<br><br>
<i>Keep us informed as to your progress if you require further assistance.</i>
<br><br>
<i>If you think that any of the posts that have been made by all TR Members, have solved or contributed to solving the problem, please Mark them as <b>Helpful</b> so that others may benefit from the outcome.
</i>

Collapse -

Good info, but...

by munsch In reply to That is a standard config ...

it's access to *other* users' roaming profiles that's the problem :)

Any given user can (or could before i disabled context menus) rightclick Start, choose Open All Users or Explore All Users, and browse around *any other user's* My Documents. And we checked: it's not an old, local My Documents, but current up-to-date files in the other users' roaming profiles.

This, frankly, horrified me. All i can think of is how much i'd like to "chmod 600" the lot of 'em.

Collapse -

OK

by Jacky Howe In reply to Good info, but...

you have a permissions problem. A standard User does not have permission to access another Users account. They would have to have Administrative permissions. Check your Users and see which groups that they belong to. When you use roaming profiles you would normally redirect the Users Home folder to a share on the file server by using folder redirection.
<br><br>
A roaming profile will cache the Users profile on the workstation and the User can logon and bypass any GPO's that are in place. To avoid this you will need to use these Policies to stop the use of the local profiles. :)
<br>
Using Group Policy to delete cached copies of roaming profiles
<br><br>
You can configure a Group Policy Object (GPO) to perform the preceding behavior by performing the following steps:<br>
1. Edit the GPO that you want to modify. <br>
2. Locate the following section: Computer Configuration \ Administrative Templates \ System \ User Profiles. <br>
3. Double-click Delete cached copies of roaming profiles (the Group Policy setting). <br>
4. Click Enabled. <br><br>

Log users off when roaming profile fails.
<br>
GPO Computer Configuration, Administrative Templates, System, User Profiles
<br>
Logs a user off automatically when the system cannot load the user's roaming user profile.
<br>
This setting is used when the system cannot find the roaming user profile or the profile contains errors which prevent it from loading correctly.
<br>
If you disable this setting or do not configure it, when the roaming profile fails, the system loads a local copy of the roaming user profile, if one is available. Otherwise, the system loads the default user profile (stored in %Systemroot%\Documents and Settings\Default User).
<br><br>
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/gp/21.mspx?mfr=true
<br><br>
<i>Keep us informed as to your progress if you require further assistance.</i>
<br><br>
<i>If you think that any of the posts that have been made by all TR Members, have solved or contributed to solving the problem, please Mark them as <b>Helpful</b> so that others may benefit from the outcome.
</i>

Collapse -

I thought it was cached copies too, but...

by munsch In reply to OK

User A logs into computer A. User A has never logged into any other computer. User B logs into computer B. User B has never logged into any other computer.

User A can see User B's current profile, files that were created or saved 5 minutes ago, etc.

I didn't set up the network, orignally. I see all users are in the Users OU, as well as a departmental OU. Neither the departmental OUs nor the Users OU seem to have local admin privs... or so i thought. i don't see the OUs themselves being a member of anything else.

Would this weirdness all be explained if the Users OU itself is set to allow localadmin privs? I could have missed that, and it would explain what's otherwise a headscratcher to me.

BTW, i'm going to go back and mark all your answers Helpful thus far, because while they haven't hit this particular instance of MS weirdness, they are all good things to know and of use to anyone else who finds this thread hunting up permission oddities :)

Collapse -

Someone

by Jacky Howe In reply to I thought it was cached c ...

must have added them to local admin. Was there any documentation for the server setup and the changes that have been configured. There should be.

Rob

Back to Software Forum
10 total posts (Page 1 of 1)  

Related Discussions

Related Forums