Tectia

Accessing Resources on Windows Network from Logon Sessions Created by Tectia SSH Server

Network Resource Access from Terminal Session
Network Resource Access from SFTP Subsystem
Accessing Network Shares Using Another User's Account
Accessing Shares on a Computer That Is Not a Member of a Domain
Access to DFS Shares

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:

Accessing files on several Windows servers via Tectia SSH Server

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:

  1. Tectia SSH Server logs the user on to the system without providing the user's password. Currently, Tectia SSH Server first tries to obtain the user's access token using S4U2Self - Microsoft extension of Kerberos protocol. If this fails (it is only supported on Windows server platforms), then Tectia SSH's own authentication package SSHDAP is used.

  2. Tectia SSH Server verifies the identity of the user using its own means:

    • User's public/private key pair (or certificate) for public-key authentication method.

    • Computer's public/private key pair (or certificate) for host-based authentication method.

    • Interactive challenge response via RSA Authentication Agent for SecurID submethod of keyboard interactive method.

    • Interactive authentication using RADIUS protocol for Radius submethod of keyboard interactive method.

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.

Interactive access to network resources

When tasks involving access to Windows network resources from Tectia SSH Server's logon session are done interactively, it is usually possible to configure Tectia SSH Server to include password authentication.

Non-interactive access to network resources

When public-key authentication (or any other method that is not using Windows native passwords) is required for non-interactive scripts, password authentication can be added as a second required authentication method and the password is passed to automated scripts via command-line option.

-P, --password=PASSWORD|   Set user password. Giving the PASSWORD
            file://FILE|   directly as the argument or through an
         env://VARIABLE|   environment VARIABLE is not secure. Give
         extprog://PROG    either a path to FILE containing the password
                           or a path to external program that will output
                           the password.

Alternatively, you can specify the path to a password file or password program in Connection Broker's configuration file. This way you can use the benefits of the authentication method of your choice and access the network resources.