GSSAPI (Generic Security Service Application Programming Interface) is a function interface that provides security services for applications in a mechanism-independent way. This allows different security mechanisms to be used via one standardized API. GSSAPI is often linked with Kerberos, which is the most common mechanism of GSSAPI.

Kerberos libraries are installed by default on Linux platforms. They are also available for most other Unix platforms, but have to be installed separately.

For Windows, GSSAPI offers integrated authentication for Windows 2000/2003 networks with Kerberos. This method utilizes domain accounts, since local accounts are not transferable across machine boundaries.

The GSSAPI authentication method has no user interface (besides configuration). It does not ask anything from the user. If something fails during GSSAPI exchange, the reason for the failure can be seen in the server event log.

To enable GSSAPI authentication on the server, the authentication-methods element of the ssh-server-config.xml file must contain an auth-gssapi element. For example:

<authentication-methods>
  <authentication action="allow">
    <auth-gssapi dll-path="path-to-gssapi-dll" />
  ...
  </authentication>
</authentication-methods>

Also other authentication methods can be allowed.

On Windows, using the SSH Tectia Server Configuration tool, GSSAPI authentication can be configured on the Authentication page. See Authentication. On Windows, the dll-path attribute is ignored. SSH Tectia Server locates the correct DLL automatically.

	Note
	SSH Communications Security does not provide technical support on how to configure Kerberos. Our support only covers SSH Tectia applications.

Special Considerations on Microsoft Windows Server 2003

When GSSAPI authentication is used on SSH Tectia Server running on Windows 2003, you need to make additional configurations for users who do not have administrator privileges. For instructions on enabling the command prompt for GSSAPI users, see Enable Shell Access for Non-privileged GSSAPI Users; and on enabling SFTP service, see Enable SFTP Service for Non-privileged GSSAPI Users

Enable Shell Access for Non-privileged GSSAPI Users

Windows Server 2003 has more restrictive permission settings. Because of that, non-privileged domain users, who are authenticated using GSSAPI, do not by default have permissions to the command prompt executable (cmd.exe) that provides the users with shell access.

In this environment, additional steps need to be taken to allow shell access for non-privileged users:

1. Go to the %WINDIR%\system32 folder (typically C:\WINDOWS\system32).

2. Right-click the cmd.exe program, and select Properties from the shortcut menu. The cmd.exe Properties dialog box opens.

3. On the Security tab, click Add to add Read & Execute rights to those domain users you want to allow to authenticate using GSSAPI.

   You can do one of the following actions:

   • Add each user separately (for example, add Domainname\username).

   • Add the NETWORK group. This will allow all users with valid domain accounts to authenticate using GSSAPI.

   • Add your own group that is a member of NETWORK and contains all users that you want to allow to authenticate using GSSAPI.

   Click OK when finished.

See also the general considerations on user name handling in User Logon Rights on Windows.

Enable SFTP Service for Non-privileged GSSAPI Users

Non-privileged domain users, who use the GSSAPI authentication on Windows Server 2003, cannot use the SFTP service automatically. In this environment, the SFTP application is not allowed to write into the event log before the relevant user group, or the users individually, have been added to the Windows access control list (ACL). To edit the ACL, follow the instructions below:

Caution

This means modifying the registry! Make sure that you back up the registry before you modify it. Make sure that you know how to restore the registry if a problem occurs. For information about how to back up, restore, and modify the registry, refer to the Microsoft Knowledge Base (for example article 256986). Serious problems might occur if you modify the registry incorrectly. Such problems might require that you reinstall the operating system! You modify the registry at your own risk.

1. On Windows, open the registry editor by clicking Start, and Run. Then type regedit, and click OK.

2. Locate and then click the following registry subkey:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\CustomSD

3. Add a new entry for the relevant users. In the entry, replace custom_SID with the user ID or group ID of an existing user group:

   (A;;0x2;;;custom_SID)

   To cover all users using groups you can use for example (A;;0x2;;;AU) where AU means all authenticated users, or (A;;0x2;;;NU) where NU means network users.

4. Exit Registry Editor, and restart the computer.