Novell is now a part of Micro Focus

Overview of New Features in BorderManager Enterprise Edition 3.5

Articles and Tips: article

LAURA PAN
Technical Writer
Common Engineering Services

01 Nov 1999


Describes the new BorderManager Enterprise Edition 3.5 features and enhancements and shows how to configure them in your enterprise environment. Includes information on Login Policy Object (LPO), support for ActivCard token authentication, proxy support for Real Time Streaming Protocol (RTSP), and VPN LAN client software.

Introduction

BorderManager Enterprise Edition 3.5 provides the following new features not included in BorderManager Enterprise Edition 3 or BorderManager 2.1:

  • A Login Policy object (LPO) in NDS for centralized administration of authentication for VPN users, proxy users, SOCKS 5 clients, and BorderManager Authentication Services (RADIUS) clients.

  • Support for ActivCard, Inc. token authentication that includes the ability to manage and store Novell/ActivCard smart card assignments in NDS for VPN users, proxy users, SOCKS 5 clients, and RADIUS clients.

  • Interoperability with Security Dynamics, Inc. (SDI) ACE/Server for SecurID token authentication of VPN users, HTTP proxy users, SOCKS 5 clients, and RADIUS clients.

  • Proxy support for Real Time Streaming Protocol (RTSP) which is used to efficiently stream multimedia content over IP networks.

  • Built-in transparent Telnet proxy.

  • Support of LAN and broadband access for both Windows 95/98 and Windows NT 4.0 VPN clients using a cable modem or Digital Subscriber Line (DSL) to access the Internet.

BorderManager Enterprise Edition 3.5 also provides the following enhancements to improve the functionality and ease-of-use of the software:

  • Improved installation to allow selective installation of all or some of the BorderManager Enterprise Edition services on a single server (or across multiple servers).

  • Capability to enable from NetWare Administrator all the BorderManager alerts or just the ones of interest.

  • Text-based logs and log file configuration files for IP packet filtering.

  • VPN client support for Windows NT 4.0 clients.

  • VPN client phone book capability.

  • Single sign-on for FTP users.

This AppNote describes the new BorderManager Enterprise Edition 3.5 features and enhancements and how to configure them in your enterprise environment.

Login Policy Object

Prior to the release of BorderManager Enterprise Edition 3.5, authentication rules for users of BorderManager Authentication Services were configured for Dial Access System (DAS) objects in NDS. A user could dial in to a remote access server only if an administrator assigned an authentication rule for the user at the DAS object representing the server in NDS. If a user dialed in through multiple remote access servers, the administrator was required to create an authentication rule at each DAS object representing those servers. The Login Policy object (LPO) enables an administrator to define authentication rules for users as part of a policy that can be accessed by multiple servers. The function of the LPO has also been extended to the authentication of Virtual Private Network (VPN) clients, proxy users, and SOCKS 5 clients.

The following is now true for BorderManager authentication:

  • Only one LPO is allowed per NDS tree. It is created in the Security container at the root of tree.

  • Authentication rules and policies are defined and stored in NDS at the LPO and are globally managed with NetWare Administrator.

  • A module called the Authentication Device Manager (ADM) running on each BorderManager server is responsible for processing all authentication requests and checking the LPO authentication rules for each BorderManager service enabled on the server.

  • If an LPO is not defined, the ADM cannot process authentication requests and access to BorderManager services requiring authentication is denied.

  • A BorderManager server that does not have a local NDS replica cannot access the LPO unless it is a trustee of the LPO with Read rights to the SAS: Policy Credentials attribute explicitly assigned.

Creating a Login Policy Object

To create a Login Policy Object (LPO) in your NDS tree, do the following from NetWare Administrator (you must be logged in as Admin or another user with administrative rights to the root of the NDS tree):

  1. Under [Root], right-click the Security object and select Create.

  2. Double-click Login Policy and click Create. (You are warned that you must define at least one rule for each BorderManager service. See the next section for the procedure.)

  3. Click OK to view the Login Policy details page.

Creating Login Policy Rules

When you create a Login Policy authentication rule, you can specify the following:

  • Service Type—Which BorderManager service the rule applies to (VPN, SOCKS, Proxy, or a DAS object name for Authentication Services)

  • User List—Which NDS users the rule applies to (User, Container, or Group objects)

  • Methods—Which authentication methods the rule will enforce

  • Method Enforcement—How the rule is to be enforced

  • Method Restrictions—Whether to limit the number of grace logins

To create a Login Policy authentication rule, do the following from NetWare Administrator:

  1. If you just created your Login Policy object (LPO), the Login Policy page is automatically displayed. Otherwise, right-click the LPO and select Details.

  2. Click Rules > Add.

  3. Select Predefined to specify VPN, SOCKS, or Proxy service types, or select Object name and browse to select a DAS object (for BorderManager Authentication Services).

  4. Click User List > Add to add the User, Container, or Group objects whose authentication will be enforced by the authentication rule.

  5. Click Methods > Add to configure the Login Method options.

  6. Click OK.

Figure 1 shows the Login Method configuration window.

Figure 1: The Configure Login Method Window.

The Method Types are defined as follows:

  • Object name. Although this method type has the same identifier as one of the service types, they are completely different objects. The object name for Service Type represents a DAS object. The object name for Method Type represents a Login Method Container. A Login Method Container holds the Authentication Device objects (tokens) from a particular vendor. See the next section for more information about tokens.

  • NDS password. This method type requires the user to enter an NDS password when authenticating.

  • Dial access password. This method type requires the user to enter a dial access (RADIUS) password separate from the NDS password. The password is exchanged using the Password Authentication Protocol (PAP).

  • Dial access password (CHAP). This method type requires the user to enter a dial access (RADIUS) password separate from the NDS password. The password is exchanged using the Challenge Handshake Authentication Protocol (CHAP).

  • Any user-defined device. This method enables token-based authentication using tokens from multiple vendors. See the next section for more information about tokens.

Note: Dial access passwords are valid only with BorderManager Authentication Services.

The Method Enforcement options are defined as follows:

  • Mandatory. This option enforces the Login Method at all times.

  • Required if assigned. This option enforces the Login Method only if the user has an assigned token.

  • Acceptable. This option accepts the Login Method as one of multiple methods that are available.

Not all Method Types and Method Enforcement options are available to all Service Types. Further, the ability to decrement grace logins for VPN clients is not applicable. Refer to Table 1 for the Login Method options available for each service type.

Table 1: Login method options available for each service type.


Service Types
Method Types
Method Enforcement
Method Restrictions

VPN (Predefined)

Object name (Login Method Container for tokens)Any user-defined device

MandatoryRequired if assignedAcceptable

Not applicable

SOCKS (Predefined)

Object name (Login Method Container for tokens)NDS passwordAny user defined device

MandatoryAcceptable

Decrement grace logins

Proxy (Predefined)

Object name (Login Method Container for tokens)NDS passwordAny user-defined device

MandatoryAcceptable

Decrement grace logins

Object Name (DAS object)

Object name (Login Method Container for tokens)NDS passwordDial access passwordDial access password (CHAP)Any user-defined device

MandatoryAcceptable

Decrement grace logins

Note: Although NDS password does not appear as an available method type for VPN client authentication, if token-based authentication is used to authenticate a VPN client, the user must provide both a token password and an NDS password during login. NDS password is listed as the default Method Type with Prerequisite listed for Method Enforcement.

All authentication rules defined by the LPO are stored in a single list regardless of which services they apply to. However, the first rule in the list that applies to an authentication request is used. If there are two rules for proxy authentication and a user's authentication request succeeds based on the first rule, the subsequent rule does not apply. After a rule matches, rules sequentially lower in the list are not considered. (This is similar to how BorderManager access control rules are executed.)

For example, as shown in Figure 2, if a user has been assigned an ActivCard token, it is an acceptable authentication method (1st method in list). If the user has been assigned a token from another vendor, the user must login with a token (2nd method in list). Finally, if the user has not been assigned a token, the user must authenticate using an NDS password (3rd method in list).

Figure 2: Order of authentication rules.

Note: Although both are stored in NDS, authentication rules and BorderManager access control rules have a different function. For example, a proxy user may have an access control rule granting access to Web content and a separate authentication rule specifying the authentication method. If the user fails to authenticate using the method specified by the authentication rule, access is denied, even though the BorderManager access control rule grants access.

Assigning Trustee Rights to BorderManager Servers without a Local NDS Replica

A BorderManager server with a local Read/Write or Read-Only NDS replica can automatically access the authentication rules defined by the LPO. However, a BorderManager server that does not have a local NDS replica cannot access the authentication rules. You must make the server a trustee of the LPO. See Figure 3.

To make the server a trustee of the LPO, do the following in NetWare Administrator:

  1. Select the LPO located in the Security container at the root of your NDS tree.

  2. Select Object > Trustees of this Object.

  3. Select Add Trustee.

  4. Browse for and select the Server object representing the BorderManager server.

  5. Deselect all object rights.

  6. Click Selected Properties.

  7. Scroll down and select the SAS: Policy Credentials attribute.

  8. Under Property Rights, click Read.

  9. Click OK.

Figure 3: Granting LPO Trustee Rights to servers without an NDS replica.

Token-Based Authentication

BorderManager Enterprise Edition 3.5 supports token-based authentication for VPN, SOCKS, Proxy, and remote access clients.

Token-based authentication is an example of two-factor authentication. In contrast to password authentication, which relies solely on the use of a single password, two-factor authentication incorporates a personal identification number (PIN) in addition to a hardware or software token device. Smart cards (credit-card-sized devices that are preprogrammed with unique passwords) are an example of hardware tokens. Software tokens are generated by software installed on a computer. After being activated by a user entering a PIN, a software token provides a unique password for authentication. Because of the additional requirement of token generation, two-factor authentication is more secure than password authentication and is often referred to as strong authentication.

There are two methods for token authentication. The asynchronous (or challenge/response) method requires that the server send the token device an encrypted message. The token device uses a preset algorithm and shared secret to decrypt the message and respond with the correct password encrypted with the shared secret. The synchronous method requires that the server and the token device simultaneously calculate a challenge message using parameters from a time counter or login event counter, or both. If the calculated messages match, the authentication is successful.

Note: With BorderManager Enterprise Edition 3.5, only the synchronous method can be used to authenticate tokens used by VPN, proxy, or SOCKS clients. However, BorderManager Authentication Services supports both synchronous and asynchronous methods.

How Tokens Are Stored in NDS

BorderManager Enterprise Edition 3.5 natively supports Novell/ActivCard tokens. A special container in NDS stores information about these tokens.

Novell/ActivCard tokens must be initialized (or imported) for storage in NDS and assigned to users before token authentication can occur. Initialization of smart card tokens involves attaching a hardware token programming device to a serial port on the administrative workstation and inserting the smart card to be initialized into this device. This is known as local initialization. During initialization of Novell/ActivCard tokens, you use NetWare Administrator to specify the type of device (smart card), a profile, a language, the serial port (COM1 or COM2), and an initial PIN. Novell/ActivCard devices support English, Finnish, French, Norwegian, Spanish, and Swedish.

You can also perform what is known as a manual initialization. With manual token initialization, you use NetWare Administrator to generate and display a secret code for the token. You then manually enter the code into the token programming device so the smart card uses the same code.

Novell/ActivCard smart cards that have been pre-initialized at the factory can also be used. In this case, you must use NetWare Administrator to import the device image files from a disk into NDS. The tokens must be assigned to users before they can be used for authentication.

Note: If your network users are already equipped to use SDI SecurID tokens in conjunction with an ACE/Server, the BorderManager Enterprise Edition 3.5 software can forward authentication requests to an ACE/Server when a BorderManager service requires a user to authenticate. However, unlike ActivCard tokens, information about SecurID tokens is not stored in NDS.

To better understand how to manage both ActivCard and SecurID token authentication for BorderManager services, consider the objects that are created in NDS:

  • Authentication Device objects

  • ActivCard Containers

  • External Login Service objects

Authentication Device Objects

An Authentication Device object stores information about a single token in NDS. Each token that is initialized or imported results in the creation of a unique Authentication Device object in NDS.

ActivCard Containers

BorderManager Enterprise Edition 3.5 natively supports Novell/ActivCard One, Novell/ActivCard Plus, and Novell/ActivCard Gold smart card tokens. A new class of object called ActivCard Container stores the Authentication Device objects created from the initialization or import of ActivCard tokens. The ActivCard Container is created in the Security container under [Root] in your NDS tree.

External Login Service Objects

BorderManager Enterprise Edition 3.5 provides interoperability for SecurID token authentication through a Security Dynamics, Inc. (SDI) ACE/Server. ACE/Server network security software runs on UNIX and Windows NT platforms. When the BorderManager receives a request for SecurID token authentication, it uses the RADIUS protocol to forward that authentication request to an ACE/Server. The ACE/Server can be an internal server residing on the same network as the BorderManager server, or it can be an external server on a public network.

To support SecurID token authentication, you must create an External Login Service object in the Security container under [Root] in your NDS tree. The External Login Service object stores details about the primary and secondary IP addresses of the ACE/Server and the primary and secondary shared secrets for RADIUS. These fields must be configured before users can authenticate using SecurID tokens.

Managing Tokens with NetWare Administrator

In summary, you can use NetWare Administrator to

  • Create ActivCard Container and External Login Service objects

  • Initialize tokens

  • Import token device files

  • Assign tokens to users

  • Enable and disable tokens

  • Test token passwords

  • Synchronize tokens (If you are using synchronous token authentication and the counters on the server and a token device become out-of-sync, you can use NetWare Administrator to synchronize the token with the server.)

  • Unlock tokens (For security purposes, a token is typically locked after a user enters a series of incorrect PINs. The locked token cannot be used until an administrator unlocks it.)

RTSP Proxy

BorderManager Enterprise Edition 3 enabled clients using Real Players to connect to RealAudio servers through the RealAudio proxy. Because requests were fulfilled through the RealAudio proxy, private hosts were essentially hidden from the public network. However, a limitation was that the RealAudio proxy did not support Real Time Streaming Protocol (RTSP). RTSP controls multiple data delivery sessions that are multicast to clients. Therefore, any UDP, TCP, IP, or IP Multicast application that required RTSP could not connect through the RealAudio proxy. BorderManager Enterprise Edition 3.5 extends the RealAudio proxy to support connections to servers using RTSP. To enable this feature using NetWare Administrator, check the RealAudio and RTSP Proxies check box within the Application Proxy tab on the BorderManager Setup page.

Transparent Telnet Proxy

BorderManager Enterprise Edition 3 did not have a built-in Telnet application proxy. However, you could create a Telnet proxy by configuring the Generic TCP proxy or the Generic UDP proxy. However, one difficulty with using a generic Telnet proxy was that each Telnet session had to be configured to connect to the specific IP address representing the Telnet proxy. BorderManager Enterprise Edition 3.5 now has a built-in transparent Telnet proxy that enables users to seamlessly connect to the Telnet proxy without requiring that each session be configured to point to the proxy server. The function of the transparent Telnet proxy is similar to that of the transparent HTTP proxy. To enable this feature using NetWare Administrator, check the Transparent Telnet Proxy check box within the Transparent Proxy tab on the BorderManager Setup page. Double-click Transparent Telnet Proxy to specify the connection ports for Telnet sessions that are to be monitored and redirected to the Telnet proxy. You also have an option to specify the IP addresses of Telnet servers for which you want redirection to be disabled.

VPN LAN Client Software

When you install the VPN client software you have the option to select the Dial-Up VPN Login check box, the LAN VPN Login check box, or both. The installation program automatically creates shortcuts on your desktop corresponding to these login options. If you install both the Dial-Up VPN Login and the LAN VPN Login options, two different shortcuts are created on your desktop.

Logging in using the VPN LAN Login option is very similar to logging in using Dial-Up Login option except the VPN LAN Login option does not require the following:

  • Configuration of a dial-up entry name (created by double-clicking the Make New Connection icon)

  • Configuration of the server type (Novell Virtual Private Network) for the dial-up entry

  • Entry of the dial-up username and password during login

  • Entry of a RADIUS domain for authentication by a RADIUS proxy server.

Figure 4 shows what is required for login using the VPN LAN Login option.

Figure 4: Fields required by the VPN LAN Login Option.

Note: The NetWare Options and the information shown under VPN Status for VPN LAN Login are the same as those for VPN Dial-Up Login.

Additional BorderManager Enhancements

This section briefly describes other BorderManager Enterprise Edition 3.5 software enhancements.

Improved Installation

The BorderManager Enterprise Edition 3 software required that you install all the software components as part of an integrated installation. The installation program copied all the firewall/caching NLMs on servers even if you wanted to set up a VPN only. The BorderManager Enterprise Edition 3.5 software now provides check boxes to select which services to install. You can select to install BorderManager Firewall/Caching Services, BorderManager VPN Services, or BorderManager Authentication Services individually, or select to install all three.

Flexible Alert Notification

BorderManager Alert sends an e-mail message when certain server events occur, such as a disk space shortage or a TCP SYN packet flood. However, when BorderManager Alert was enabled for the BorderManager Enterprise Edition 3 software it was an all-or-none event. Only the entire set of alerts could be enabled or disabled. The BorderManager Enterprise Edition 3.5 software now provides the capability to enable all of the alerts or a subset of them. To select the alerts during setup, you can check the check boxes in NetWare Administrator corresponding to the following alerts:

  • Disk space shortage

  • Loading of security sensitive NLM

  • ECB shortage

  • License error

  • Oversized Ping packet

  • SYN packet flooding

  • Oversized UDP packet

  • ICP parent down

  • SOCKS server down

  • POP3 or SMTP server down

Text-Based IP Packet Filter Logs

BorderManager Enterprise Edition 3 packet filter logging relied on the Btrieve database. Some drawbacks to using the Btrieve database included the requirement that IPX be supported on your network, the slow performance of Btrieve, and the nonstandard (proprietary) log format required by CSAUDIT.NLM. The BorderManager Enterprise Edition 3.5 software now provides text-based logging for IP packets. You can view the log files with any text editor. In addition, the log configuration file is a text file. You can specify the archiving, rollover, and size of the log files by editing parameters in the log configuration file.

The IP packet filter logs are stored in the SYS:ETC\LOGS\IPPKTLOG directory. The log configuration file is located in the SYS:ETC directory and is named IPPKTLOG.CFG.

Note: IPX packet filter logs still rely on Btrieve and have not been converted to text-based logs. With BorderManager Enterprise Edition 3.5, you can no longer view or export IP or IPX packet filter logs from NetWare Administrator.

VPN Support for Windows NT 4.0 Clients

BorderManager Enterprise Edition 3.5 now supports VPN connectivity from Windows NT 4.0 clients. Windows NT 4.0 clients can now access a VPN server using either a dial-up or LAN connection. See the previous VPN LAN client software section in this article for more information about VPN LAN connections.

VPN Client Phone Book Capability

The phone book capability enables clients to easily dial in to an ISP by selecting a phone number from a pre-configured or custom phone book. Because the VPN client can use any phone book created by Microsoft Connection Manager, the VPN client can access any phone books distributed by ISPs as long as they were created in that format. Phone books that are not created in that format can be converted using the VPN client software.

When the phone book capability is selected, phone books located on the workstation are listed in the Phone Book drop-down menu.

Single Sign-On for FTP

BorderManager Enterprise Edition 3 supported single sign-on for the HTTP proxy and Novell IP Gateway through the use of the CLNTRUST.EXE and DWNTRUST.EXE modules on Windows 95/98 and Windows NT 4.0 clients. BorderManager Enterprise Edition 3.5 extends single sign-on to the FTP proxy. If a user is already authenticated to one of these proxies or the Novell IP Gateway, use of another proxy does not require the user to log in again. The additional authentication occurs in the background and is seamless to the user.

Conclusion

This AppNote has described the new features and enhancements in BorderManager Enterprise Edition 3.5. Refer to the online NetWare Administrator Help, the product documentation, and the Readme for specific configuration procedures.

The BorderManager Enterprise Edition 3.5 documentation is located at: http://www.novell.com/documentation/lg/bmee3.5/docui/index.html

The BorderManager Enterprise Edition 3.5 Readme and updates to the Readme are located at: http://support.novell.com/cgi-bin/search/tidfinder.cgi?2952460 and http://support.novell.com/cgi-bin/search/tidfinder.cgi?2951388

For more information about configuring BorderManager Enterprise Edition 3.5 servers to operate with third-party authentication servers, refer to: http://support.novell.com/cgi-bin/search/tidfinder.cgi?2952863

Note: Laura Pan's book, Novell's BorderManager Administrator's Handbook, is a task-oriented guide that provides instructions for installing, monitoring, and troubleshooting BorderManager. For more information see: http://shop.novell.com/

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates