WinRS/WinRM can't access UNC path using CredSSP (Multi-Hop, Double-Hop)

[t0mso]

Hi

I am trying to send a WinRS command from clientX to server1, which inlcudes a UNC path reference to a shared folder on server2. I understood that therefore I need to perform credential delegation from clientX to server1 ("double-hop"). Both clientX and server1 actually have access to that shared folder on server2.

clientX -> server1 -> server2

I followed all available instructions regarding WinRM and CredSSP configurations, like this: [Multi-Hop Support in WinRM - Win32 apps and it appears to me that everything was set up as intended.

• hostname of clientX is 'clientX' (acquired from cmd command 'hostname')
• full computer name of clientX is 'clientX' (acquired from control panel > system)
• user domain of clientX is 'CLIENTX' (acquired from cmd command 'echo %userdomain%')
• hostname of server1 is 'server1' (acquired from cmd command 'hostname')
• full computer name of server1 is 'server1' (acquired from control panel > system)
• user domain of server1 is 'SERVER1' (acquired from cmd command 'echo %userdomain%')
• the unc path on server2 is \SERVER2\sharedF\test

on server1, I can successfully run the command:

dir \\SERVER2\sharedF\test

on clientX, I can aswell successfully run the command:

dir \\SERVER2\sharedF\test

on clientX, I can successfully run the command:

winrs.exe -r:http://SERVER1:5985 -u:adminOnserver1 -pass4server1 "dir c:"

on clientX, I fail to run the command:

winrs.exe -r:http://SERVER1:5985 -u:adminOnserver1 -pass4server1 "dir \\SERVER2\sharedF\test"

as I receive the error message "access is denied". And that is the problem.

on clientX, the power shell command

Get-WSManCredSSP

returns:

The machine is configured to allow delegating fresh credentials to the following target(s): wsman/SERVER1
This computer is not configured to receive credentials from a remote client computer.

on clientX, the cmd command

winrm get winrm/config

returns:

Config
MaxEnvelopeSizekb = 500
MaxTimeoutms = 60000
MaxBatchItems = 32000
MaxProviderRequests = 4294967295
Client
NetworkDelayms = 5000
URLPrefix = wsman
AllowUnencrypted = true
Auth
Basic = true
Digest = true
Kerberos = true
Negotiate = true
Certificate = true
CredSSP = true
DefaultPorts
HTTP = 5985
HTTPS = 5986
TrustedHosts = 200.0.0.145,CLIENTX,200.0.0.159,SERVER1
Service
RootSDDL = O:NSG:BAD(A;;GA;;;BA)(A;;GR;;;IU)S(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
MaxConcurrentOperations = 4294967295
MaxConcurrentOperationsPerUser = 1500
EnumerationTimeoutms = 240000
MaxConnections = 300
MaxPacketRetrievalTimeSeconds = 120
AllowUnencrypted = false
Auth
Basic = false
Kerberos = true
Negotiate = true
Certificate = false
CredSSP = false
CbtHardeningLevel = Relaxed
DefaultPorts
HTTP = 5985
HTTPS = 5986
IPv4Filter = *
IPv6Filter = *
EnableCompatibilityHttpListener = false
EnableCompatibilityHttpsListener = false
CertificateThumbprint
AllowRemoteAccess = true
Winrs
AllowRemoteShellAccess = true
IdleTimeout = 7200000
MaxConcurrentUsers = 2147483647
MaxShellRunTime = 2147483647
MaxProcessesPerShell = 2147483647
MaxMemoryPerShellMB = 2147483647
MaxShellsPerUser = 2147483647

on server1, the power shell command "Get-WSManCredSSP" returns:

The machine is not configured to allow delegating fresh credentials.
This computer is configured to receive credentials from a remote client computer.

on server1, the cmd command

winrm get winrm/config

returns:

Config
MaxEnvelopeSizekb = 500
MaxTimeoutms = 60000
MaxBatchItems = 32000
MaxProviderRequests = 4294967295
Client
NetworkDelayms = 5000
URLPrefix = wsman
AllowUnencrypted = true
Auth
Basic = true
Digest = true
Kerberos = true
Negotiate = true
Certificate = true
CredSSP = true
DefaultPorts
HTTP = 5985
HTTPS = 5986
TrustedHosts = 200.0.0.145,CLIENTX,200.0.0.159,SERVER1
Service
RootSDDL = O:NSG:BAD(A;;GA;;;BA)(A;;GR;;;IU)S(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
MaxConcurrentOperations = 4294967295
MaxConcurrentOperationsPerUser = 1500
EnumerationTimeoutms = 240000
MaxConnections = 300
MaxPacketRetrievalTimeSeconds = 120
AllowUnencrypted = false
Auth
Basic = false
Kerberos = true
Negotiate = true
Certificate = false
CredSSP = true
CbtHardeningLevel = Relaxed
DefaultPorts
HTTP = 5985
HTTPS = 5986
IPv4Filter = *
IPv6Filter = *
EnableCompatibilityHttpListener = false
EnableCompatibilityHttpsListener = false
CertificateThumbprint
AllowRemoteAccess = true
Winrs
AllowRemoteShellAccess = true
IdleTimeout = 7200000
MaxConcurrentUsers = 2147483647
MaxShellRunTime = 2147483647
MaxProcessesPerShell = 2147483647
MaxMemoryPerShellMB = 2147483647
MaxShellsPerUser = 2147483647

on server1, the cmd command

winrm e winrm/config/listener

returns:

Listener
Address = *
Transport = HTTP
Port = 5985
Hostname
Enabled = true
URLPrefix = wsman
CertificateThumbprint
ListeningOn = 127.0.0.1, 169.254.229.41, 200.0.0.159, ::1, fe80::5465:9195:eabb:b7e7%11, fe80::c056:f6db:8f7f:e529%9

Any ideas?

 

[DVDR_Dog]

I will warn you that has been my recent experience that Windows keeps changing the rules lately to make networking more secure. You can try this if you already haven't but even this is 4 years old.

Configuring CredSSP for use with WinRM/PowerShell

Owing to these constant changes you might try posting these questions to the official Microsoft forum. Their employees have access the current updates and can give you current info.

 

[t0mso]

I will warn you that has been my recent experience that Windows keeps changing the rules lately to make networking more secure. You can try this if you already haven't but even this is 4 years old.

Configuring CredSSP for use with WinRM/PowerShell

Owing to these constant changes you might try posting these questions to the official Microsoft forum. Their employees have access the current updates and can give you current info.

Thank you very much for your reply. Actually, I think that I stumbled across that page a few days ago. What I did is basically exactly what is written there.

I also posted this issue on the microsoft forum already, but nobody replied there.
https://learn.microsoft.com/en-us/a...-winrm-cant-access-unc-path-using-credssp-(mu

 

[DVDR_Dog]

Yeah well I feel your pain. When you try to do what used to be more or less a routine networking setup, Microsoft has put all these undocumented speedbumps under the title security patch which is more like security band-aids. The end result will probably continue to push Linux to the top of the networking pile. I don't know what's being done on the cloud DaaS side of things, part of my job is delivering those services to the customer. However it seems Microsoft has moved it's priorities to delivered services rather than email, data management and manipulation on site which used to be a cash cow for them. They may be correct but the security aspects are still an unknown and to me at least, scary.