When access to resources on Windows network from Tectia SSH Server's logon session is needed:

Example: John Brown wants to access some files on several Windows file servers in his company's private network. The only access point to his company's network is via Tectia SSH Server on a Windows server that serves as a gateway to the internal network. File share called share1 on server1 is mapped to drive N: in his user account on the SSH server host. John also wants to access share2 from server2 via UNC path. See Figure 5.15:

Figure 5.15. Accessing files on several Windows servers via Tectia SSH Server

It is important to remember that a user who logs on to a Windows server via Tectia SSH Server (or any other means) is authorized to use only that specific host. If the user wants to access other computers in the local network of the server host, the authentication to those computers must be performed first. Microsoft Windows operating systems already provide the means to minimize the number of interactive password prompts when working in network environments. Examples of this are credential cache implemented in credential manager of specific network provider and Kerberos Ticket Granting Ticket.

Tectia SSH Server does not implement the network provider itself, neither it implements the Kerberos authentication module. Therefore it does not implement any credential management integration into Windows OS as such. As a consequence, if a user wants to access network resources from Tectia SSH Server logon session, it is important to log on to SSH server using the right authentication method. Currently, the only authentication methods that can benefit from credential management of Windows network providers are the methods that use native Windows credentials (the username and password of a Windows local or domain account). These are the password authentication method (see User Authentication with Passwords) and the password submethod of keyboard-interactive authentication method (see Password Submethod).

Whenever a user who logged on to the system using a username and password tries to access network resources, the operating system will first try to use cached credentials provided during logon. If the user has access rights to such network resources, the user will be authenticated to a remote machine and access will be granted. If the user is not allowed to access the resources, then the user may be prompted to provide alternative credentials. If interaction is not possible, the attempt will fail.

The following happens when a user logs on to Tectia SSH Server using an authentication method that does not use the user's Windows username and password:

The authentication is done in this order for technical reasons. If the second step fails, the actual authentication fails (the user is denied accessing the computer) and the user is logged off immediately. This also means that the Windows OS security log will contain a successful logon-logoff sequence even for failed authentications.

Methods that do not use native Windows account's password do not pass any credentials (password) to the Windows OS. As a consequence, Windows OS has no credentials to forward when accessing resources on Windows network.

SecurID and Radius submethods of keyboard-interactive authentication are, however, most commonly used as a two-factor authentication together with normal password authentication submethod. If a method that does not use native Windows account password is used as a second authentication method together with password authentication, the actual logon session will be created using the password provided by the user and access to network resources will work the same way as if password authentication was used alone.

Windows Server 2003 domain controllers (and newer) accept a new type of Kerberos request, where the service requests a ticket from the client, presenting its own credentials instead of the client's. This extension is called Service-for-User-to-Self (S4U2Self). Tectia SSH Server is using this service to obtain the user's access token without providing a password. These Kerberos extensions allow users in Windows 2003 domain (and newer) to access some network resources. These resources must be configured on a domain controller to be trusted for delegation of credentials. See User Logon Rights on Windows, Requirements for Trusted Domain Authentication on Windows, and Virtual Folders Defined on Windows Network Shared Folders Are Not Available on Tectia Server on Windows for details.