none
Remoting with a non admin account - would like to run get-childitem against remote share

    Întrebare

  • Hi,

    I have configured PS remoting on a machine external to my environment, the external host is part of a domain.

    The host is running exchange 2010, I have configured RBAC role groups and am able to issue commands against the remote machine once I have configured a remote session after creating a persistent remote session.

    I am authenticating to the remote host with a non administrative account.

    What I would like to also do is run get-childitem on the remote machine either via invoke-command or using a interactive remote session.

    Unfortunately at the moment, when I run the command, it returns an error along the lines of "cannot find this cmdlet" - I guess this means that the user I have authenticated the remote session with does not have access to run these built in commands?

    I am using the script block when running invoke-command, so assume ok. Also, I can invoke-command on a exchange cmdlet I know the user has access to via RBAC.

    So basically I would just like to know how I can get access to the get-ChildItem cmdlet for the non admin user.

    Any assistance would be appreciated.

    Thanks
    Matthew

    15 martie 2012 12:59

Răspunsuri

Toate mesajele

  • Hi,

    One other thing, I actually need to run the get-childitem on the remote machine and then pipe this into a exchange specific command to import PST files into end user mailboxes. I dont think the new-psdrive cmd will work in this case.

    Thanks
    Matthew

    15 martie 2012 13:02
  • I don't think your problem has anything to do with permissons.  Can you enter a PSSession to the computer, and issue a gci?

    Grant Ward, a.k.a. Bigteddy

    What's new in Powershell 3.0 (Technet Wiki)

    15 martie 2012 13:27
  • Hi Grant,

    This does not work.

    If I issue a get-command in a interactive remote session I dont see the get-childitem as an available command.

    Thanks
    Matthew

    15 martie 2012 19:07
  • If that's an Exchange server, and you're connecting to an Exchange Management session, it only provides the Exchange-specific cmdlets. 

    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "


    • Editat de mjolinor 15 martie 2012 20:42
    15 martie 2012 20:36
  • If that's an Exchange server, and you're connecting to an Exchange Management session, it only provides the Exchange-specific cmdlets. 

    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "


    Are you sure of that? What would be the point of having access to the exchange cmdlets but not to commandlets such as, for example, foreach-object? or exit-pssession?


    Al Dunbar

    15 martie 2012 20:51
  • You establish that session and then do an import-session to import the functions from there into your local session.  There are actually no cmdlets in that session - they are all proxy functions tailored to your RBAC role group memberships. 

    When you use the functions in your local session, the command is passed to the remote session and the results (which are de-serialized objects) returned and passed back to your local session.  Everything except those fuctions is from your local session, running in the context of that session. 

    If you enter that pssession, the only thing you can do there is run those proxy functions. You can't even create a variable to store the results in.

    Consider what it would mean for a hosting provider if an admin at a domain they're hosting for actually could enter that pssession and start accessing shares and machines in that network, or running cpu or memory intensive scripts in that session.


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "




    • Editat de mjolinor 15 martie 2012 21:28
    15 martie 2012 21:19
  • Hi,

    With that said, it does make sense as to why it wont work.

    Still, is there any way at all to allow the remote session the ability to run the GCI command?

    Thanks
    Matthew

    16 martie 2012 01:58
  • When you say you configured ps remoting on that machine, do you mean independently of the remoting setup that would have be done by the Exchange installation?

    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

    16 martie 2012 11:15
  • Hi,

    Nothing extra was done on the target host apart from running "Set-PSSessionConfiguration -Name Microsoft.PowerShell -showSecurityDescriptorUI" to allow the non admin user remote PS access.

    If there is no way to do this then I guess not much else can be done.

    Thanks
    Matthew

    17 martie 2012 07:49
  • On the target machine, open Powershell elevated (as Administrator), and run the following command:

    Enable-PSRemoting

    Then follow the prompts.


    Grant Ward, a.k.a. Bigteddy

    What's new in Powershell 3.0 (Technet Wiki)

    17 martie 2012 07:58
  • Hi,

    Just checking in to see if the suggestions were helpful. Please let us know if you would like further assistance.

    Have a great day!

    Best Regards,
    Yan Li

    TechNet Subscriber Support

    If you areTechNet Subscriptionuser and have any feedback on our support quality, please send your feedbackhere.


    Yan Li

    TechNet Community Support

    20 martie 2012 01:53