"Access is denied" for standard user accessing C:\Users\Public folders

[shaddybaddah]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest version
• Search the existing issues.

Steps to reproduce

It appears that when logged in as a standard user (ie. non-admin privileges), the session is restricted in counterintuitive and non-consistent, with a standard console run cmd prompt, way.

At a high-level, this means changing to and directory listing various folder paths. For descriptive purposes, I'm citing the most standard one, C:\Users\Public.

Expected behavior

From just a Command Prompt (running cmd):

Microsoft Windows [Version 10.0.19045.6456]
(c) Microsoft Corporation. All rights reserved.

C:\Users\shaddy>hostname
computer-msw

C:\Users\shaddy>cd C:\Users\Public

C:\Users\Public>cacls C:\Users\Public /s
C:\Users\Public "D:PAI(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICIIO;0x1301ff;;;IU)(A;;0x1200af;;;IU)(A;OICIIO;0x1301ff;;;SU)(A;;0x1200af;;;SU)(A;OICIIO;0x1301ff;;;S-1-5-3)(A;;0x1200af;;;S-1-5-3)"

Actual behavior

This is what I encounter with the latest Win32-OpenSSH, which to my surprise, upgraded the standard Windows 10 installed version (I had intended to run a secondary server on another TCP port).

From the ssh session:

Microsoft Windows [Version 10.0.19045.6456]
(c) Microsoft Corporation. All rights reserved.

shaddy@COMPUTER-MSW C:\Users\shaddy>hostname
computer-msw

shaddy@COMPUTER-MSW C:\Users\shaddy>cd C:\Users\Public       
Access is denied.

shaddy@COMPUTER-MSW C:\Users\shaddy>cacls C:\Users\Public /s   
C:\Users\Public

Access is denied.

shaddy@COMPUTER-MSW C:\Users\shaddy>sshd -V
OpenSSH_for_Windows_10.0p2 Win32-OpenSSH-GitHub, LibreSSL 4.2.0

shaddy@COMPUTER-MSW C:\Users\shaddy>

Error details

shaddy@COMPUTER-MSW C:\Users\shaddy>cacls C:\Users\Public /s   
C:\Users\Public

Access is denied.

shaddy@COMPUTER-MSW C:\Users\shaddy>

Environment data

Not using powershell

Version

OpenSSH_for_Windows_10.0p2 Win32-OpenSSH-GitHub, LibreSSL 4.2.0

Visuals

No response

[jborean93]

If you convert your SDDL string to something a big more human readable with (ConvertFrom-SddlString $sddl -Type FileSystemRights).DiscretionaryAcl you can see the following

NT AUTHORITY\BATCH: AccessAllowed (AppendData, ExecuteFile, Read, ReadAndExecute, ReadAttributes, ReadData, ReadExtendedAttributes, ReadPermissions, Synchronize, WriteData)

NT AUTHORITY\INTERACTIVE: AccessAllowed (AppendData, ExecuteFile, Read, ReadAndExecute, ReadAttributes, ReadData, ReadExtendedAttributes, ReadPermissions, Synchronize, WriteData)

NT AUTHORITY\SERVICE: AccessAllowed (AppendData, ExecuteFile, Read, ReadAndExecute, ReadAttributes, ReadData, ReadExtendedAttributes, ReadPermissions, Synchronize, WriteData)

NT AUTHORITY\SYSTEM: AccessAllowed (AppendData, ChangePermissions, Delete, DeleteSubdirectoriesAndFiles, ExecuteFile, FullControl, Modify, Read, ReadAndExecute, ReadAttributes, ReadData, ReadExtendedAttributes, ReadPermissions, Synchronize, TakeOwnership, Write, WriteAttributes, WriteData, WriteExtendedAttributes)

BUILTIN\Administrators: AccessAllowed (AppendData, ChangePermissions, Delete, DeleteSubdirectoriesAndFiles, ExecuteFile, FullControl, Modify, Read, ReadAndExecute, ReadAttributes, ReadData, ReadExtendedAttributes, ReadPermissions, Synchronize, TakeOwnership, Write, WriteAttributes, WriteData, WriteExtendedAttributes)

We can see that there is no access right for non-Administrators. The reason why this works in an interactive prompt for the standard user is due to the NT AUTHORITY\INTERACTIVE ACE present which an interactive logon will have. For SSH it will log on with NT AUTHORITY\NETWORK (because it's spawned from a network request) and thus doesn't have the required token to access this folder.

Unfortunately this is not something that SSH should can as the network logon is the correct type to use here. It's the same logon type used for things like WinRM, SMB, etc. Either you need to change the SD on the folder here to allow standard users or look at changing your logon in some impersonated thread or process.

You can use the thread way with Invoke-WithImpersonation to run in process commands under a different user context

$cred = Get-Credential
Invoke-WithImpersonation -Credential $cred -ScriptBlock {
    # Code that runs in process, like Get-Item will run
    # under the credentials specified. By default it will be
    # an INTERACTIVE token
}

You can also look at using a scheduled task to run as the same user but under a BATCH logon but this method won't work as you aren't an administrator in the first place. It's handy if you are an admin but come across something that restricts a NETWORK logon like the Windows Update API. Using New-ScheduledTaskSession

# Has various options to select the user, see the gist help
$session = New-ScheduledTaskSession
Invoke-Command $session {
    # Code here runs under the BATCH logon
}
$session | Remove-PSSession

[shaddybaddah]

Thank you for the explanation. It does make sense.

I'm not sure you can shed any light, but why does a Cygwin sshd server, running on the same Windows system (different port), allow the same user account to navigate the filesystem (seemingly) without issue? Including C:\Users\Public.

Is it this from the ssh-host-config script that installs the service (coupled with, I'm assuming, tailored (for security) credentials for each CreateProcess call)?

/usr/bin/editrights -u "${run_service_as}" -a SeServiceLogonRight

I note that logging in via Cygwin sshd the ACE list is the same, including NT AUTHORITY\NETWORK, but not including NT AUTHORITY\INTERACTIVE.

[shaddybaddah]

Apologies, I see that the ACE list does differ. On Cygwin, this:

NT AUTHORITY\NTLM Authentication Well-known group S-1-5-64-10 Mandatory group, Enabled by default, Enabled group

replaces this:

NT AUTHORITY\Cloud Account Authentication Well-known group S-1-5-64-36 Mandatory group, Enabled by default, Enabled group