Limiting Powershell remoting to an authorized domain account

Enterprise Remoting

Enable-PSRemoting command

Enter-PSSession command

We would like to enable PS remoting on all of our domain computers so we have another management avenue available to our IT group.   However, we need to limit this ability to a single secure domain account or accounts specified in an access control list.  We need to exclude the local administrator account because the credentials for this account need to be known outside of the IT group.

I've already tried changing the logon account for the WinRM service on a test machine, but found that this requires changing the account for all other services in the same svchost group (evidently thay all must use the same account)

(see http://answers.microsoft.com/en-us/windows/forum/windows_vista-performance/error-1079-the-account-specified-for-this-service/d0f13130-f166-4524-a88e-9338963352a9)

and I don't know what the repurcussions of that would be.

Is there currently a way to use an ACL with Powershell Remoting?

Sincerely,

ge98

  • Sure, there is a way. Every Windows PowerShell remote session uses a session configuration. When you enable Windows PowerShell remoting, default configurations (Microsoft.PowerShell and Microsoft.PowerShell32 (on 64-bit system)) are registered. By default, only members of the local Administrators group can use the default session configurations. If I understand you correctly, you want to change that so that only specific user account/group can access the remoting endpoint. You can do that using the following command:

     

    PS C:\> Set-PSSessionConfiguration Microsoft.Powershell -ShowSecurityDescriptorUI

     

    That command displays a property sheet that helps you to create a new SDDL for the session configuration. The users must have at least "Execute(Invoke)" and Read permissions to use the session configuration. Restart of the WinRM service is needed as well.

  • How about programmatically rather than interactively?  We will need to perform the configuration via a login script.

  • If you can't use it interactively, there is another parameter- SecurityDescriptorSDDL.

    -SecurityDescriptorSDDL <string>

    Specifies a different Security Descriptor Definition Language (SDDL) string for the configuration.

    This string determines the permissions that are required to use the new session configuration. To use a session configuration in a session, users must have at least "Execute(Invoke)" permission for the configuration.

    If the security descriptor is complex, consider using the ShowSecurityDescriptorUI parameter instead of this one. You cannot use both parameters in the same command.

     

    SDDL are not easy to grasp, so I would recommend to set rights first with the UI (on some test machine), and then find required SDDL string and use it with -SecurityDescriptorSDDL parameter in your login script.

     

     

  • Okay, so my next adventure is to figure out how to extract, from Powershell, the SDDL I created through the GUI dialog presented by -ShowSecurityDescriptorUI. 

     

    I discovered the RootSDDL by doing this:

         get-item wsman:\localhost\Service\RootSDDL

    I then ran Set-PSSessionConfiguration Microsoft.Powershell -ShowSecurityDescriptorUI again and changed the ACL to see if the
    RootSDDL would be changed. The value of RootSDDL did not change. Do you know how I can get Powershell to show me the
    value of the SDDL that was created for the session named "Microsoft.Powershell?

     

  • Every PowerShell session configuration is registered as a plug-in in WSMan configuration:

     

    PS C:\> dir wsman:\localhost\plugin

     

    So, if you want to find SDDL for a specific plug-in (in your case Microsoft.PowerShell) you need to go a little bit deeper in WSMan configuration hierarchy:

     

    PS C:\> $pluginname = 'microsoft.powershell'

    PS C:\> (dir wsman:\localhost\plugin\$pluginname -recurse | ? {$_.name -eq 'sddl'}).value