Table of Contents

1. Introduction

• AAA Server Administration (incl. ldap, gate, groups, profiles)
• Novell Access Manager Identity Server Configuration
• Troubleshooting Identity Server Authentication Issues

Introduction

The goal of this document is to show how Novell Access Manager can be configured to authenticate against the ActiveIdentity AAA 6.6 server, as well as detailing the Access Manager troubleshooting options in cases where authentications may fail. We will also cover a high level overview on how to setup the AAA server to verify users and assign tokens to users in eDirectory. For details on the individual configuration options of the AAA server, consult your AAA documentation.

Here is a high level layout of what servers are in place.

Click to view.

AAA Server Administration Console

2.0 Define the IP address and credentials of the LDAP server where users will authenticate against, as well as the list of attributes to search for.

Click to view.

2.1 Gate

Define the Gate settings on the AAA server, including all radius settings for the server.

Click to view.

2.2 Groups. Defines groups of users that will be accessing the server. The most important group are those users with tokens, but here we include screenshot of all group options.

2.2.1 All Users

Click to view.

2.2.2 Users with Tokens. Make sure that the users with tokens point to the GATE setup from 2.1 above

Click to view.

2.2.3 Users without Tokens

Click to view.

2.3 Profiles. Define list of attributes sent back during authentication to the server

Click to view.

2.4 LDAP. Define the ldap search criteria against back end LDAP server

2.4.1 LDAP All Users. Make sure that the filter is defined as 'objectclass=inetorgperson'

Click to view.

2.4.2 LDAP Users with Tokens

Set the filter to be (&(objectclass=inetorgperson)(telexNumber=*)). The telexNumber attribute contains the serial number of the token device (see 2.0 above).

Click to view.

2.4.3 LDAP Users without Tokens

Set the Filter to be (&(objectclass=inetorgperson)(!(telexNumber=*)))

Click to view.

Novell Access Manager Configuration

Novell Access Manager's Identity server must be configured to authenticate users via Radius. The following screenshots show the various Access Manager steps required to authenticate users against the AAA RADIUS Server for authentication.

Click to view.

1. The Radius client configuration is defined as part of the Identity Server configuration, so the Identity server TAB must be selected.

Click to view.

• By Selecting the Identity Server component and hitting the Edit TAB, one will be able to view what URL the Identity Server can be accessed on (BaseURL below). This is the URL that the users will access in order to authenticate to Access Manager. The type of authentication depends on the type of classes, methods and contracts defined under the LOCAL tab.

Click to view.

• When setting up an IDP server, one has to specify a User store that the Identity Server will talk to during the authentication process. By default, we will point to our IDV LDAP user store. The IP address, port, search credentials and timeout settings all need to be configured.

Click to view.

• By selecting the LOCAL TAB in the Identity Server configuration, we can view the various user stores, classes, methods and contracts available for use during the authentication process. By default, there are no predefined radius classes in the list – the administrator must manually create this. For the porposes of our Active Identity cards, we'll create a new "Class" named "AAA" using "RadiusClass" for the Java Class.

Click to view.

• For the "AAA" Class we have to populate various attributes, such as the AAA Server IP Address, the Ports and Shared secret used to exchange radius requests/responses between the AAA server and the Radius client on the Identity Server. Note that if an administrator wants the users to authenticate with a combination of the radius token and password, as well as the users password in an LDAP tree, the 'require password' option would be enabled.
  
  
  The JSP field allows administrators to customise the look and feel of the login page presented to the users.

Click to view.

• With the class defined, we now have to define the methods that uses the class. The method ties the Radius class we just created above, with the user store where our users are located. In the example below, we create a OTP method name where we link the AAA Radius class to our IDV user store. This implies that, when the method is executed, we will try and validate our radius users to the IDP user store.

Click to view.

Click to view.

• Finally, in order to be able to have users authenticate to certain applications or protected resources with one authentication type versus another, we define contracts. The contract can include multiple methods so that we can AND them together. For example, it may be that we want to protect an application in such a way that users are asked to authenticate with their token as well as their LDAP username and password. In such a case, we could create a contract that includes a radius method (OTP above for example) and an LDAP method. Only when both methods in the contract are satisfied, will the user be considered authenticated. In our example below, we will create a Name/OTP contract and only include the OTP method.

Click to view.

Click to view.

Click to view.

At this stage, we simply need to save and apply the changes and our Identity server should be ready to test out. If we now go to our browser and hit the Identity Server base URL – http://ism-am-ids.ism.utopia.novell.com:8080/nidp, we will get prompted for our username and password with the default settings.

Default and Current Demo Login is shown here.

Click to view.

When the default contract is changed to the Name/OTP contract, users will be asked to authenticate with their radius credentials as show. When the Username and OTP have been entered and submitted to the Identity server, the Identity server will go to the AAA server to verify the credentials using a Radius request. Assuming we get a radius accept message back, the user will be authenticated and allowed to access the Identity Server.

Click to view.

Troubleshooting Authentication issues against the AAA server

Before delving into the detailed logs, some basic checks need to be performed:

1. Verify connectivity from the Novell Identity Server to the AAA Server. From the Novell Identity Server console, use netcat to check that the UDP port is open
   

   orch-host3:~ # netcat -u 172.17.2.93 1812 -v -v
   (UNKNOWN) [172.17.2.93] 1812 (radius) open
   sent 0, rcvd 0
   
   

   
   If there is no response to the netcat probe, make sure no firewall exists on or between the Identity Server and the Radius server.

• Verify that sample users can authenticate with the right credentials against the back end AAA server using ntradping. This utility and details are available at http://www.novell.com/coolsolutions/tools/14377.html
  
  If this utility fails to authenticate the sample user, make sure that the AAA server
  
  1. allows incoming requests from the IP address of the Identity server and test workstation running the ntradping utility and
• that the user is setup correctly on the Radius and/or back end authentication server

Assuming that the above basic steps validate successfully, we need to look at the Identity server logs in more detail. The best approach is to enable verbose logging at the Identity Server is to enable the following log settings on the Novell Identity server. With these settings applied, all radius requests on the Identity Server will be logged to the /var/opt/novell/tomcat4/logs/catalina.out file.

Click to view.

After applying these changes and logging in as a test user, we will see the following key entries in the catalina.out file.

// Look for the RadiusCLient.Authenticate method to be called and make sure valid username sent over
<amLogEntry> 2008-12-18T17:07:52Z NIDS Trace: Method: RadiusClient.authenticate()
Thread: http-0/0.0.0.0-8443-Processor119
authenticate(userName,) = tokenuser
</amLogEntry>

// After obtaining the user details, we will try and communicate with the Radius Server
<amLogEntry> 2008-12-18T17:07:53Z NIDS Trace: Method: RadiusClient.A() Thread: http-0/0.0.0.0-8443-Processor119
(1 of 2):
Sending packet to failover server
(2 of 2):
Waiting for packet from failover server
 </amLogEntry>

// Assuming that the Radius accept message is returned, we will autehnticate the user and add that user t our local user database

<amLogEntry> 2008-12-18T17:07:53Z NIDS Trace: Method: RadiusClient.authenticate()
Thread: http-0/0.0.0.0-8443-Processor119
User vasco user authenticated
 </amLogEntry>

// It may be that the Radius server is configured to return Radius attributes – these attributes will be defined in the log file too.

<amLogEntry> 2008-12-18T17:07:53Z NIDS Trace: Method: RadiusClient.B()
Thread: http-0/0.0.0.0-8443-Processor119

Response Packet Attributes
        Type    Value   26      ^@^@=l^A%CN=TOKENuser.O=novell.T=AccessMGR^@
 </amLogEntry>
 

Should any errors be displayed during the radius authentication process, the error codes produced by the Novell Identity server will be documented at http://www.novell.com/documentation/novellaccessmanager/eventcodes/?page=/documentation/novellaccessmanager/eventcodes/data/bookinfo.html (1.1 Identity Server (001) section)

If no errors or erroneous logged entries appear in the catalina.out log file as the user authenticates, it may be useful to run tcpdump (http://www.tcpdump.org/) on the Identity Server and analyse the radius traces using Wireshark (http://www.wireshark.org/download.html).

tcpdump can be run with filters so that only the appropriate radius requests are capture. An example of such a request in the scenario above would be

orch-host3:~ # tcpdump -i any -s 0 -w radAAA.cap port 1812 and host 172.17.2.93
tcpdump: WARNING: Promiscuous mode not supported on the "any" device
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
8 packets captured
197 packets received by filter
0 packets dropped by kernel

When the data has been captured and we exit out of the tcpdump command (control-c), the saves radAAA.cap file can be read into Wireshark where the radius requests are decoded. The radius protocol specifications are available from http://www.ietf.org/rfc/rfc2865.txt.