How to secure my MSI mapped folder as a drive letter...

[kennysarmy]

Hoping someone can advise.

I map a drive letter viewable by "everyone" on the network as the V:\ drive.

This is a folder on one of my servers where I create sub-folders to store any MSI's that are deployed using active directory.

Everyones login script contains the line : net use v: \\servername\ShApps

The actual locaton of ShApps being D:\server_apps\utilities

The permissions on this folder are: Administrators & Domain Admins = Full Control; Everyone = Read & Execute, List Folder Contents, Read

Examples of things that get deployed out via AD are Flash, Tarsia, Shockwave, InPrint etc.

I've suddenly realized this location is not locked down by our security policies which restrict which drives allow software to run from & that everyone can view the folders and contents - and obviously run the installations.

If I was to either add the V:\ drive to the security policy or remove the Everyone = Read & Execute, List Folder Contents, Read permissions would the software still install OK when the relevant GPO was applied.

I am thinking yes as it's done before a "user" logs on - unless the "Everyone" element also means the "system" can have permission to execute.

[victory2012]

Why not remove the V drive? it is not needed to active directory MSI deployment?

[themightymrp]

Or as I do, have a subfolder in the netlogon share which contains my deployed MSI's and just have the AD dish them out from there. Permissions are already set for students etc to read & execute but they can't browse to it

[tmcd35]

Someone will probably correct me if my memory is wrong but...

1) you don't need to map the msi share for everybody, take the mapping out of the startup script
2) I'd have the msi folder as a hidden share, change the share name from \\servername\ShApps to \\servername\ShApps$

Bad news, is that making both of those changed will require all your msi's to be uninstalled and redeployed (Windows is sh*t).

As for folder permissions, I thought it was the SYSTEMS user that installed the msi's and needs full control. msi installs are done before the user logs on so you should be save removing Everyone from the folder.

[apeo]

Not sure why you need/want the drive mapped but assuming you're using 2008 servers, you can use gpp to deploy mapped drives and you can hide drives from the user. Even if they have access to it, they cant see it.

As the other have said, you dont need a map drive to deploy msi and installation is done during computer startup if deploying via gpo. Everyone group is not required but Domain Computers is.

As a general rule I dont use Everyone if I can help.

[Ergo]

Someone will probably correct me if my memory is wrong but...

1) you don't need to map the msi share for everybody, take the mapping out of the startup script
2) I'd have the msi folder as a hidden share, change the share name from \\servername\ShApps to \\servername\ShApps$

Bad news, is that making both of those changed will require all your msi's to be uninstalled and redeployed (Windows is sh*t).

As for folder permissions, I thought it was the SYSTEMS user that installed the msi's and needs full control. msi installs are done before the user logs on so you should be save removing Everyone from the folder.

1) Correct
2) Correct

Yes, removing and re-creating GPOs for software deployment would cause the software to re-install (depending on GPO settigs) but as the drive is mapped for users this could not have been used for deploying software as Computer GPOs. I assume this means you deploy software using the User Policies section of GPOs?

For the security settings it will be required for Domain Computers to have at least Read+Execute permissions - I don't think it requires full control.
@kennysarmy I assume there is some reason you have mapped this drive in the first place - was it simply convenience or so users could access network applications which are also installed onto that share?

Regards,

Dave

[Jamo]

You never need to map an MSI package share, I won't even work if you deploy through GPO to a mapped drive as the map won't exist until the user has logged on. A share path is all that is needed.

You need 'Authenticated Users' as the permission to read and execute on the share. You can change the NTFS security permissions to not allow folder browsing if you don't want people poking around in the folder. Thats in the advanced security settings on the NTFS folder itself. Adding the hidden share $ onto the share name is the only other part that is done in our school

People really have to be persistent to get to the apps then!

You can't add 'System' to the permissions as that's a local account, specific to each machine. You either have to have 'Authenticated Users' or 'Everyone'.

[j17sparky]

I'd have the msi folder as a hidden share, change the share name from \\servername\ShApps to \\servername\ShApps$

Bad news, is that making both of those changed will require all your msi's to be uninstalled and redeployed (Windows is sh*t).

If you go this route I'd suggest implementing DFS now. Whenever you change the path you will have to redo every app, ie whenever you change server name. With DFS the path will alway be \\domain.local\dfs_root\ShApps$

[kennysarmy]

1) Correct
2) Correct

Yes, removing and re-creating GPOs for software deployment would cause the software to re-install (depending on GPO settigs) but as the drive is mapped for users this could not have been used for deploying software as Computer GPOs. I assume this means you deploy software using the User Policies section of GPOs?

For the security settings it will be required for Domain Computers to have at least Read+Execute permissions - I don't think it requires full control.
@kennysarmy I assume there is some reason you have mapped this drive in the first place - was it simply convenience or so users could access network applications which are also installed onto that share?

Regards,

Dave

Hi Dave,

I do use the computer part of GPO but point the install for example at \\servername\shapps\inprint\In Print 2.msi

Historically all networkable software was run from the V:\ drive but when we switched from server 2003 to 2008 we rolled out a new APPS server and now all software than can just run from a central EXE is run from that server from an N:\ drive share. I left some software I did nt want to mess with and the MSI folders on the V:\ drive.

Where software remaining on V:\ needs to be secured from students I have removed the EVERYONE and replaced with STAFF.

I guess I have at the moment a hybrid that needs sorting.

My plan will be to create a new sub-folder under NETLOGON for future MSI deployments.
Lock down existing sub-folders that contain MSI's on the V:\ drive by removing EVERYONE and replacing wtih DOMAIN COMPUTERS (Read & Execute)

I want to avoid any existing software being removed and re-installed and causing delays to logons etc. Some of the software does take a while to deploy out!

Thanks for all the helpful comments.

Does my plan sound OK?

[apeo]

Assuming you still have software that can run from the network on the V:\ drive the I'd remove Everyone. Then give Domain Computers and which ever user groups that you want read/excute access to it. If you want you could just use Authenticated Users (as said above) to generally give all logged on users access.

While you still need to map the drive i would suggest mapping the drive via GPP and hide it.

[Ergo]

Does my plan sound OK?

Yes it sounds like you have thought that through well

With the permissions changes I would recommend testing on 1 folder before you go through the whole drive to make sure we have not suggested anything which will break your setup!

Dave

[Davit2005]

I have an apps drive mapped which is hidden that I use for resources that won't work with a URL and have hidden the drive from use as well as used a hidden share.

You can hide mapped drives by making a custom adm (but I wouldn't install custom adm's on the default domain policy).

The following link can show you how.

Using Group Policy Objects to hide specified drives

[kennysarmy]

I have an apps drive mapped which is hidden that I use for resources that won't work with a URL and have hidden the drive from use as well as used a hidden share.

You can hide mapped drives by making a custom adm (but I wouldn't install custom adm's on the default domain policy).

The following link can show you how.

Using Group Policy Objects to hide specified drives

A little confused.
Can I hide a mapped drive and shortcuts that refer to on the users desktop still work??

[Davit2005]

I guess the computer has just got to know where to find the target it doesn't really matter if the user can't see the drive.

We have shortcuts to some applications on users desktops and in the redirected startmenu that run on a server or the local machine they work with out issue.

[j17sparky]

My plan will be to create a new sub-folder under NETLOGON for future MSI deployments.

You have an App server, use it. Unless you change the location of NETLOGON you will be serving MSIs from the DC(s). Once you have a few dozen PCs pulling big MSIs your user logon time will jump up as they fight for HD time on the DC.