|Home||What's New||Products||Download||Purchase||Support||About Us||Contact|
SUPPORT > TIPS
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.
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:
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" ?>
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".
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:
The VShell authentication settings allow any of five authentication methods: Password, Public Key, GSSAPI (with mic), GSSAPI (key exchange), and RADIUS (keyboard-interactive).
The User/Group Subconfigurations page defines the Administrator group
and ties it to a subconfiguration XML file.
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.
The XML subconfiguration file specifies that either password or public-key authentication is allowed.
|VShell Server||VShell Server||Buy Direct||Evaluation||Contact|
|SecureCRT||SecureCRT||License Pricing||Updates Policy||Press Releases|
|SecureFX||SecureFX||About Encryption Export||FAQs||What's New|
|VanDyke ClientPack||VanDyke ClientPack||Orders FAQ||Tips & How-Tos||Customer Stories|
|Beta Software||Beta Software||Resellers||Forums||Secure Solutions|
VShell, SecureCRT, SecureFX, Entunnel, CRT, and AbsoluteFTP are trademarks or registered trademarks of VanDyke Software, Inc. in the United States and/or other countries. All other trademarks or registered trademarks are the property of their respective owners.
Copyright © 1995 - VanDyke Software, Inc. All rights reserved.