v7.9 Kerberos GSSAPI / SSPI Testing Binaries

Kerberos GSSAPI / SSPI Testing Release

This release is compiled with the changes identified in pull request PowerShell#360 as well as all other unreleased changes that have been committed to the main branch as of this release date. In short, this release enables Kerberos authentication which should provide an experience similar to that of the public key authentication but without the need to setup keys. Furthermore, using Kerberos authentication with delegation (discussed more below) can overcome the ability to access resources on other systems from the SSH server. Kerberos authentication is only applicable in an Active Directory environment.

The installer provided in the zip files will automatically set "GSSAPIAuthentication yes" in the default C:\ProgramData\ssh\sshd_config file. If you simply wish to change out the already-installed binaries with those from this release, then you will need to manually append this setting to your sshd_config file. The SSH client then needs to be launched using the '-K' flag to indicate it should attempt GSSAPI-based authentication.

Using Kerberos Delegation

Using Kerberos delegation, the authenticated user can access resources on other systems that are remote to the server that SSH is running on. For example, if I SSH into a server and want to access an administrative file share on a client from the server SSH session. Without delegation, attempting to access remote resources will typically result in an 'Access Denied' message for a user that normally would have permissions outside of the SSH session. While Kerberos delegation solves this problem, setting up Kerberos delegation properly can be difficult.

Several types of Kerberos delegation are described below. In addition to the conditions and restrictions discussed for each type, no user account with the 'Account is sensitive and cannot be delegated' attribute set under the user's 'Account' tab will ever be able to delegate; this setting is not set by default but is often recommend to be set by security professional on highly privileged accounts.

• Unconstrained Delegation: This is configured by going to the computer object that runs SSH server in Active Directory, selecting the delegation tab and choosing 'Trust this computer to delegation to any service (Kerberos only)". However, unconstrained delegation will not work when the client is running Credential Guard. It also does not work across domain or forest boundaries.

• Constrained Delegation: This is configured by going to the computer object running the SSH server in Active Directory, selecting the delegation tab, and choose 'Trust this computer to delegation to specified services only". Choose the "Use Kerberos only" sub option and then choose 'Add...'. Browse and select the computer(s) that the SSH user should be able to access remotely. You will be prompted to select the services that need to be accessed remotely such as "HOST" (used for file sharing). It does not work across domain or forest boundaries.

• Resource Based Kerberos Constrained Delegation: This is configured by making a change on each computer object (or user object if the service is hosted by a user) that the SSH server will be accessing on behalf of the user.
  The Set-ADUser/Set-ADComputer cmdlets with the PrincipalsAllowedToDelegateToAccount parameter is used to do this configuration. (More information to be provided at a later time).