Environment
Novell Client 2 SP2 for Windows Vista
Novell Client 2 SP2 for Windows Server 2008
Novell Client 2 SP2 for Windows 7
Novell Client 2 SP2 for Windows Server 2008 R2
Novell Client 2 SP2 for Windows 7
Novell Client 2 SP2 for Windows Server 2008 R2
Situation
1) When copying a folder from a local drive to a Novell volume, errors may appear, such as:
"<path> refers to a location that is unavailable."
"You'll need to provide administrator permission to copy to this folder <name of folder>
2) An .inf installation file will not run/copy files if executed from a Novell mapped drive
Resolution
For members of the Administrators group:
Beginning with Novell Client 2 SP2 for Windows (IR5), the Novell Client will respect the "EnableLinkedConnections" policy such that drive mappings will be recognized by both elevated and non-elevated sessions, even when UAC is enabled.
Either with or without the Novell Client, the EnableLinkedConnections policy only "links" the elevated & non-elevated sessions created for an Administrators member. In this scenario, it is not necessary to actually prompt for credentials when elevating; both Windows logon sessions are for the exact same user, it's just that one has been filtered to have only normal Users group permissions instead of full Administrators permissions.
For non-Administrators group users:
The "EnableLinkedConnections" policy does not affect non-Administrators group users. When a non-Administrators member wants to run an application elevated, Windows UAC must prompt for credentials since the requesting user isn't a member of Administrators themselves. In this case the elevated Windows logon session is created "as some other user entirely." The EnableLinkedConnections policy cannot "make the mapped drives the same in these two sessions", because the two different Windows users don't even necessarily have access to the same shares.
For more information on the "EnableLinkedConnections" policy, see the Microsoft Technet article "Some Programs Cannot Access Network Locations When UAC is Enabled".
Cause
This behavior is a result having User Account Control (UAC) enabled on the machine.
See Microsoft KB Article 2019185, "Copying files from a mapped drive to a local directory fails with error “Location is not available” if UAC is enabled" for further information.
See Microsoft KB Article 2019185, "Copying files from a mapped drive to a local directory fails with error “Location is not available” if UAC is enabled" for further information.
See Microsoft KB Article 937624, "Programs may be unable to access some network locations after you turn on User Account Control in Windows Vista or newer operating systems" for further information.
Additional Information
Enabling User Account Control has the following effect:
For members of the Administrators group: it creates "admin approval mode" behavior in which the Administrators member primarily logs on with a filtered version of the user token which actually only grants Users group rights, and then also separate logon session using an "elevated" (unfiltered) version of their user token. This permits Administrators to simply "approve" running an application elevated without having to provide credentials; while also isolating most of the interactive user's processes to run with only Users group rights.
For non-Administrators group users: they login with just a single logon session using their normal non-Administrators rights. If and when they ever need to run an application "elevated", they are prompted for credentials of an Administrators
member. Windows then creates a separate logon session using those credentials; similar to having used RUNAS.EXE with the administrator credentials, or logging in on a separate terminal session with the administrator credentials.
The fact that Windows is using separate logon sessions here has a very distinct purpose and effect:
The intention is to isolate all the applications which are running with full Administrators rights from those applications which either don't require or aren't permitted to run with full Administrators rights.
This actually includes your network connections; not just because Windows UAC thought that would be a good idea as part of the isolation, but because Windows network connections have always been managed and segregated at Windows logon session boundaries. This isolation is what keeps multiple concurrent terminal sessions or fast-user-switching sessions from stepping on each other, etc.
In both the "admin approval mode" and normal users' usage of UAC, the logon session with full Administrators rights has separate network connections, separate drive mappings, separate authentication information, etc. Just because the non-elevated logon session had a particular drive mapped or was authenticated to a particular network resource before elevating doesn't make that resource available in the elevated logon session. The elevated logon session "starts blank" (no network connections, no mapped drives, etc.) just like the non-elevated logon session did.
What is happening during the copy operation:
Even when simply copying from one folder on the local machine to another, if the source or destination folder is going to require Administrators rights for successful access, the Windows 6.x Explorer / SHELL32.DLL detects this and
prompts for elevating in order to successfully achieve access. (Whether that means admin approval mode, or prompting for Administrators credentials to use.)
In the case of the source or destination path being a network resource, the unexepected ramification this can have is that even though elevating did successfully achieve access to the secured path on the local machine, the fact that Windows is now using a different logon session (the elevated logon session) means that the original network connection is now no longer available.
What happens in the elevated logon session for that case is the same thing that happens in a non-elevated logon session when you're not already connected to the remote network resources: Either access to the path fails, or for some cases you should be prompted for credentials to authenticate to the remote resource. (Again, since you already successfully authenticated to the remote resource once in the non-elevated logon session before trying to copy a file to a secure local folder using the elevated logon session.)
Example:
WITHOUT the Novell Client installed, login to Windows as an Administrators member user.
Now use Windows Explorer to access a UNC path of a remote Windows share (CIFS/SMB) which requires different credentials than you used to login to the local Windows machine. i.e. Access to the remote share isn't "transparent", and you are prompted for Windows credentials to use on the remote machine before successfully accessing the Windows share.
Now attempt to copy files from that UNC path into a local secured directory which will require full Administrators rights in order to have write access to the directory.
You will be prompted to elevate (in order to access the target path), but then the copy attempt fails with "Folder Access Denied. You don't have permission to copy files to this location over the network. You can copy files to the Documents folder and then move them to this location."
Note there are other cases, such as when launching a program from a network path which also requires elevation, where you can end up being prompted to authenticate (again) to the remote Windows server. This prompt occurs because
in the elevated session, this is the first authetication to the remote server that has ever occurred. You're being prompted for credentials on the remote path for the same reason you can be prompted for credentials even in a normal session when you're not already authenticated to the remote resource.
Note that "different credentials than you logged into the local Windows machine with" was key to demonstrating the difference, since Windows standard behavior is to attempt authenticating to the remote Windows server using the same
credentials as you logged into the local Windows machine with. That type of automatic login doesn't apply in the eDirectory case since you didn't login to the local Windows machine with eDirectory credentials, only Windows
credentials.
From this example, it can be seen that this condition is true even outside of the Novell Client. The specific message may be different, but the root cause is the same.
For members of the Administrators group: it creates "admin approval mode" behavior in which the Administrators member primarily logs on with a filtered version of the user token which actually only grants Users group rights, and then also separate logon session using an "elevated" (unfiltered) version of their user token. This permits Administrators to simply "approve" running an application elevated without having to provide credentials; while also isolating most of the interactive user's processes to run with only Users group rights.
For non-Administrators group users: they login with just a single logon session using their normal non-Administrators rights. If and when they ever need to run an application "elevated", they are prompted for credentials of an Administrators
member. Windows then creates a separate logon session using those credentials; similar to having used RUNAS.EXE with the administrator credentials, or logging in on a separate terminal session with the administrator credentials.
The fact that Windows is using separate logon sessions here has a very distinct purpose and effect:
The intention is to isolate all the applications which are running with full Administrators rights from those applications which either don't require or aren't permitted to run with full Administrators rights.
This actually includes your network connections; not just because Windows UAC thought that would be a good idea as part of the isolation, but because Windows network connections have always been managed and segregated at Windows logon session boundaries. This isolation is what keeps multiple concurrent terminal sessions or fast-user-switching sessions from stepping on each other, etc.
In both the "admin approval mode" and normal users' usage of UAC, the logon session with full Administrators rights has separate network connections, separate drive mappings, separate authentication information, etc. Just because the non-elevated logon session had a particular drive mapped or was authenticated to a particular network resource before elevating doesn't make that resource available in the elevated logon session. The elevated logon session "starts blank" (no network connections, no mapped drives, etc.) just like the non-elevated logon session did.
What is happening during the copy operation:
Even when simply copying from one folder on the local machine to another, if the source or destination folder is going to require Administrators rights for successful access, the Windows 6.x Explorer / SHELL32.DLL detects this and
prompts for elevating in order to successfully achieve access. (Whether that means admin approval mode, or prompting for Administrators credentials to use.)
In the case of the source or destination path being a network resource, the unexepected ramification this can have is that even though elevating did successfully achieve access to the secured path on the local machine, the fact that Windows is now using a different logon session (the elevated logon session) means that the original network connection is now no longer available.
What happens in the elevated logon session for that case is the same thing that happens in a non-elevated logon session when you're not already connected to the remote network resources: Either access to the path fails, or for some cases you should be prompted for credentials to authenticate to the remote resource. (Again, since you already successfully authenticated to the remote resource once in the non-elevated logon session before trying to copy a file to a secure local folder using the elevated logon session.)
Example:
WITHOUT the Novell Client installed, login to Windows as an Administrators member user.
Now use Windows Explorer to access a UNC path of a remote Windows share (CIFS/SMB) which requires different credentials than you used to login to the local Windows machine. i.e. Access to the remote share isn't "transparent", and you are prompted for Windows credentials to use on the remote machine before successfully accessing the Windows share.
Now attempt to copy files from that UNC path into a local secured directory which will require full Administrators rights in order to have write access to the directory.
You will be prompted to elevate (in order to access the target path), but then the copy attempt fails with "Folder Access Denied. You don't have permission to copy files to this location over the network. You can copy files to the Documents folder and then move them to this location."
Note there are other cases, such as when launching a program from a network path which also requires elevation, where you can end up being prompted to authenticate (again) to the remote Windows server. This prompt occurs because
in the elevated session, this is the first authetication to the remote server that has ever occurred. You're being prompted for credentials on the remote path for the same reason you can be prompted for credentials even in a normal session when you're not already authenticated to the remote resource.
Note that "different credentials than you logged into the local Windows machine with" was key to demonstrating the difference, since Windows standard behavior is to attempt authenticating to the remote Windows server using the same
credentials as you logged into the local Windows machine with. That type of automatic login doesn't apply in the eDirectory case since you didn't login to the local Windows machine with eDirectory credentials, only Windows
credentials.
From this example, it can be seen that this condition is true even outside of the Novell Client. The specific message may be different, but the root cause is the same.