Authentication
PowerShell Server supports three authentication mechanisms: Username/Password, Public Key Authentication, and GSSAPI Authentication (NTLM/Kerberos).
Password Authentication
Clients connecting to the server need to provide a username and password combination. The credentials are then verified using Windows Authentication mechanisms to make sure they match a valid local account on the server or on a domain trusted by it.
Connecting clients are also authorized by checking membership of the specified user in a special Group. The local/domain security group used for authorization can be selected under the Security tab in the server user interface.
Public Key Authentication
If Public Key Authentication is enabled in the server user interface, connections to the server can also authenticate using the standard public key authentication mechanism supported by the SSH protocol instead of presenting a password.
With Public Key Authentication, connecting clients only need to present a username and demonstrate that they have a private key matching a public key known by the server.
When using Public Key Authentication, the server has no way to match public keys with actual Windows local/domain users, and so the username presented by the client is essentially ignored. To control which connections are allowed, the server will look into the certificate store selected in the configuration for a certificate with a public key matching the private key presented by the client connection. If one is found, the connection will be allowed; otherwise it will be denied.
It is important, therefore, to make sure that the selected certificate store does not contain certificates for people you do not want to allow access to your server.
GSSAPI Authentication (NTLM/Kerberos)
NTLM or Kerberos authentication can be enabled through the server user interface by enabling GSSAPI Authentication.
Note that when using Kerberos as an authentication mechanism, it is recommended that PowerShell Server be run as a service. When not running as a service and instead running under a user account, the default SPN (Service Principal Name) format of host/machine@domain used may result in errors. In that case, a new SPN should be registered (for instance ssh/machine) with the domain controller, and the KerberosSPN registry setting for PowerShell Server must be set. Additionally any connecting SSH client will need to be configured to use the newly defined SPN.
Impersonation
By default, when a new connection is made to the server and the user is authenticated, the server will try to impersonate the user's account so that any actions or commands the user runs on the connection are executed using the user's own credentials.
Impersonation, however, is a bit more complex and how it works depends on what specific options are configured on the server.
Impersonation and Public Key Authentication: Impersonation is never done, regardless of server settings, for connections authenticated using a Public Key. This is because the user specified in the connection is not validated or matched to a windows account. Because of this, any commands run under such a connection will always execute with the credentials of the user the server process is running as.
Interactive Logons: When authenticating connections with username/password, the server will attempt to logon the user to verify his/her credentials. By default, the server will attempt what is known as a "Network Logon", which is more secure because it restricts the authenticated credentials to accessing local resources. This means that, by default, connections will very likely be allowed access only to resources in the local machine that PowerShell Server is running and not any remote network resources (like shared folders, or other servers).
If you want authenticated connections to have access to remote network resources under the credentials used for authentication, then the server needs to authenticate users in a different way, by doing an "Interactive Logon" instead. This can be enabled at the server level by setting the UseInteractiveLogon option to 1 in the Windows registry and restarting the server process. See the configuration section for more details.
Disabling Impersonation: There are some cases where you may want to completely disable the server from impersonating the user credentials, regardless of the kind of logon used. This is necessary in cases when you're running into problems with commands or cmdlets that don't support impersonation (some will fail if impersonation is enabled and others might even crash the server). To disable impersonation, you can set the NoImpersonation option to 1 in the Windows Registry and restart the server process. See the configuration section for more details.
Process Isolation
When running as a service PowerShell Server will create a new process as the authenticated user. The PowerShell runspace will be hosted in this process. This is a configurable option on the Other tab and is enabled by default when running as a service. It is recommended to leave this option enabled when running as a service. If this option is disabled and a user connects and starts a new process, that new process will assume the identity of the service Log On account instead of the authenticated user due to the Windows APIs that PowerShell calls when a new process is started. By isolating the process this problem can be avoided. The Process Isolation option is only applicable when running PowerShell Server as a service.
The Authentication tab controls authentication options.
Below are the available options for this tab:
- Security Group: This is the name of a Windows group used for authorizing access to the server. Only users who are members of this group will be allowed access. This can be a group in the local machine or a group on the domain.
- Enable Password Authentication: This specifies whether or not Password authentication is allowed. This is enabled by default.
Note that when using Password Authentication, the recommended format for user authentication is "DOMAIN\Username". - Enable GSSAPI Authentication: This allows GSSAPI authentication for connecting clients. This is enabled by default in licensed versions.
- Supported Mechanisms: Specifies the authentication mechanism used. Possible values are All, Kerberos, NTLM. The default value is NTLM.
- Logon Type: Controls the type of logon performed by the application when attempting to authenticate users.
Possible values are:
- Network Logon: Regular network logon is performed. This is more secure, but access to remote network resources is prohibited.
- Interactive Logon: Interactive logon is performed. This is less secure, but allows access to remote network resources.
Public Key Authentication
- Enable Public Key authentication: If checked, clients will be able to authenticate using a public key instead of a username/password. When using Public Key Authentication, no impersonation of the logged on user will be done by the server, so all commands will run in the context of the user the server process is running under. Clients connecting to the server using any certificate found in the selected store will be granted access. Public Key Authentication can be configured to use either the Windows certificate store or a keys file on disk.
- Windows Store Based Public Key Authentication: When selected the client's public key is validated against
the certificates in the Windows certificate store specified by the following options:
- Store Type: Tells the server to look for client certificates in the Machine or User stores.
- Store Name: Tells the server to look for client certificates under the selected store.
- File Based Public Key Authentication: If selected, the client client's public key is validated against
a list of SSH public keys in the specified file. The file path indicated may contain the %USERNAME% macro, which will resolve to the name of the user being authenticated. The file must contain one key per line. The keys must be in the following format:
ssh-rsa AAAAB3NzaC1yc2EA...rPFBe7Pnc= rsa-key-20110822
When File Based Public Key Authentication is used you can also control the IP addresses from which the key may be used by using the "from" keyword in the SSH public keys file. Please see the following examples:
- Only accept connections using the specified public key from 192.168.1.12:
from="192.168.1.12" ssh-rsa AAAAB3NzaC1yc2EA...rPFBe7Pnc= rsa-key-20110822
- Only accept connections using the specified public key for the IP Address range 192.168.1.30 - 192.168.1.39:
from="192.168.1.3?" ssh-rsa AAAAB3NzaC1yc2EA...rPFBe7Pnc= rsa-key-20110822
- Only accept connections using the specified public key for the IP Address range 192.168.1.100 - 192.168.1.199:
from="192.168.1.1??" ssh-rsa AAAAB3NzaC1yc2EA...rPFBe7Pnc= rsa-key-20110822
- Only accept connections using the specified public key for the IP Address range 192.168.0.12 - 192.168.255.12 (must end in .12):
from="192.168.*.12" ssh-rsa AAAAB3NzaC1yc2EA...rPFBe7Pnc= rsa-key-20110822
- Only accept connections using the specified public key for the IP Address range 192.168.1.0 - 192.168.1.255 EXCEPT 192.168.1.12:
from="192.168.1.*,!192.168.1.12" ssh-rsa AAAAB3NzaC1yc2EA...rPFBe7Pnc= rsa-key-20110822
As demonstrated above, the special characters "?", "!", and "*" may be used to specify an IP address pattern that is to be matched.
Note that when File Based Public Key Authentication is enabled, similar settings to define the allowed public keys are available in the registry, as documented on the Authorized Keys page.
Note: Only IPv4 addresses are currently supported. Hostname matching and IPv6 address matching are currently not supported.
- Only accept connections using the specified public key from 192.168.1.12: