|
     |
When access to resources on Windows network from Tectia Server's logon session is needed:
Use the password authentication method to achieve the most benefits. If you use two-factor authentication with Radius or SecurID, use it together with password authentication.
It is possible to log into a local or domain account. The remote computer on Windows network can be in the domain, but that is not required.
When computers on Windows network of Tectia Server are in the same domain with the SSH server, you can try using also other authentication methods that do not involve native Windows account credentials. Tectia Server uses Microsoft S4U2Self (Service-for-User-to-Self) method to obtain the user's access token. This method must be used together with constraint delegation of authentication configured on your domain controller for specific resources that are going to be accessed.
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 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:
It is important to remember that a user who logs on to a Windows server via Tectia 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 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 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 user name 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 user name 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 Server using an authentication method that does not use the user's Windows user name and password:
Tectia Server logs the user on to the system without providing the user's password. Currently, Tectia 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 Server's own authentication package SSHDAP is used.
Tectia 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.
Domains with Windows Server 2003 or newer domain functional level 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 Server is using this service to obtain the user's access token without providing a password. These Kerberos extensions allow users in domains with Windows Server 2003 or newer domain functional level 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.
When tasks involving access to Windows network resources from Tectia Server's logon session are done interactively, it is usually possible to configure Tectia Server to include password authentication.
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.
The command for working with network shares in Windows console is net use. When John Brown from our earlier example logs on to his company's SSH jump server using password authentication, the output of net use will look as follows:
C:\Users\johnb>net use New connections will be remembered. Status Local Remote Network ------------------------------------------------------------------------------- OK N: \\server1\share1 Microsoft Windows Network The command completed successfully.
Now he can access the data on this disk:
C:\Users\johnb>N: N:\>dir Volume in drive N is share1 Volume Serial Number is 1D01-2B83 Directory of N:\ 31.03.2009 14:56 <DIR> johns_treasure 02.04.2009 10:15 8 johns_test.txt 12.05.2009 16:22 2 315 important_data.txt 17.06.2009 12:46 13 061 important.log
However, when he chooses to log on to the same server using the public-key authentication method, his experience may be as follows:
C:\Users\johnb>net use New connections will be remembered. Status Local Remote Network ------------------------------------------------------------------------------- Unavailable N: \\server1\share1 Microsoft Windows Network The command completed successfully.
Now his network drive is completely unavailable:
C:\Users\johnb>N: The system cannot find the drive specified.
Other times using the public-key authentication he will get the drive letter assigned:
C:\Users\johnb>net use New connections will be remembered. Status Local Remote Network ------------------------------------------------------------------------------- OK N: \\server1\share1 Microsoft Windows Network The command completed successfully. C:\Users\johnb>N:
His files are still inaccessible, though:
N:\>dir Volume in drive N is share1 Volume Serial Number is 1D01-2B83 Directory of N:\ File Not Found
Tectia Server attempts to restore all of the user's persistent network connections. This is done just before starting the interactive terminal session's prompt. The operation will succeed if the user provided credentials to his Windows user account. It also succeeds if all of the following is true (see Virtual Folders Defined on Windows Network Shared Folders Are Not Available on Tectia Server on Windows):
If Tectia Server is running on Windows Server 2008 or newer.
The computer where Tectia Server is running is a member of Windows Server 2003 or newer domain functional level .
The user account johnb is a domain account in the same domain (or other domain with bi-directional trust).
The share being accessed is on a computer in the same domain and constrained delegation of credentials has been set up for this share on the domain controller.
However, even if the restoration of network connections failed as illustrated above, John can still try to re-connect to the drive manually since he is using the terminal session interactively. This time Windows OS will ask him to provide the user credentials of the server he is trying to access, after which John can use his files freely:
C:\Users\johnb>net use New connections will be remembered. Status Local Remote Network ------------------------------------------------------------------------------- Unavailable N: \\server1\share1 Microsoft Windows Network The command completed successfully. C:\Users\johnb>N: The system cannot find the drive specified. C:\Users\johnb>net use h: \\server1\share1 The password is invalid for \\server1\share1. Enter the user name for 'server1': johnb Enter the password for filer: ****************** The command completed successfully. C:\Users\johnb>N: N:\>dir Volume in drive N is share1 Volume Serial Number is 1D01-2B83 Directory of N:\ 31.03.2009 14:56 <DIR> johns_treasure 02.04.2009 10:15 8 johns_test.txt 12.05.2009 16:22 2 315 important_data.txt 17.06.2009 12:46 13 061 important.log
Tectia Server will attempt to restore persistent network connections of the user logged on the same way also when it starts the SFTP subsystem (sft-server-g3). In addition to this, it will also attempt to restore connections to virtual folders that reside on network shares. However, at this point the client program communicates with the server using SFTP protocol. This protocol does not include any support for challenge response authentication because it is designed to be used over a connection that has already been authenticated. In this case the success of Windows network connection attempt depends solely on the credentials provided during the initial authentication to SSH server. Therefore, the only reliable alternative in this case is to use password authentication that uses credentials of the native Windows account.
Example: John Brown forgot to copy his test results
from the folder belonging to the test account he uses for testing.
It is on \\server3\test_share and the only user that has
access to the file is testuser. It is possible to access
the file from the user's own terminal logon session on SSH jump server:
C:\Users\johnb>net use \\server3\test_share <testuser's password here> /USER:testuser The command completed successfully. C:\Users\johnb>dir \\server3\test_share Volume in drive \\server3\test_share has no label. Volume Serial Number is 1D01-2B83 Directory of \\server3\test_share 13.12.2011 17:15 <DIR> . 13.12.2011 17:15 <DIR> .. 02.04.2009 10:15 8 192 test_results.txt
However, it will only work if John logs on to the SSH jump server using his credentials (user name and password).
An alternative way to access the file would be to log on to SSH jump server as testuser using his credentials and just type:
C:\Users\testuser>net use \\server3\test_share The command completed successfully. C:\Users\testuser>dir \\server3\test_share Volume in drive \\server3\test_share has no label. Volume Serial Number is 1D01-2B83 Directory of \\server3\test_share 13.12.2011 17:15 <DIR> . 13.12.2011 17:15 <DIR> .. 02.04.2009 10:15 8 192 test_results.txt
When the computer to be reached is not a member of the same domain as the computer with SSH server, the shares on it can still be accessed. However, the access will only work if the Windows native user account credentials are used for authentication and if the user account with the same name and password exists on the remote machine.
Accessing shares as a user with a different name works in an interactive session as described in Accessing Network Shares Using Another User's Account.
| |