Windows Server TechCenter > Windows Server Forums > Windows PowerShell > Network access when using Invoke-Command or Enter-PsSession
Ask a questionAsk a question
 

AnswerNetwork access when using Invoke-Command or Enter-PsSession

  • Friday, August 21, 2009 1:13 PMRobCannon Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    I have noticed that when I am running a remote script with Invoke-Command or when I am using Enter-PsSession that I cannot access files on network shares. 

    Is there a way to have the host trust  a network share?  I have the network share in the IE list of trusted sites, which allows me to run scripts from the share when I am logged on to the computer via Remote Desktop.  I cannot find any documentation on this restriction.


    Thanks,
    Rob Cannon

Answers

  • Thursday, October 08, 2009 3:00 PMRobCannon Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    I was finally able to get CredSSL working.  It is not convinient as I have to provide my login/password everytime I use invoke-command, plus alot of extra parameters to invoke-command.


    I had to do the following on the server:
    Enable-WSManCredSSP -Role Server


    I had to do the following on the client:

    set-item wsman:localhost\client\trustedhosts -value *

    Enable-WSManCredSSP -Role Client –DelegateComputer *

    Use gpedit.msc to enable Delegating Fresh Credentials to WSMAN/*


    The following command now works (after a password prompt):

    invoke-command { dir \\isgfile02\devtools } -computer eavmainoasis02 -authentication credssp -credential turner\rcannon



    Not an elegant solution.  Is there anything else I can do to get Kerberos working?

    Thanks

All Replies

  • Friday, August 21, 2009 2:23 PMMarco ShawMVP, ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    I suspect this is related to the "double-hop" authentication issue.

    This may help:
    http://blogs.msdn.com/powershell/archive/2009/01/06/manage-winrm-settings-with-wsman-provider.aspx

    I actually think they have a more appropriate blog post on this issue, but I can't find it right now.
  • Monday, August 24, 2009 10:50 AMMervyn ZhangMSFT, ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Proposed Answer

    Hi Rob,

    You may need to configure delegation. Open ADUC, right-click the computer account of the remote system, choose Properties, switch to delegation tab, choose Trust this computer for delegation to any service (Kerberos only). For more information, please refer to the article below:

    Delegating authentication
    http://technet.microsoft.com/en-us/library/cc739740%28WS.10%29.aspx

    Thanks.


    This posting is provided "AS IS" with no warranties, and confers no rights.
  • Wednesday, August 26, 2009 12:28 PMRobCannon Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    I wasn't able to get anything working with the winrm and Credssl.

    I think the delegation might be the answer.  BUT, I very much doubt that our AD administrator will do that.  They are very against making any kind of changes (they still run Windows 2003!).  

    I hope there is another solution.  I can make any kind of change on the app servers that we manage (Windows 2008 64-bit)
  • Thursday, October 08, 2009 2:34 PMRobCannon Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    I got our network administrators to enable the Kerberos delgation (and I can verify that it is correct via ADUC).  Do you have any other ideas.  Can you get something like the following to work?

    invoke-command { dir \\isgfile02\devtools } -computer eavmainoasis02
    Cannot find path '\\isgfile02\devtools' because it does not exist.
        + CategoryInfo          : ObjectNotFound: (\\isgfile02\devtools:String) [Get-ChildItem], ItemNotFoundException
        + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand


     
  • Thursday, October 08, 2009 3:00 PMRobCannon Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    I was finally able to get CredSSL working.  It is not convinient as I have to provide my login/password everytime I use invoke-command, plus alot of extra parameters to invoke-command.


    I had to do the following on the server:
    Enable-WSManCredSSP -Role Server


    I had to do the following on the client:

    set-item wsman:localhost\client\trustedhosts -value *

    Enable-WSManCredSSP -Role Client –DelegateComputer *

    Use gpedit.msc to enable Delegating Fresh Credentials to WSMAN/*


    The following command now works (after a password prompt):

    invoke-command { dir \\isgfile02\devtools } -computer eavmainoasis02 -authentication credssp -credential turner\rcannon



    Not an elegant solution.  Is there anything else I can do to get Kerberos working?

    Thanks
  • Thursday, October 29, 2009 10:31 PMgoldfinger Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    Hi Rob,

    in my lab environment I don't have the "double-hop" authentication issue if I start the remote connection from a normal client. 
    Can you run klist with the remote shell. There should a krbtgt ticket.

    But ...
    The same will not work when I logged on a domain controller and try a connection to the client with remote share access.
    In this case I have only a http ticket not krbtgt. I don't understand this problem at the time.


    # Logged on the w7 client
    # user admin has a different password as administrator
    # remote Connection to DC (w2k8r2)
     $s = new-session -ComputerName w2k8r2.powerv2.zz -Credential powerv2\administrator
    # remote access
     icm $s {gci \\w7\c$; gci \\xp1\c$; klist}

    ...
    #0>     Client: Administrator @ POWERV2.ZZ
            Server: krbtgt/POWERV2.ZZ @ POWERV2.ZZ
            KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
            Ticket Flags 0x60a00000 -> forwardable forwarded renewable pre_authen
            Start Time: 10/29/2009 23:02:40 (local)
            End Time:   10/30/2009 9:02:40 (local)
            Renew Time: 11/5/2009 23:02:40 (local)
            Session Key Type: AES-256-CTS-HMAC-SHA1-96


    #1>     Client: Administrator @ POWERV2.ZZ
            Server: cifs/xp1.powerv2.zz @ POWERV2.ZZ
            KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
            Ticket Flags 0x60a00000 -> forwardable forwarded renewable pre_authen
            Start Time: 10/29/2009 23:05:24 (local)
            End Time:   10/30/2009 9:02:40 (local)
            Renew Time: 11/5/2009 23:02:40 (local)
            Session Key Type: RSADSI RC4-HMAC(NT)


    #2>     Client: Administrator @ POWERV2.ZZ
            Server: cifs/w7.powerv2.zz @ POWERV2.ZZ
            KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
            Ticket Flags 0x60a00000 -> forwardable forwarded renewable pre_authen
            Start Time: 10/29/2009 23:05:24 (local)
            End Time:   10/30/2009 9:02:40 (local)
            Renew Time: 11/5/2009 23:02:40 (local)
            Session Key Type: AES-256-CTS-HMAC-SHA1-96

    ----------------


    The not working case
    Logged on w2k8r2 with user administrator
    #remote Connection to Client w7
    PS C:\Users\Administrator> $s =nsn -ComputerName w7.powerv2.zz -Credential admin@powerv2.zz

    #remote share access double hop
    PS C:\Users\Administrator> icm $s {gci \\xp1\c$; klist}

    Cannot find path '\\xp1\c$' because it does not exist.
        + CategoryInfo          : ObjectNotFound: (\\xp1\c$:String) [Get-ChildItem], ItemNotFoundException
        + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand


    Current LogonId is 0:0xfb0c7

    Cached Tickets: (1)

    #0>     Client: admin @ POWERV2.ZZ
            Server: HTTP/w7.powerv2.zz @ POWERV2.ZZ
            KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
            Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
            Start Time: 10/29/2009 22:59:57 (local)
            End Time:   10/30/2009 8:59:57 (local)
            Renew Time: 1/1/1601 1:00:00 (local)
            Session Key Type: AES-256-CTS-HMAC-SHA1-96