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)

NTML 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.