WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

UAC

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

Mapped Network Drive Issue with UAC On

 Keywords:  Elvation Escalation DiskScan network mapped drive drives GetDriveType WinBatch Studio DirChange DirHome FileOpen FileExist 
FileItemize wntGetCon Mapped Drives Issue UAC User Account Control Windows Win7 Vista 7

When running as an Administrator, the user has two contexts: the limited user context, and the administrator context. When you map drives in Windows Explorer, they are added only for the limited user context. Thus when the script runs in the administrative context, no mapped drives are 'seen' by the script. WBT files run with user elevation 'HighestAvilable', which means when running under an Administrator account the script is running in the context of the administrator NOT the user.

OPTIONS:

It would seem that many other functions are also affected by this issue. Most any function that references the mapped drive: DirChange, DirHome, FileOpen, FileExist, FileItemize, wntGetCon, etc.

Resources:
http://blogs.msdn.com/cjacks/archive/2007/02/19/mapped-network-drives-with-uac-on-windows-vista.aspx

https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=939697&SiteID=1

http://community.installshield.com/showthread.php?p=380031

http://www.vista64.net/forums/vista-installation-setup/29134-when-logged-admin-mapped-drives-arent-visible-only-unc-p.html


More

You've got UAC enabled and you are either performing elevation by clicking the UAC continue button, or escalation by providing administrative account credentials.

In both cases, a different access-token is being used to run the elevated/escalated program, and the access-token has a different DOS device namespace from the access-token that you were using in the parent process that initiated the start of the elevated/escalated program.

Elevation

In the case of elevation, the restricted token & the full admin token can be told to share the same DOS device namespace by making a change in the registry. This is possible because the 2 tokens belong to the same logon session [the same security context]. Refer to the TechDB article http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/Vista+DiskScan~Issue.txt for more information about the registry modification. Please note that this change is global, as it affects the entire system, and it requires a reboot for it to take effect.

Escalation

In the case of escalation, the restricted token & full admin token belong to entirely different security contexts, and thus they cannot ever share the same DOS device namespace.

Ideally, you should be using UNC paths and not mapped drive letter paths when launching a program via elevation. Since the same security context is being used, the full admin will have the same identity as the restricted token, and this applies to all authenticated connections to eDirectory & Novel Servers. This means that the program running elevated will still be able to access the UNC paths.

In the case of a program running via escalation, the program is in a separate security context from its parent process, and it doesn't share any of the Novell Client environment information regarding authenticated connections to eDirectory & Novel Servers. This means that the escalated program does not have any identity in the Novell environment and that it would have to perform authentication before it could access any eDirectory/Novell resources.


Even More

The UAC pop-up for elevation/escalation is the clue as to what is going on.

Launch a command prompt window normally by clicking on the icon for it. Then, launch a 2nd command prompt window by right-clicking on the icon and then clicking on "run as administrator..." Please note that you now have 2 command prompt windows open, and one of them will say "Administrator" at the end of the window title.

From the non-elevated command prompt, run your script, acknowledge the UAC elevation/escalation prompt, and allow it to make the call to wntAddDrive(). After the script successfully runs and terminates, run a "NET USE" command in each of the command prompt windows. You will see no drive mapped in the "normal" window, but in the one that is running elevated, you will see the mapped drive letter.

What is happening is that by default, the restricted access token ["normal" level] and the administrator token ["elevated" level] have separate DOS device tables in memory, so that drive mappings made by an elevated process are not shared with those made by a normal process.

You either need to change your WinBatch script's UAC Manifest to specify running "as invoker" instead of "as administrator", or you need to make a registry change to allow both restricted & administrator access tokens under UAC to share a single DOS device table.


Windows 8 Notes:

It gets particularly tricky on Windows 8 when you are logged on as an administrator with the UAC prompt turned off and attempt to map a network drive. This is because applications default to run with medium integrity level on Windows 8 even when UAC is off. The only exception being that if the application is manifested to run as an administrator, it will run at high integrity level. If you try to execute a '.wbt' file, it may not be able to see a drive even though you just mapped it. The .wbt file will be running at high integrity level because WinBatch.exe is manifested to run as an admin and you will more likely than not have been at the medium integrity level when you mapped the drive using a cmd prompt or the Explorer shell.
Article ID:   W18316
Filename:   Mapped Drives Issue with UAC.txt
File Created: 2017:07:28:13:02:44
Last Updated: 2015:08:25:10:19:46