Drive Naming vs. Permissions

[Gongalong]

Hi folks,

 

I've inherited a 2008 R2 system which maps a series of drives for staff, some of which have reduced access e.g. Senior Leadership Team.

 

The mapping is done via a VB Script (in Group Policy) which passes a number of variables, although the detail isn't that important I suspect. In short it first maps the drive, then names the mapped drive.

 

Domain Users has been added to all drives with folder only read access at the root, so from a security POV it allows all users to at least view folders and files (specifically filenames) in the root of drives with reduced access. If Domain Users is removed from the drive then the script still maps the drive, but is unable to name it.

 

Does anyone know why the drive can't be named with Domain Users permission removed?

 

TIA

[DEvans]

Hey,

 

Have you instead thought about changing that whole vbscript routine and moving to preferences. Since it's a 2008R2 network, it might be worth it and it'll give you more control over who gets what drive and what criteria needs to be met for those people to get said drives etc..

 

Vbscript is brilliant, I won't fault that, but it does make life tricky when it comes to permissions over certain things like naming the drives etc.

[Gongalong]

Stupid question, but what's "preferences"?

[Gongalong]

Ah, Group Policy > User Configuration > Preferences > Windows Settings > Drive Maps?

[DEvans]

Stupid question, but what's "preferences"?

 

No Question is stupid if you don't know the answer.

 

Group Policy > User Configuration > Preferences > Windows Settings > Drive Maps?

 

You have it in one.

 

-----------------

 

Essentially, all that hassle of writing scripts for drive mapping, registry edits, printer mapping, control panel settings, proxy, local user, power policies.. well just about anything, now has a easy to use, advanced GUI to it all.

 

What type of network do you have? Do you have Ranger, CC4, Vanilla Group Policy, CSE?

 

When you go into your group policies, create a policy for your students and/or staff. Edit the policy and you'll notice there is a + sign next to two folders, Policies and Preferences.

 

Open up Preferences under User configuration (for drive maps) or Computer configuration for other things, (thats dependant on what you want to do) and play with it. There is something known as Item Level Targeting which essentially creates you IF statements. e.g.

 

IF User is Member of Staff Security Group, THEN map X drives, IF NOT do this, etc..

 

It's nice and easy. Works perfectly on XP and above, though for XP you need to install the preferences client side extension hotfix which makes XP aware of what preferences are and allows them to work. This is installed by standard on Vista, 7 & 8.

 

Hotfix found here: Group Policy Preferences Client-Side Extension Hotfix Rollup

Edited July 12, 2012 by DEvans

[Radius118]

Hi folks,

 

I've inherited a 2008 R2 system which maps a series of drives for staff, some of which have reduced access e.g. Senior Leadership Team.

 

The mapping is done via a VB Script (in Group Policy) which passes a number of variables, although the detail isn't that important I suspect. In short it first maps the drive, then names the mapped drive.

 

Domain Users has been added to all drives with folder only read access at the root, so from a security POV it allows all users to at least view folders and files (specifically filenames) in the root of drives with reduced access. If Domain Users is removed from the drive then the script still maps the drive, but is unable to name it.

 

Does anyone know why the drive can't be named with Domain Users permission removed?

 

TIA

 

Why not define security groups in AD, then define access to network shares using those groups? Then use a simple logon script to automatically map the shares.

 

To answer your question, you might want to look at the permissions the script runs under. If it runs in the Domain Users group - although with enhanced permissions - then removing the Domain Users permissions from the share will result in the script not having necessary permissions. At least that's my guess anyway.

 

Michael

Edited July 14, 2012 by Radius118

[Gongalong]

That's what I'm doing (scripts and groups), but with the aforementioned problems.

 

Where would I check for what permissions the script runs under?

[Radius118]

That's what I'm doing (scripts and groups), but with the aforementioned problems.

 

Where would I check for what permissions the script runs under?

 

By default, Startup scripts run as Local System, and they have the full rights that are associated with being able to run as Local System. Logon script scripts run on the User account and not on the Administrator account.

 

So, if these are logon scripts, and the user account they are running under are members of the Domain Users group, and you remove that group from permissions for the shared resource, then the logon script will no longer have permissions to run.

 

If these are not your scripts, I would start with checking to see if the script is running under group policy in Group Policy Management. If they aren't, then I would consider reconfiguring things so they can run under Group Policy.

 

I have a few links for you, but I can't post them because my post count is too low. I will be able to on the next post though. So I will try.

 

Michael

[Radius118]

Here are a few links, although some of them are a little old:

Assign computer startup scripts: Group Policy

Overview of Logon, Logoff, Startup, and Shutdown Scripts in Windows 2000

Windows 2000 Script Policies

 

And here is some information on Group Policy Preferences:

Group Policy FAQ #1: What are the Group Policy Preferences Prerequisites?

[Gongalong]

The script maps 5 drives. If I remove Domain User permissions from one of the drives it still maps, but won't name it, even if the user has permissions to it. Odd!

[Radius118]

The script maps 5 drives. If I remove Domain User permissions from one of the drives it still maps, but won't name it, even if the user has permissions to it. Odd!

 

Wow! No offense, but that seems like a mess. You should really start using DFS. The beauty of DFS is that you create a namespace such as .local\home. Then you can assign all of your shares to this namespace by making DFS folders. In our organization, we have shares across 12 servers with about 35 folders. All of them are available from one location. The real location of the share becomes transparent to the users and you only have to map one location. Assign your permissions when you create the DFS folders and you're done. If you have permissions to view the folder, it's there. If not, then it's not visible. Not only that, but it adds incredible flexibility to your network.

 

So when our users logon, it maps Y: to \\.local\home and we're done. We make sure that all users have access to that share, then restrict access to the individual folders inside that share. So now the whole company refers to the "Y" drive. It really works well.

 

For example, we have a lot of custom scripts that run to process EDI data coming in from our customers. Instead of having each script run in a specific share, we specify a folder from our root DFS. So instead of specifying something like: \\server\folder1\folder2 We do this instead: \\.local\home\folder

 

 

What's great about this is that if for some reason you decide to move that share, all you have to do is copy it and update the DFS share. You don't have to run around modifying scripts, etc, in order to avoid breaking something.

 

Another example of the flexibility of DFS. I needed more hard drive space for our server nightly backups. So I created a new namespace Archive. So the path is \\.local\Archive. I added 3 different shares to this namespace. All 3 shares are on different machines. So now when I do network backups, my path is \\.local\Archive\Backup or Backup2 or Backup3. Then I set Windows backup to backup to these shares. If I decide to move one of these shares, it's easy. Simply copy the data where I want it to go, delete the original share, make a new share at the new location, and update DFS. Done. I don't have to log on to 6 different servers and reconfigure the nightly backup.

 

Make sense? I think I got a little verbose there.

 

As for your current issue, you definitely have some type of permissions issue going on there. Why do you want to remove Domain User permissions from these shares?

 

Michael

[Gongalong]

The more detail the better My networking skills are fairly rusty.

 

I get the feeling this was setup in a legacy fashion, so if I get the time I'll revisit a redesign.

[Gongalong]

As for your current issue, you definitely have some type of permissions issue going on there. Why do you want to remove Domain User permissions from these shares?

Because it enables any user to see the root of the share e.g. folders, and filenames. As above they only have read-only access at the root of the folder, but they shouldn't really and it's just a kludge it seems to get naming working.

[Radius118]

Because it enables any user to see the root of the share e.g. folders, and filenames. As above they only have read-only access at the root of the folder, but they shouldn't really and it's just a kludge it seems to get naming working.

 

Based on what I understand you are trying to do, that DFS really is your answer. You can go through and set up security groups for uses, and go through all your shares and set it up but it's going to be time consuming and cumbersome.

 

Michael

[Radius118]

The more detail the better My networking skills are fairly rusty.

 

No worries, I'm still pretty new myself.