Table of Contents
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.
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.
Define the Gate settings on the AAA server, including all radius settings for the server.
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
2.2.2 Users with Tokens. Make sure that the users with tokens point to the GATE setup from 2.1 above
2.2.3 Users without Tokens
2.3 Profiles. Define list of attributes sent back during authentication to the server
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'
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).
2.4.3 LDAP Users without Tokens
Set the Filter to be (&(objectclass=inetorgperson)(!(telexNumber=*)))
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.
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.
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.
Before delving into the detailed logs, some basic checks need to be performed:
orch-host3:~ # netcat -u 172.17.2.93 1812 -v -v
(UNKNOWN) [172.17.2.93] 1812 (radius) open
sent 0, rcvd 0
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.
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()
authenticate(userName,) = tokenuser
// 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
// 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()
User vasco user authenticated
// 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()
Response Packet Attributes
Type Value 26 ^@^@=l^A%CN=TOKENuser.O=novell.T=AccessMGR^@
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.