Novell is now a part of Micro Focus

Configuring BorderManager Authentication Services for Use with ActivCard Tokens

Articles and Tips: article

Marcus Williamson
Connectotel Ltd.
London, UK
marcus@myrealbox.com

Silvia Hagen
Sunny Connection
Zurich, Switzerland

01 May 2000


Thanks to Chee Tan of ActivCard for his assistance in the review of this AppNote.

This AppNote was developed after the implementation of ActivCard for a Swiss bank. The bank had a requirement for the provision of a system to allow 250 of its top private banking clients to access their account details online. As part of the implementation, it was found that the existing Novell and ActivCard documentation did not provide a sufficiently detailed description of configuring the BMAS/ActivCard combination. It was therefore decided that an AppNote should be produced on this topic.

Instead of providing dial-in to their private network, as many other banks have done, it was decided to use the Internet, a public-access network which is universally available. Security is provided in a number of ways. Firstly, access to all servers is mediated by a Java-based piece of middleware, acting as a RADIUS Client, which is used to authenticate to Novell Directory Services (NDS) using the RADIUS protocol. ActivCard devices are used as tokens to verify the user's identity. Secondly, all transactions between the user and the bank's systems use Secure Socket Layer (SSL) to ensure that data is not visible in clear text when passing over the Internet.

In other implementations of BMAS and ActivCard which have been undertaken by Connectotel, the RADIUS client is usually a hardware-based Remote Access Server (RAS) device, such as those provided by 3Com, Cisco, or Shiva.

The installation and configuration instructions which follow include tests and deliberate errors which have been introduced to show the stages by which the various layers of communication aspects of the TCP/IP and RADIUS communication have been configured.

Since this AppNote was written in Europe, it retains the British spelling used by the authors.

What is RADIUS?

RADIUS, the Remote Authentication Dial In User Service, was first described in Internet Request for Comment (RFC) document RFC 2058, published in January 1997. This RFC was updated and obsoleted by RFC 2138, published in April 1997.

RADIUS is a proposed Internet standard which has been widely adopted for use in situations where a remote access device, such as a Remote Access Services (RAS) server, needs to authenticate a dial-in user to a directory service. In most RAS solutions, it is necessary to maintain a separate directory of users who will be using the RAS dial in option. In the case of Novell's RADIUS implementation, the authentication of users is using existing user details stored in NDS.

Novell's implementation of RADIUS is known as BorderManager Authentication Services (BMAS). The software consists of the following:

  • RADIUS.NLM, located in SYS:SYSTEM and running on a NetWare 4.11/4.2 or 5.x server

  • A snap-in DLL, RADSNAP.DLL, located in SYS:PUBLIC\WIN32\SNAPINS and used by the NetWare Administrator (NWAdmin) utility

The RADIUS "Server" will always be the NetWare server which is running RADIUS.NLM. The RADIUS "Client" will be the device which is using the RADIUS protocol to authenticate users. Note that the client is not a NetWare user, but is instead a device which will communicate with the NetWare server running the RADIUS.NLM, on behalf of the NetWare user.

What is an ActivCard Token?

The ActivCard token device is a small, credit-card-sized device which looks like a pocket calculator, as shown in Figure 1.

Figure 1: The ActiveCard token device resembles a simple, pocket calculator.

It is an example of a security token, which is used to provide strong authentication onto a network. Strong authentication when using ActivCard makes use of a combination of the user name, the token, and a one-time personal identification number (PIN) to determine that the user is really who he or she claims to be. Thus, this technology is suitable for use in environments where standard username and password security is not adequate and additional security is required.

Prerequisites

In order to implement BMAS with ActivCard the following hardware and software components must be made available:

  • NetWare 4.11/4.2 or 5.x server

  • Novell BorderManager Authentication Services

  • ActivCard One Tokens

  • Windows 95/98 or Windows NT 4/2000 client

  • A RAS server or other RADIUS "Client" component

ActivCard One Tokens are available in a 5-token "promo" pack, or in a 50-token preconfigured pack. For availability and ordering details, visit

http://www.activcard.com/products/BMAS-ActivCard/stronger.html

Installation of BorderManager Authentication Services

BorderManager Authentication Services is installed from the CD-ROM using the INSTALL.NLM utility on NetWare 4.11/4.2 or the NWCONFIG utility on NetWare 5.0/5.1. When running NetWare 5.0/5.1, the installation is carried out through a GUI interface. In NetWare 4.11/4.2, the installation is a text-based interface.

After installation of the software, you should install the latest BorderManager Service Pack, which at the time of writing was BM35SP1.EXE, to ensure that the latest versions of the software components are being used.

Note: In some rare cases, during the installation of the BorderManager service pack, the TCPIP.NLM is zero bytes and cannot be loaded. In this case, do not copy a TCPIP.NLM from another NetWare Server without BorderManager, because the two TCP/IP stacks are currently not identical. Instead, go to http://support.novell.com and download the latest TCP/IP stack for BorderManager from the Minimum Patch List.

It is understood that Novell is working on a consolidated TCP/IP stack for all products and will release this as soon as possible.

The NWAdmin snap-ins for BorderManager are installed using the SETUP.EXE program, which is located in the SYS:PUBLIC\BRDRMGR\ SNAPINS directory.

Test 1: Connectivity Check.    From the RADIUS Server, we pinged the TCP/IP address of the RADIUS client. (Note that this relies on the RADIUS Server system having a Ping utility, which is not always the case.) From the RADIUS server, we then pinged the TCP/IP address of the BorderManager server.

This test ensured that the RADIUS Client and Server devices could communicate with each other. Once connectivity had been proven at the TCP/IP level, we were able to proceed with the next stage of the configuration process.

Test 1: Troubleshooting.    If connectivity had not been operating correctly, we would have adopted standard TCP/IP troubleshooting procedures, including checks of:

  • TCP/IP address and net mask of the RADIUS Client

  • TCP/IP address and net mask of the RADIUS Server

  • Router configuration and default routes, if the RADIUS Client and Server are on different networks

  • DNS configuration, if DNS names are being used

Configuration of BorderManager Authentication Services

We created a "Dial Access System" object in NWAdmin under the Resources container. In this case, we named the object CN=SunnyDialAccessSystem with a password of "novell". This password is required when starting the RADIUS NLM, as shown below.

The dialogue shown in Figure 2 appeared when we were creating the "Dial Access System" object.

Figure 2: Setting the Dial Access System password.

We then loaded RADIUS.NLM at the file server console as follows:

LOAD RADIUS name=SunnyDialAccessSystem password=novell RADIUS DISPLAY ALL

We also placed these same two lines in the AUTOEXEC.NCF of the server.

By default, the RADIUS.NLM listens on the following ports:

  • UDP 1645: authentication port

  • UDP 1646: accounting port

The use of these ports can be verified by checking the UDP listeners in TCPCON.NLM. If different port values should be used, you can change them on the command line when loading RADIUS.NLM. The load parameters recognised by RADIUS.NLM can be seen in Figure 3.

Figure 3: LOAD parameters recognised by the RADIUS.NLM.

Test 2: RADIUS Client Requests.    From the RADIUS Client, we attempted to log in as a user.

On the RADIUS DISPLAY screen of the server, a message appeared indicating that the login was not accepted for the reason that the "Client is not known". This test proved that the RADIUS Client and Server were able to communicate using the RADIUS protocol. Port 1645 or 1812 may be used for communication between the RADIUS Client and Server. For an explanation of the difference between port 1645 and 1812, see the Implementation Note section of RFC 2138.

Test 2: Troubleshooting.    If the RADIUS message was not seen, we would have checked the following areas:

  • TCP/IP connectivity, as described in Test 1 above

  • The RADIUS DISPLAY ALL command should be entered at the system console and in the AUTOEXEC.NCF file

  • Ports 1645 and 1646 are being allowed through any routers or firewalls between the RADIUS Client and Server.

Dial Access System Client Configuration

Now that the RADIUS communication had been proven, we updated the Dial Access System Configuration to add the address of the RADIUS Client system which would be communicating with RADIUS.NLM running on the NetWare server.

In this case, the IP Address was 10.1.1.10 and a Generic RADIUS type was chosen, as illustrated in Figure 4. In other circumstances, a different RADIUS Server type such as Shiva or Cisco might be chosen. The full list of currently supported client types can be seen in the pull-down menu for "Client Type".

Figure 4: Configuring a RADIUS Client on the RADIUS Server.

After this change, we unloaded and reloaded RADIUS.NLM at the server console so that the new RADIUS configuration could be read from NDS.

At this point, the administrator can also configure the Username Resolution option for the Dial Access System. This option dictates how users' names will be resolved when they attempt to log in through RADIUS. In this case, fully distinguished names were being used, so no Username Resolution configuration was necessary.

Test 3: Login Attempt.    With the next login attempt, using the fully distinguished name, the message "Access Rejected" was displayed. This was correct because the user had not yet been activated for use with this Dial Access System.

Test 3: Troubleshooting.    If "Access Rejected" had not been displayed, we would have repeated Tests 1 and 2 above to ensure that these have been successful. If necessary, we would carry out the relevant troubleshooting.

Assigning the Dial Access System to the User

We selected the "Dial Access Services" property page for the User object. We clicked the Enable radio button and chose the previously-configured Dial Access System, SunnyDialAccessSystem (see Figure 5). A prompt indicated that rights were about to be changed so that the User object could see this Dial Access System.

Figure 5: Assigning a Dial Access Service to an NDS User.

Test 4: Login Attempt.    At this point we attempted another login. On this occasion, we saw the message "Invalid Password".

Test 4: Troubleshooting.    The "Invalid Password" message can have a number of different causes. For example:

  • The user's NDS password has not been provided correctly.

  • The password is being transmitted as "Clear Text" or using the CHAP protocol, or there is some other mismatch between the protocols being used to transmit the password on either side.

  • The "Shared Secret" is not identical on the RADIUS Client and on the RADIUS Server.

In this case, the "Shared Secret" on the RADIUS Client was not configured the same on the RADIUS Client and Server. After we corrected this on the RADIUS Client, we were able to proceed with further configuration.

Dial-in Profiles

Dial-in Profiles can be defined optionally at this stage to provide a set of special parameters for each type of RADIUS Client system. You can further expand the profiles used and assigned through user-specific additional parameters. This provides for a very flexible configuration. In this specific example, no special profiles were required.

As an example, we configured the Dial-in Profile SunnyProfile.

Configuration of the ActivCard Authentication Container

The next step was to create an ActivCard container in which the ActivCard device objects were to be located. In this case, we named the container "ActivCard".

Opening this object in NWAdmin showed the Import Device Images page (see Figure 6).

Figure 6: Importing the ActivCard device images.

We selected this option to import the ActivCard serial number information provided on a diskette supplied with the ActivCard devices (see Figure 7).

Figure 7: The ActivCard serial numbers appear underneath the ActivCard container. Each serial number could now be assigned to a user.

Test 5: ActivCard Password Test.    Now, within NWAdmin using the Password Tests page of the ActivCard device object, we could test the ActivCard password as shown in Figure 8.

Figure 8: ActivCard Password Tests.

Clicking on the Test button displayed the dialogue shown in Figure 9.

Figure 9: Testing the ActivCard Password.

At this point, we switched on the ActivCard device for the first time and entered the default PIN, 1254. On first activation, we were prompted for a new PIN, which we entered twice.

It was now possible to proceed to create the relationship between the ActivCard device and the User object (see Figure 10).

Figure 10: Creating the relationship between the User object and the ActivCard device.

Test 5: Troubleshooting.    If the ActivCard password test had not been successful, the most common cause is that the ActivCard snap-ins have not been correctly installed on the server from which NWAdmin is being run. If this is the case, we would install the ActivCard snap-ins using the BorderManager SETUP.EXE as described previously.

Defining a New User

The definition of a new ActivCard user takes place in three stages. This process will be carried out for every new user who will be accessing services via the RADIUS server.

After the new user had been created as a User object, we made the following two definitions in NWAdmin:

  • After opening the User object and selecting the "Login Devices" property page, we clicked the Add button and selected the ActivCard device for the user from the NDS tree.

  • On the "Dial Access Services" property page of the User object, we selected Enable and assigned the SunnyDialAccessSystem to the user.

We made the third configuration change in the Login Policy object, as shown in Figure 11.

Figure 11: Updating the Login Policy object.

We opened the Login Policy object in the Security container, chose the Property Rules, selected "Modify", and inserted a new user.

Test 6: Login Test.    We carried out the final test out in the following stages:

  • We entered the User Name at the remote user login screen.

  • We switched on the ActivCard device.

  • We entered the ActivCard PIN on the ActivCard device.

  • We entered the number generated by the ActivCard device into the remote user login screen.

On the Radius DISPLAY screen, the information shown in Figure 12 was displayed:

Figure 12: Radius display screen.

Note: The name of the organisation has been removed from this screen shot.

The different entries represent the tests which were carried out and which generated the information shown on this screen. On the first attempt, we entered a wrong password for .admin.orgname. On the second attempt, we entered the name of a user which exists in NDS but is not enabled to use the Dial Access System. After that, we enabled the user for the Dial Access System, and on the third attempt, the user was authenticated and accepted.

Conclusion

This AppNote has shown how an ActivCard solution can be implemented in your own environment. Whilst the authors are unable to provide technical support, we welcome comments or suggestions for additional AppNotes in this subject area. Contact Marcus Williamson as marcus@myrealbox.com.

Additional Resources

The following additional documentation may be useful in the installation and configuration of Novell BorderManager products:

* 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