Netscreen's IVE 4.0 Centralizes VPN Management

Among the platform's most notable features are its access-policy enforcement capabilities and its NetScreen-SA Central Manager, which provides centralized monitoring, reporting and configuration management of multiple IVEs. In addition, version 4.0 enables dynamic-access control based on user identity, browser, time of day, and whether the user's remote device is managed. It also supports multiple hosts, which you can customize.

Hooked Up to the IVE

I tested the IVE 4.0 using a NetScreen-SA 3000 appliance. I was able to integrate the IVE with our Active Directory 2000 installation for user authentication; IVE also supports RADIUS, LDAP and its own internal identity store. Single sign-on functionality for Web resources is supported via forms and header-based posts.

To evaluate the dynamic nature of access policies, I created two roles: "User," for those signing on from a known IP address (in this case, my home office); and "KioskUser," for those signing on from all other addresses.

Upon creating a role, the administrator can assign it access rights. I limited the KioskUser's access to Web and Windows file shares, excluding NetworkConnect, terminal sessions (SSH/telnet) and e-mail.

For each role, the administrator can set restrictions based on IP address, a host-checking policy or even the browser type and version being used. Host-checking policies let administrators perform checks on the remote system before authentication is attempted. Examples of host checks include a successful antivirus scan; determination of whether specific ports are accessible; a check of the list of running processes for specific instances of required or of rogue applications running; or confirmation of the existence of a particular file.

Configuring a host-checking policy is straightforward, but the check-box options are limited to CyberGatekeeper, McAfee, Sygate and ZoneAlarm.

The administrator can, however, configure rules that require or deny access based on a specific process running or not running, open port(s) or the existence of file(s). I set up a rule for the KioskUser that would deny access if Port 80 were open.

You can specify whether remote access is granted, and the product's fine-grained control lets you determine what a user can and cannot do once access has been granted. You can control bookmark use and creation, as well as Windows and Unix file sharing and SSH/telnet use. I was able to let users assigned to the "User" role access all Windows-based shares while restricting access for the "KioskUser" role to a specific set of directions within the share.

Roles, Rules and RealmsOnce the roles are configured, the administrator must map them using rules. Such rules may be based on user name, certificate or custom expression. The custom expression is invaluable in providing truly dynamic role mappings, as roles can be mapped by checking myriad system variables against the user's authentication, including specific LDAP or RADIUS user attributes, time and/or date, source IP and user-agent. For example, I could dynamically assign users to different roles based on the location attribute within Active Directory. I easily configured a mapping rule that assigned the KioskUser role to those using Internet Explorer and the User role to all others.

You can configure user realms to authenticate to specific servers, such as LDAP, Active Directory or the local identity store. The user realm can be used in dynamic policies determining access as well. I configured the default "User" realm to authenticate to the internal identity store, and designated a custom "UserRealm" realm to utilize the Active Directory server I had configured earlier.

Once user realms have been configured, admins can customize which realm is assigned based on the URL the user accesses during sign-on. I configured a new sign-on URL, */nwc/, to use only the Active Directory authentication, and the default sign-on, */, to use the internal store. Any user accessing the IVE with the URL */nwc/ was now required to be a valid user within Active Directory, while the default URL looked only internally. By configuring only administrative users in the internal identity store and separating access by URL, I easily restricted access without building additional access-control lists or complex rules to determine whether a user should have administrative access.Next, I tried to log on to both as a user existing only in AD. I was delighted to find this worked as advertised, as integration with AD usually requires much more than these minimal IVE settings.

Combining this feature with the IVE's capability to support virtual hosts, makes a powerful delegated administrative security model not only possible, but simple to configure and maintain.

Looks Good, Costs a Lot

Page customization is a welcome addition to the IVE. I customized the sign-on pages with our logo and changed the text displayed on buttons and labels--all from the administrative console. Although not necessary for a successful secure remote-access product, this feature is a nice touch.

One downside to IVE 4.0 is its cost. Although existing NetScreen customers can upgrade most functionality for free, and though you can choose between a baseline package and an advanced one, several features--Central Manager, Network Connect, Secure Application Manager and Secure Meeting--must be bought separately. Compared with a conventional IPsec VPN, IVE 4.0 is far too expensive for small and midsize businesses. NetScreen says it will offer less expensive alternatives later this year, but with fewer features.Lori MacVittie is a NETWORK COMPUTING senior technology editor working in our Green Bay, Wis., labs. Write to her at [email protected].