VShell^® Subconfiguration For More Flexible Authentication

Global configuration settings can't always meet the security needs of an entire complex organization. However, with VShell's subconfiguration support, you can use different authentication levels for specific sets of users, groups, or locations.

Two examples are provided below. The first applies more stringent authentication for a group of users. The second example uses subconfiguration to differentiate authentication settings for users connecting from internal and external networks. The examples are illustrated using the Windows interface. Subconfiguration is also supported for VShell server UNIX versions, however the format is different. Information on creating subconfiguration files for UNIX can be found in the VShell server man pages.

Subconfiguration explained

As mentioned above, the subconfiguration capability of the VShell server (version 3.0 and later) allows VShell administrators to define different settings for particular users, groups, or locations.

Subconfiguration settings are specified in XML files via the VShell Control Panel Subconfiguration category, and act to override the standard settings. Only applicable settings (see below) specified in the subconfiguration XML files are overridden. Settings that are not specifically changed in the XML files retain the value specified in the Control Panel.

Five settings can currently be defined in a subconfiguration:

• authentications allowed
• authentications required
• alternate user shell
• port forwarding filter tables
• connection limit (VShell 3.8 and later)
• connection filters (VShell 3.9 and later)
• use single virtual root (VShell 3.9 and later)

Note: The AuthenticationAllowed setting can only be overridden on a location basis.

(If you would like to request additional subconfiguration settings, please contact VanDyke Software Technical Support.)

The following is the sequence of subconfiguration operations. When a connection is made, VShell reviews its location Source subconfiguration list to see if the connected location appears on the list. If the location matches a source entry, that subconfiguration is applied and takes precedence over the VShell default configuration.

When a user begins the authentication process, VShell reviews its User/Group subconfiguration list to see if that user appears on the list. If the user or group matches a User/Group entry, that subconfiguration is applied and takes precedence over any location subconfiguration as well as over the VShell default configuration.

For a more general discussion of subconfiguration, see the VShell help file.

The following is the syntax used in the XML subconfiguration file:

         
     <?xml version="1.0" encoding="utf-8" ?>
     <VShell Version="3.9">
       <AuthenticationsAllowed Type="array">
         <Item Type="string">password</Item>
         <Item Type="string">publickey</Item>
       </AuthenticationsAllowed>
       <AuthenticationsRequired Type="array">
          <Item Type="string">password</Item>
       </AuthenticationsRequired>
       <PortForwardFilterTableV2 Type="array">
         <Item Type="string">I,deny,127.0.0.1,0,Deny localhost</Item>
         <Item Type="string">N,allow,0.0.0.0/0.0.0.0,0,Default Allow All Entry</Item>
       </PortForwardFilterTableV2>
       <UserShell Type="string">C:\WINDOWS\system32\CMD.EXE</UserShell>
       <UserShellArgs Type="string">/C dir</UserShellArgs>
       <ConnectionLimit Type="dword">2</ConnectionLimit>
       <ConnectionFilterTableV2 Type="array">
         <Item Type="string">I,allow,fe80::8d96:2a99:1d2a:119d,0</Item>
         <Item Type="string">D,deny,*.sub.example.org,0</Item>
         <Item Type="string">H,deny,myhost.example.org,0,Deny connections from myhost.example.org</Item>
         <Item Type="string">N,allow,::/0,0,Default IPv6 Allow All Entry</Item>
         <Item Type="string">N,allow,0.0.0.0/0.0.0.0,0,Default Allow All Entry</Item>
       </ConnectionFilterTableV2>
       <UseSingleVirtualRoot Type="dword">1</UseSingleVirtualRoot>
    </VShell>  

Generating subconfiguration XML files

Generating the subconfiguration XML file can be done using the VShellConfig command-line utility. You will first, create a snapshot of your current VShell configuration using VShellConfig. Creating a backup will ensure that you can restore the original configuration.

To create a backup, open a command prompt by clicking the Windows Start button, and then select Run.... Type cmd, and then click OK. From the command prompt, run the following command: "VShellConfig export --include registry vshell-backup.xml" (see VShellConfig help or usage message for more export options).  This will export all current VShell server settings into the vshell-backup.xml file.

The next step is to change the authentication settings in the VShell Control Panel to match what you would like to apply in a subconfiguration file. After the authentication settings are made and the VShell Control Panel is closed, the VShell configuration will need to be exported to a file again.  This can be done as described above, only now specify a different filename: "VShellConfig export --include registry subconfiguration.xml".

Finally, open the VShell Control Panel and change the authentication settings back to what you would like to apply in the general case.

Example – subconfiguration applied per-user or per-group

In this example, the Administrator group is required to authenticate with both password and public key, while either is accepted for everyone else. Whenever someone that is a member of the Administrator group connects to VShell, the subconfiguration will override the general settings to require both password and public-key authentication.

The following XML subconfiguration file specifies that both password and public-key authentications are required:

<?xml version="1.0" encoding="utf-8"?>
<VShell Version="3.6">
  <AuthenticationsRequired Type="array">
    <Item Type="string">password</Item>
    <Item Type="string">publickey</Item>
  </AuthenticationsRequired>
</VShell>

The VShell authentication settings allow any of five authentication methods: Password, Public Key, GSSAPI (with mic), GSSAPI (key exchange), and RADIUS (keyboard-interactive).

VShell server Control Panel Authentication page – all authentication types are allowed

The User/Group Subconfigurations page defines the Administrator group and ties it to a subconfiguration XML file.

 Control Panel page for subconfiguration by user or group

Example – subconfiguration applied per location

In this example, users connecting from an external network are required to authenticate using both password and public key, while users connecting from the internal network can authenticate using either method. Whenever a connection is made to VShell, VShell checks the location definition, finds a match to the internal network, and invokes the subconfiguration XML settings to override the default settings and allow either password or public key.

The standard VShell Control Panel settings show that both password and public-key authentications are required for all users.

Control Panel Authentication page showing password and public-key authentications required for all users

Control Panel Location page identifying internal network IP address for subconfiguration

The XML subconfiguration file specifies that either password or public-key authentication is allowed.

<?xml version="1.0" encoding="utf-8"?>
<VShell Version="3.6">
  <AuthenticationsAllowed Type="array">
    <Item Type="string">password</Item>
    <Item Type="string">publickey</Item>
  </AuthenticationsAllowed>
  <AuthenticationsRequired Type="array"/>
</VShell>