Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

In Windows 7, Vista and newer OS's, UAC will prevent logon scripts from mapping hard drives so that the following logon script code won't work:

Dim WshNetwork
Set WshNetwork = WScript.CreateObject("WScript.Network")

WshNetwork.MapNetworkDrive "g:", "\\\Saturn\data\"
WshNetwork.MapNetworkDrive "k:", "\\\Saturn\stuff\"

Administrators have a few choices when dealing with this issue:

Question

What approach is the most practical and supportable approach to making login scripts "just work" in Enterprise environments?

If the "most preferred" solution isn't the one enterprises are doing in the real world, what approach are they taking?

share|improve this question
2  
Well, in this specific case wouldn't it be preferable to use Group Policy to map the drives anyway? User Configuration > Preferences > Windows Settings > Drive Maps –  Safado Apr 27 '12 at 17:34
1  
Also, I used to map drives through login scripts before I switched it over to GPO and I would use net use S: \\Server\Shared and it would work fine with UAC on the default setting. –  Safado Apr 27 '12 at 17:39
    
@RyanM. I'm using Group Policy's Login Script field not drive mappings. Additional (if else) logic is needed to map drives that the setting you mention is unable to accommodate. –  makerofthings7 Apr 30 '12 at 13:59
add comment

5 Answers

Honestly UAC should not be interfering with anything being called from a group policy regardless if its a login.vbs script or even an exe. My script which has had years to mature is suddenly useless with UAC turned on. My script not only maps drives automatically, but checks to makes sure when the drive is already mapped that its the one you want. Remaps the dirve if its not the one its assigned to be. My script also calls an installer which checks to see if an update is required for a particular program and runs the installer as an administrator so that the user logged in does not need to have administrative rights. If your environment is setup where the users can't install programs UAC is more of a hinderence then a help. I have to support MORE calls because something DIDN'T happen now.

share|improve this answer
add comment

The problem I and many others have ran into is if the domain user account is part of the local administrators group, then the GPO Logon Script will not run resulting which will not map the network drives/shares.

http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/54721cb2-7f59-467f-856a-2a2d799ed953

Here is a thread I was looking at....the NET USE will not work in a GPO either with both Win 7 or Win 8, but Ori might have something that might work, the only problem is it is a more complex process than what should just work without a certificate.

share|improve this answer
add comment

How about calling the "net use" command from your VBS logon script?

Even thought the script itself runs under the Administrator token, any programs started by the script will run under a Standard user token, which means that drives mapped this way will be available to the user.

Your example could be adapted to look like this:

Set shell = CreateObject("Wscript.Shell")

shell.Run "net use g: \\Saturn\data", 7, True
shell.Run "net use k: \\Saturn\stuff", 7, True

(The '7' causes the command to run minimised, to avoid command prompt windows from appearing on the screen. And 'True' waits for the command to complete before continuing)

share|improve this answer
add comment

I don't have this in enterprise environments but have some experience of it in a small business environment.

I would recommend either the basic net use s: \\server\share suggested by Safado but if you need logic I would recommend kixtart, it was recommended to me by a 3rd party contractor we had in and everything I've seen it do has been impressive including basic logic, drive and printer mappings based on a number of variables including OU, groups, and pc name. It also has some basic security features should you wish to deny users the ability to view the login script logic.

share|improve this answer
add comment

Use Powershell and set your execution mode to allsigned. It's the best of the worst options for powershell execution methods, issue a code signing cert from your internal CA and sign your login scripts.

(new-object -com WScript.Network).MapNetworkDrive("g:","\\Saturn\data")
(new-object -com WScript.Network).MapNetworkDrive("k:","\\Saturn\stuff")

Powershell defaults to executing asInvoker, so unless I'm mistaken that should run sans UAC prompt.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.