December 3, 2014 at 3:28 pm #20911
I'm trying to access a network drive through a remote computer using invoke-command, but the remote computer can't find it.
I've checked permissions, and I can read/write to the network drive from my local computer.
This is part of a larger objective where I want to test if a the D:\ drive exists on every computer in a lab and across campus, then I want to take that information, make a custom object, and export it (append) to a csv on the network drive.
I just found out that I can use invoke-command to run the commands remotely as a job, and when they are done running, I can Get-Job | Receive-Job and store the result in a variable, which I can then export to a csv.
But I would still like to access the network drive through a remote computer, and I'm not sure why I can't. Is this a double-hop issue?
Any insight would be appreciated,
December 3, 2014 at 3:43 pm #20912
This is absolutely a double-hop issue. The remote computer doesn't have permissions, by default, to delegate your credentials. You'll need to take a look at CredSSP.
Edit: I wanted to add more to this post in case you haven't used CredSSP in the past. The best way to get your feet wet is to use the cmdlets Get-WSManCredSSP, Enable-WSManCredSSP, and Disable-WSManCredSSP. The Get version returns two lines: The first line indicates if the machine, where the command was run, can delegate fresh credentials (think: client). The second line indicates if the machine, where the command was run, can receive fresh credentials (think: server).
In order to use CredSSP, you need to enable fresh credential delegation from your client, and enable receiving credentials on the server. In your instance, your remote computers will be your clients, and the system that holds the UNC share will be you server.
Enable-WSManCredSSP -Role Client -DelegateComputer _________ -Force
Disable-WSManCredSSP -Role Client
The "client version" of this cmdlet requires you specify a computer, or computers, that can delegate your credentials. While you can use * (for all computers), I would opt to be as specific as possible. When I've used it, I only allow credential delegation from one system and therefore my command looked like this: Enable-WSManCredSSP -Role Client -DelegateComputer computername,computername.mydomain.com -Force
I entered both the NetBIOS and DNS name because I noticed that if one was entered, and I tried the other, that it wouldn't work.
Enable-WSManCredSSP -Role Server -Force
Disable-WSManCredSSP -Role Server
Be sure to rerun Get-WSManCredSSP often so you can see how it changes as you use Enable-WSManCredSSP and Disable-WSManCredSSP.
CredSSP can also be set using Group Policy (GP). Once you're comfortable with CredSSP, you may want to enable credential delegation using GP, especially in a lab environment.
December 5, 2014 at 4:27 pm #20968
Thanks that did it!
December 10, 2014 at 5:07 am #21050
I am connecting to system B and trying to copy files from system C back down to system B using a unc path. I have setup credssp on all ends, but am still not able successfully execute my script. I am getting this error now:
[[d130280] Connecting to remote server d130280 failed with the following error message : The WinRM client cannot process the request. A computer policy does not allow the delegation of the user
credentials to the target computer. Use gpedit.msc and look at the following policy: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Delegating Fresh
Credentials. Verify that it is enabled and configured with an SPN appropriate for the target computer. For example, for a target computer name "myserver.domain.com", the SPN can be one of the
following: WSMAN/myserver.domain.com or WSMAN/*.domain.com. For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: [d130280:String] , PSRemotingTransportException
+ FullyQualifiedErrorId : -2144108125,PSSessionStateBroken[/blockquote]
The thing is that I have configured the policy. I really need help.
December 10, 2014 at 8:09 am #21056
I suspect that you don't have CredSSP set up correctly. Go to system B, the client, and run Get-WSManCredSSP. What does it return? Go to system C, the server, and run Get-WSManCredSSP. What does [i]it[/i] say?
December 10, 2014 at 9:15 am #21057
I re-read your earlier post and got it to work. I needed to enter the netbios name of the target computer on system A. i had the fqdn entered (which in theory should work perfectly), but entering the short name was the key. Thanks.
(blockquote)I entered both the (b)NetBIOS(/b) and DNS name because I noticed that if one was entered, and I tried the other, that it wouldn't work.(/blockquote)
You must be logged in to reply to this topic.