0

On Windows, when I try to access a network location (specifically, a drive on another Linux computer being shared with Samba), it will prompt me for a username and password. What I find interesting is that if I enter the username and password and don't tick the box to remember it, then when I access the drive, I cannot open powershell or command prompt as administrator at the network drive location, but I can as non-admin:

enter image description here

set-location : Access is denied
At line:1 char:1
+ set-location '\\192.168.0.210\sambashare'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (\\192.168.0.210\sambashare:String) [Set-Location], UnauthorizedAccessException
    + FullyQualifiedErrorId : ItemExistsUnauthorizedAccessError,Microsoft.PowerShell.Commands.SetLocationCommand

set-location : Cannot find path '\192.168.0.210\sambashare' because it does not exist.
At line:1 char:1


    

  • set-location '\192.168.0.210\sambashare'
    • 

  •   + CategoryInfo          : ObjectNotFound: (\\192.168.0.210\sambashare:String) [Set-Location], ItemNotFoundException
  + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.SetLocationCommand

    

    •

However, if I restart the computer, sign in again, and then I do tick the box to remember the password, I am able to open as administrator. Similarly, if I delete the credential from the Windows credential manager, I can't open as admin, but if I restore it, then I can. In other words, it seems to be dependent on the sign-in credentials being stored in the Windows credential manager. I have been able to repeat this with other Windows machines as well.

Can somebody explain why this is? I'm on Windows 10 v1607 build 14393.

EllipticalInitial
  • 1,800

1 Answers1

0

There's two pieces that cause this behavior:

  • Set-Location has some limitations. It uses the same kind of system commands to navigate as file explorer, so when it tries to authenticate to an SMB share, it goes through the same steps (simplified):

    1. Try kerberos/saml/ntlm for the current user if available.
    2. If denied, present any saved credentials with the correct Network Address attribute.
    3. If denied, prompt the user for credentials.

    It's unable to display the credentials prompt gui like explorer, so it fails when there are no valid stored credentials saved.

  • Windows runs elevated processes in a different shell, often like a separate user. This matters because SMB connections are all user-mode in windows, unlike the common mounts in linux. This can be kind of transparent because File Explorer never runs as an elevated process.

    Non-elevated powershell sessions use the same ongoing SMB connections as explorer (including ones without saved credentials), but elevated ones cannot. This also applies to mapped drives! Elevated processes do have access to the same saved credentials though, so it can use them when trying to Set-Location.

When using powershell to access network resources, you often want to use New-PSDrive to set up the connection in your current session:

$cred = Get-Credential  ## Prompt for creds, could also load stored credentials etc.
New-PSDrive -Name Stuff -PSProvider FileSystem -Root \\Samba01\Stuff -Credentials $cred
Set-Location Stuff:
Cpt.Whale
  • 10,914