Accessing Network Resources With VShell And Public-Key-Only Authentication

Previous to VShell server version 2.6.3 and Windows 2003 Active Directory, Windows file shares were not easily available to Secure Shell users who authenticate using public keys, as they are with password authentication. There are work-arounds, but they can be inconvenient or cumbersome.

However, if the VShell server and shared resources are running in a properly configured Windows 2003 Active Directory domain, file shares can be made available to accounts that authenticate using public keys. This page includes all the steps necessary to configure the domain and VShell server. Access to file shares applies to all SSH2 clients, including SecureFX, SecureCRT, and the sfxcl.exe, vsftp.exe, and vcp.exe command-line utilities.

Versions 2.6.3 and later of the VShell server support a Windows capability called Kerberos Protocol Transition (KPT), which is part of the infrastructure created by Microsoft to support Kerberos. The VShell server takes advantage of Windows KPT to create the user's credentials, but does not use Kerberos authentication.

Configuration is straightforward and occurs largely on the domain controller, where the administrator sets up constrained delegation for the systems that will handle authentication requests. VShell configuration consists entirely of ensuring that the Kerberos Protocol Transition option is enabled, which is the default for VShell 3.0 and later.

System Requirements for File Share Access Using KPT

In order to support Windows file shares via Kerberos Protocol Transition, the Windows environment must meet the following conditions:

• Systems use an Active Directory domain running at the Windows 2003 compatibility level.
• All machines involved are running Windows 2003 or newer, and are Active Directory domain members (Involved machines include the domain controller, the machine on which VShell is installed, and any machines that will provide network shares to VShell users).

Configuring Constrained Delegation on the Domain Controller

In this procedure, the following example environment is used:

• Windows 2003 domain controller named dc.somedomain.com.
• A network share named "fileshare" on fs.somedomain.com.
• Windows 2003 domain member called vshell.somedomain.com, on which VShell 2.6.3 or newer has been installed.

To configure constrained delegation, log onto dc.somedomain.com as a domain administrator and launch the Active Directory Users and Computers MMC interface (open the Start menu and select Administrative Tools):

1. In the tree view, select somedomain.com.
2. Open the Computers container.

3. Find vshell.somedomain.com in the list of computers.
4. Right-click on the entry for vshell.somedomain.com and select Properties from the context menu.
5. Click on the Delegation tab and enable the following options:

• Trust this computer for delegation to specified services only.
• Use any authentication protocol.

6. Click on the Add button.
7. When the Add Services dialog appears, click on the Users or Computers button.
8. In the Select Users or Computers dialog, enter fs.somedomain.com in the Enter the object names to select field, and click OK.

 9. Back in the Add Services dialog, select cifs from the list of Available services.
10. Click OK.

In the Properties dialog for vshell.somedomain.com, confirm that the service type you just added is listed, and that the User or Computer is fs.somedomain.com.

Configuring VShell to Use Kerberos Protocol Transition

With the VShell server and the Active Directory domain controller configured properly as described above, users should be able to authenticate to VShell on vshell.somedomain.com using public-key-only authentication and gain access to the share "fileshare" on fs.somedomain.com whether by SFTP roots or other means.