Thursday, May 18, 2006
Firstly, you should limit maximum number of clients which can connect to server simultaneously. This is done by modify registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PowerShellRemoting\Parameters]Default value is 10. Given 256MB memory is standard configuration for desktop PC, this number is more than enough if you decided to login to your desktop from home network. You can definitely increase this number if you have more clients but remember each runspace will allocate quite a few of memory. So do some experiment and calculation then you can find a reasonable number.
Secondly, you should limit maxium number of clients which can connect to server simultaneously from Same IP address. This is done by modify registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PowerShellRemoting\Parameters]Default value is 2. You can also change that but you don't want all your available slots of connection were occupied by clients from same computer.
Thirdly, you may want to limit which user can login from which IP address. This is done by modify
%Program Files%\PowerShell Remoting\user.xml
Default installation only allow user in Administrators group login from localhost. So you have to have your own user.xml before you can login from another IP. If user.xml file parse error occorred when start service, default policy will be loaded. If you can't login, check log file or EventLog for details of parse error.
User.xml file contain information about your user access control list. It has SEVEN tags:
- <NetworkACL>: container of one or more access control entry (<NetworkACE>)
- <NetworkACE>: access control entry container of <Account>, <Access> and <IPRange>
- <Account>: Valid Group or User
- <Access>: Allow / Deny
- <IPRange>: container of <IP> and <Subnet>
- <IP>: IPAddress. 0.0.0.0 for any IP, 127.0.0.1 for localhost, 192.168.0.2 etc. IPv6 string should be fine, but I have not been able to test it.
- <Subnet>: IPv4 subnet. 192.168.0.0/255.255.255.0 or CIDR like format 192.168.0.0/24.
As you can probably already figured it out : After user provide credential and got a token (WindowsIdentity), PowerShell Remoting will try to match User/Group and IP range in records of access control list. If no record was found, access is denied. If a records match User/Group and IP range were found, PowerShell Remoting will assess access in following order:
User Deny > User Allow > Group Deny > Group AllowFor example: if client were a privileged user (Administrators group) from 192.168.0.2, but there were only one record which wanted to deny access of Users group from subnet 192.168.0.0/255.255.255.0. Then access from this client will be denied because any user belongs to Administrators group also belongs to Users group and 192.168.0.2 belongs to subnet 192.168.0.0/255.255.255.0.
After you logged in and get a PowerShell prompt, you can check $UserACL for serialized access control list.
Right now, subnet parsing and match could be buggy. So tell me if you found it did not act as expected.
These changes could make it more difficult to start using PowerShell Remoting. But I believed that you will like them later on. Remember, if you make any changes to previous setting, you will have to restart service to make them take effect.
Stop-Service PowerShellRemotingThere is also some exciting new feature:
- PowerShell Remoting Client becomes a PSSnapin now. So installation become usier. Just run install.ps1 in client folder and invoke Start-RemoteHost, you are on you way to your remote shell.
- Ctrl+C Ctrl+Break support.
- You will find out that information written in log file has been dramatically reduced because I am going to swith to EventLog in later verion.
dir c:\windows\system32And press Ctrl+C to cancel it. If you don't want to handle Ctrl+C, you can set
$RemotingClient.CanHandleCancelKey = $falseBut you probably do not want to do that.
Ctrl+Break will also quit PowerShell Session. So Use it with caution.
Oes Tsetnoc | Semangat Mengembalikan Jati Diri Bangsa
Links to this post: