Introduction

The AIX® Remote Authentication Dial-In User Service (RADIUS) server implements a client-server protocol, based on the Internet Engineering Task Force (IETF) Request for Comments (RFCs) 2865 and 2866, that enables remote access clients to communicate with a central server to gain access to a network. The RADIUS server authenticates users, authorizes their requests to services, and writes accounting data. The initial release for the RADIUS server is AIX 5L Version 5.3.0.10.

Typical clients in a RADIUS environment are a terminal server, authenticating LAN device, or wireless access point.

The AIX RADIUS server consists of three services:

1. Authentication
2. Authorization
3. Accounting

These services work together with either UNIX authentication, a local database, or a Lightweight Directory Access Protocol (LDAP) directory to provide authentication information. The RADIUS authentication server daemon provides security and user authentication for remote connections to the network. It also handles authorization, which specifies what services are available, and in some configurations, how network access is accomplished. The RADIUS accounting server daemon tracks when and how long remote connections are connected to the network, as shown in Figure 1 below.

The primary processes of the AIX RADIUS server are:

• Monitoring
• Authenticating
• Accounting

Primary means that these daemons are always loaded when the RADIUS server is functioning properly. The processes are running at an effective userid of "radiusd" and do not have permanent root authority. You can stop and start the processes using the SRC master commands:

• startsrc -s radiusd
• stopsrc -s radiusd

To view if the processes are loaded, you can run the ps -ef | grep radiusd command.

Back to top

Monitor process

The monitor process is a management process which starts or re-starts all other processes associated with the RADIUS server. At startup, the monitor process reads and processes all of the configuration files (for example, radiusd.conf, clients, proxy, dictionary, default.policy). The process also starts the communications to the syslog daemon for logging purposes. Services to the RADIUS server are processes which provide network services. The RADIUS server can start and manage two services:

• RADIUS authentication
• RADIUS accounting

The monitor process can start 1 to N instances of each service. Each instance of a service listens on a unique network port. The default configured port for authentication is the standard defined port 1812. The port for accounting is 1813. You can define additional ports in the main RADIUS configuration file, radiusd.conf. Each port listed in the radiusd.conf file starts a service listening on that port number.

Service instances might be of the same service type or of different types. For example, the monitor process might start three instances of the authentication service and two instances of the accounting service.

Remember, each instance of a service must run on a unique port. As shown in Figure 2 below, the authentication service could be running process instances on port 1812, 6666, and 7779. The radiusd.conf configuration file defines the port numbers.

After all services are available and functioning, the monitor process watches the services processes. If a service process should fail or abort, the monitor process logs the event and restarts the service.

Note: If you refresh the RADIUS server frequently, you can cause a diminishment of services.

Back to top

Authentication process

The general role of the authentication process is to respond to access requests from terminal servers, authenticating LAN devices, or wireless access points in one of the following ways:

• Granting access
• Denying access
• Challenging access and requiring additional information
• Validating authorization policies
• Replying with authorization information

Terminal servers manage and proxy remote access devices (for example, modems) for the network. If the authentication process grants access, the remote device attaches and becomes a part of the existing network. If access is denied, then the remote device can try to authenticate again or disconnect. The following scenario describes the communication packets for a successful authentication using a modem connection. Following authentication, the terminal server is configured to send accounting information to determine amount of time a user is on the network.

Authentication scenario

The modem receives a call (see 1 in Figure 3) and informs the terminal server of the call. The terminal server challenges the caller for a username and password. When the terminal server receives the username and password information, it constructs a UDP Authentication packet (see the Authentication packet section for more information). The terminal server is the client to the RADIUS server. The Authentication packet (Access-Request) contains the username, the hidden password, and other information which describes both the modem connection and sending terminal server.

The Authentication packet is then sent to the RADIUS authentication process (see 2 in Figure 3), and the terminal server waits for a response. The terminal server re-sends the Authentication packet if the authentication process does not respond in a predetermined time interval (for example, three seconds). The terminal server continues to re-send the Authentication packets until it receives a successful acknowledgment packet (a well-formed reject, challenge, or acceptance acknowledgment), or until it reaches a predetermined number of attempts (for example, 23). At this point, it stops sending authentication requests and drops the call, or it attempts to deliver the authentication requests to an alternate authentication process, if one is defined.

When the authentication process receives an authentication request, it queries a user database. Depending on how the system administrator configures the RADIUS server, one of three different user database locations is queried - - the local UNIX user database, local RADIUS specific database, or an LDAP directory (see 3 in Figure 3). The process retrieves information about the user attempting authentication. Authentication requires each of the following conditions to be true in order to grant access.

1. The userid is in the database.
2. The password in the Authentication Request packet matches the password found in the database or directory.
3. The authorization policy is checked. This policy is optional and requires configuration. If the policy is configured, the attribute-value pair contents of the packet must match exactly.

An Acceptance packet (Access-Accept) is returned to the terminal server when all processing is successfully completed. Depending on configuration values, the modem can then be given an IP Address and access to the private network (see 4 in Figure 3).

If authentication fails, a reject acknowledgment (Access-Reject) is sent to the (see 4 in Figure 3) terminal server and informs the user. The client can then decide to drop or try to authenticate the same user or to authenticate a new username and password pair.

Authentication packet description

Below is an example of an Authentication packet as received by the authentication process. This sample data is logged in syslog, at debug level 9. The information is written in hexadecimal and text formats.

Sep 20 10:03:18 server1 radiusd[1773678]: [2]:Incoming Packet:
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:  
	Code = 1, Id = 253, Length = 90
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:    
	Type =   1, Length =   8, Value = 0x67656E747937
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:    
	Type =   2, Length =  18, Value = 0x********************************
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:    
	Type =   4, Length =   6, Value = 0x0A0A0A09
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:    
	Type =   5, Length =   6, Value = 0x00000002
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:    
	Type =   6, Length =   6, Value = 0x00000001
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:    
	Type =   7, Length =   6, Value = 0x00000001
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:    
	Type =  30, Length =  10, Value = 0x3132332D34353637
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:    
	Type =  31, Length =  10, Value = 0x3736352D34333231
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:Starting parse_packet()
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:
	Code 1, ID = 253, Port = 44224 Host = 10.10.10.9
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:User-Name = "user_id"
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:NAS-IP-Address = 10.10.10.9
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:NAS-Port = 2
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:Service-Type = Login-User
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:Framed-Protocol = PPP
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:Called-Station-Id = "123-4567"
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:Calling-Station-Id = "765-4321"
Sep 20 10:03:18 server1 radiusd[1773678]: [2]:Leaving parse_packet()

The Authentication packet information, Access-Request, as displayed by the RADIUS server debug, consists of the following parts:

Sep 20 10:03:18 server1 radiusd[1773678]

General syslog information, day, time, server name, and radius process id.

[2]

Packet number since the daemon was started.

Incoming packet:

Message that denotes start of packet processing.

Code = 1, Id = 253, Length = 90

Access-Request code and length of packet.

Type = 1, Length = 8, Value = 0x67656E747937

Starts the attribute-value pair information in hex. This example contains 8 attribute-value pairs.

Starting parse_packet()

Log information that denotes start of packet processing -- same information but in text, readable format.

You can capture the above information when the RADIUS server is running in debug mode, level 9. The attribute-value pairs are RADIUS attributes that were sent from the hardware access server in the packet to the RADIUS server. Part 2 of this series provides a description on the various debug states.

Back to top

Accounting process

The purpose of the accounting process is to write accounting data about usage. The terminal server can be configured to generate RADIUS accounting information once a client has been authenticated. The RADIUS accounting consists of two messages types generated by the terminal server as follows:

1. Start accounting message
2. Stop accounting message

Accounting start scenario

The following example is for a user defined in the LDAP directory. LDAP defined users have a feature which allows tracking of in-process information. If the user is defined in the local database or is a UNIX user, the "in-process" information (or RADIUS Active objectclass) is not updated.

Defining users in LDAP allows for the optional feature of limiting the number of logins. If an LDAP user is created with the "maximum allowed login times" defined, then the accounting start and Accounting stop packets determine when a user is authenticated. If the user has reached the number of "maximum allowed login times", then the user cannot authenticate.

The "Start Accounting message", Accounting Request packet is generated when a successful authentication acknowledgment is received by the terminal server (see 5 in Figure 4). Upon receipt of the authentication acknowledgment, the terminal server then creates a Start Accounting packet(see the Start Accounting packet description section). The Start Accounting packet consists of an "Acct-Session-ID" which is identical in the complimentary Stop Accounting packet. The Acct-Session-ID aids in matching "start and stop" accounting messages that are logged.

The Start Accounting packet contains information about the terminal server and the type of service connection made. The packet also contains the amount of time which has passed since the authentication acknowledgment has been received. The start time of the user is then calculated by subtracting the Acct-Delay-Time from the current system time (see the Further description of Acct-Delay-Time) section.

When the RADIUS accounting server receives the Accounting packet (see 6 and 7 in Figure 4):

1. The LDAP Active objectclass is checked for a user with matching characteristics (for example, User-Name and not logged in).
2. If a user is found, the accounting process updates the active objectclass by adding Acct-Session-ID and start time to the object. The number of logins is increased also.
3. The accounting start data is written to /var/radius/data/accounting file.

All packets are acknowledged. If the above events do not complete successfully, errors are logged. Erroneous packets are acknowledged in order to deter receiving subsequent Accounting packets.

The terminal server stops transmitting Accounting Start packets either when it receives a well-formed acknowledgment from the RADIUS server or when a predetermined number of attempts has been exhausted. The terminal server re-sends Start Accounting packets based on a predetermined set of time intervals (for example, 0, 2min, 4min, 8min, and so forth) until acknowledgment or exhaustion occurs (see 8 in Figure 4).

Further description of Acct-Delay-Time

The Acct-Delay-Time attribute does not reflect network delays. It does represent delays due to the missing delivery of previous packets, which indicates that there are network delivery problems or that the authentication process was previously unreachable (down in some manner).

When a client is given access to the network, an Accounting packet is sent (Acct-Delay-Time = 0). If the valid acknowledgment is not received in a specified time period, another packet is sent including the new delay (Acct-Delay-Time = 120). Before the terminal server quits, these retries will continue like authentication for a predetermined number of tries. Also like authentication, it will attempt to deliver to a alternate accounting process, if one is defined.

Back to top

Accounting Start packet description

Below is example of an Accounting Start packet as received by the RADIUS accounting server.

Oct  1 15:47:43 server1 radiusd[540746]: [1]:Starting parse_packet()
Oct  1 15:47:43 server1 radiusd[540746]: [1]:Code 4, ID = 54, Port = 49475 Host = 10.10.10.9
Oct  1 15:47:43 server1 radiusd[540746]: [1]:Acct-Status-Type = Start
Oct  1 15:47:43 server1 radiusd[540746]: [1]:Acct-Session-Id = "000004F5"
Oct  1 15:47:43 server1 radiusd[540746]: [1]:User-Name = "user_id"
Oct  1 15:47:43 server1 radiusd[540746]: [1]:NAS-IP-Address = 10.10.10.9
Oct  1 15:47:43 server1 radiusd[540746]: [1]:NAS-Port = 12
Oct  1 15:47:43 server1 radiusd[540746]: [1]:Acct-Authentic = RADIUS
Oct  1 15:47:43 server1 radiusd[540746]: [1]:Service-Type = Framed-User
Oct  1 15:47:43 server1 radiusd[540746]: [1]:Framed-Protocol = PPP
Oct  1 15:47:43 server1 radiusd[540746]: [1]:Framed-IP-Address = 10.10.10.10
Oct  1 15:47:43 server1 radiusd[540746]: [1]:Acct-Delay-Time = 1

The Authentication packet information, as displayed by the RADIUS server debug, consists of the following parts:

• Header information (first line)
• A series of attribute-value pairs

Both the Stop Accounting packet and the Authentication packet share some, but not all, attribute-value pairs. The packet description contains both the unique and shared definitions for convenience.

The above information can be captured when the RADIUS server is running at debug level 9 mode. Part 2 of this series will provide a description on how to run RADIUS in debug.

Accounting Stop scenario

A Stop Accounting packet is initiated when the remote device disconnects or drops. The terminal server then generates a Stop Accounting packet (see 9 in Figure 5 and the Accounting Stop packet description section).

The Stop Accounting packet contains the same Acct-Session-Id, which was generated for the Start packet. It also contains Acct-Session-Time, which is the terminal servers calculation of elapsed session time. Like the Start Accounting packet, the Stop packet might send an Acct-Delay-Time attribute-value pair. The Acct-Delay-Time for the Stop Accounting packet is the amount time which has passed since the present packet was sent and when the client terminates the connection (more details about the Acct-Delay-Time can be found in the Acct-Delay-Time section of the Start Accounting scenario section).

When the RADIUS accounting server receives the Stop Accounting packet (see 10 and 11 in Figure 5):

1. Check the LDAP Active objectclass for a matching user. The check is based on unique Session-Id and User-Name and the "is logged on flag".
2. If a matching record is found, the object class is updated and cleared to reflect that the user has terminated the session.
3. The Accounting Stop packet data is written to /var/radius/data/accounting.

The number of seconds the user has been logged on is sent in the Acct-Session-Time attribute.

Like the Start Accounting packet, all received packets are acknowledged to stop retries by the terminal server and minimize network traffic and processing. If the above steps do not complete successfully, all errors are logged to syslog.

The terminal server stops transmitting Accounting Stop packets either when it receives a well-formed acknowledgment from the RADIUS server, or when a predetermined number of attempts has been exhausted. The terminal server re-sends Stop Accounting packets based on a predetermined set of time intervals (for example, 0, 2 min, 4 min, 8 min, and so forth) until acknowledgment or exhaustion occurs (see 12 in Figure 5). If the proxy is defined, Stop packet delivery can also be proxied to an alternate RADIUS accounting server.

Accounting Stop packet description

Below is example of an Accounting Stop packet, as received by the RADIUS accounting server.

Oct  1 15:50:17 server1 radiusd[540746]: [2]:Starting parse_packet()
Oct  1 15:50:17 server1 radiusd[540746]: [2]:Code 4, ID = 67, Port = 49475 Host = 10.10.10.9
Oct  1 15:50:17 server1 radiusd[540746]: [2]:Acct-Status-Type = Stop
Oct  1 15:50:17 server1 radiusd[540746]: [2]:Acct-Session-Id = "000004F5"
Oct  1 15:50:17 server1 radiusd[540746]: [2]:User-Name = "user_id"
Oct  1 15:50:17 server1 radiusd[540746]: [2]:NAS-IP-Address = 10.10.10.9
Oct  1 15:50:17 server1 radiusd[540746]: [2]:NAS-Port = 12
Oct  1 15:50:17 server1 radiusd[540746]: [2]:Service-Type = Framed-User
Oct  1 15:50:17 server1 radiusd[540746]: [2]:Framed-Protocol = PPP
Oct  1 15:50:17 server1 radiusd[540746]: [2]:Framed-IP-Address = 10.10.10.10
Oct  1 15:50:17 server1 radiusd[540746]: [2]:Acct-Input-Octets = 100
Oct  1 15:50:17 server1 radiusd[540746]: [2]:Acct-Output-Octets = 200
Oct  1 15:50:17 server1 radiusd[540746]: [2]:Acct-Session-Time = 7200
Oct  1 15:50:17 server1 radiusd[540746]: [2]:Acct-Terminate-Cause = User-Request

The Stop Accounting packet information, as displayed by RADIUS debug level 9, consists of the following parts:

1. Header information (first line)
2. A series of attribute-value pairs

Both the Start Accounting packet and the Authentication packet share some, but not all, attribute-value pairs. The packet description contains both the unique and shared definitions for convenience. Note in this example, the Acct-Session-Time attribute was sent, and the user "user_id" was logged on for 7,200 seconds.

The accounting data is written to the flat file /var/radius/data/accounting. The format of the data is attribute=value, along with a text time and day prepended to the top of the information and a timestamp appended at the end. The timestamp is the number of seconds since 1970.

Scripts can be written to generate different type of report information on the accounting data, such as usage by month, user_id, or IP- Address.

Part 2 of this series will focus on the installation and configuration of the AIX RADIUS server.

Resources

• Read "AIX RADIUS server, Part 2: Installation and configuration" (developerWorks, January 2005) to learn how to install, configure, authorize, and debug the RADIUS server.
  
  
• Go to the eServer IBM® Solution Connection main page to find solutions that combine software from leading IBM Business Partners with IBM, software, and TotalStorage technology.
  
  
• Visit the Virtual Innovation Center for Hardware for AIX development support. This is the primary source for all pSeries AIX development.
  
  
• Browse for books on these and other technical topics.
  
  
• Want more? The developerWorks AIX and UNIX zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Monitor process
• Authentication process
• Accounting process
• Accounting Start packet description
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into AIX and UNIX on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers