NETS header NETS Homepage UCAR Homepage NCAR Homepage SCD Homepage NETS Homepage About NETS Work requests & support
  Browse NETS topics: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

RADIUS (NETS notes)

Introduction

As of 2005-07-06, we wanted a RADIUS server to handle user accounts on Movaz devices so that we could manage accounts for all Movazes in one place. It made sense to install the RADIUS server on the FRGP workstation, since we may want to serve FRGP devices with RADIUS in the future.

Installing the RADIUS server

The workstation runs Debian, so I did
(as root)
apt-get install freeradius
This created a user named "freerad" and group "freerad", and installed, among other things, ...and started the freeradius daemon.

Configuring the RADIUS server

I went to the freeradius website and read the FAQ, but it was light on details. The "man freeradius" page is quite good. Radius was written to do authentication for terminal servers. When the documentation refers to a NAS, it means a Network Access Server, which means a terminal server. When you see the term NAS, think "RADIUS client", or Movaz box.

To maximize flexibility the Radius server configuration has the following flow.

  1. The preprocess module is used to read the huntgroups file. This results in an attribute being added to the request which describes the logical group the NAS belongs to.
  2. The passwd module is used to read the group file. This assigns one or more attributes to the request which describe the logical groups the user belongs to.
  3. The file module is used to read the users file. The first portion of this file lists users along with their passwords. Users which are not listed here will have their password checked against the system password file.
  4. The second portion of the users file matches user group and hunt group pairs to provide a specific user group access to a specific hunt group.

/etc/freeradius/radiusd.conf

The /etc/freeradius/radiusd.conf file has had the configuration of unused portions and modules commented out. The major change is the addition of the 'my_group' service definition that handles the /etc/freeradius/group file listing user group definitions.

/etc/freeradius/clients.conf

The /etc/freeradius/clients.conf file defines the systems that are allowed to make requests of the server. For security, client systems and the server use a "shared secret" password. This secret is used to authenticate the requests as well as protect the passwords. Since it's quite sensitive, having a unique and hard to guess one for each NAS is a good idea. A quick and easy method of generating a strong key is the following:
od -N 64 /dev/randmo | md5sum
This produces a 32 character hex string. FreeRadius only allows 31 characters in the secret, so simply take the first 31 characters and drop the last one.

/etc/freeradius/users

The users file contains the definitions of which groups are allowed to log in to which huntgroups. It also contains the definition of any Radius-specific users as opposed to users which are also in the system /etc/passwd file.

When adding a new user to the file, the command /usr/local/bin/cryptpasswd can be used to generate a new MD5 style password hash. The format is identical to /etc/shadow so they could be copied from there as well.

/etc/freeradius/group

Each user should be added to one or more groups in this file as appropriate for their access level. If a user is not in any group, they will not be allowed to log in to any devices.

/etc/freeradius/huntgroups

Each NAS needs to be added to the appropriate huntgroup in this file. If a NAS is not part of any huntgroup, it will not be possible to log in to it.

Summary of Configuration Tasks

Testing the daemon locally

The man page suggests that you always run the daemon with the "- X" option to get debug messages, but the /etc/init.d/freeradius file doesn't do it, and I couldn't figure out how to edit the file to make it do it. For testing, I just killed the daemon and ran it from the command line with
(as root)
freeradius -xxyz -l stdout
I used radclient to test that the daemon responded to login attempts for siemsen, as shown below, with the proper password and the proper shared secret (see the usual place).

frgp-ws-1# echo "User-Name = siemsen, User-Password = password" | \
radclient -x localhost auth shared-secret
Sending Access-Request of id 179 to 127.0.0.1:1812
   User-Name = "siemsen"
   User-Password = "xxx"
rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=179, length=20
frgp-ws-1#
To make the changes "take" after you edit the radius config files, do
<as root>
/etc/init.d/freeradius restart

Movaz clients

This section assumes that you have a Unix box running the freeradius server, and a Movaz that is using local authentication, and you want to change the Movaz to use RADIUS authentication. Choose a Movaz that you can access via a terminal server.

To make the Movaz to use RADIUS authentication, use the commands documented in the NETS Movaz accounts and RADIUS authentication page.

Configuring a Movaz to do RADIUS authentication is documented in the Movaz RAYexpress User's Guide in the section titled Configuring RADIUS To Authenticate Users at Login. That section describes some attributes that must be present in the reply packets that are generated by the RADIUS server. If the reply packets don't contain the right attributes, the Movaz will reject the response packet, and RADIUS authentication won't work.

When a Movaz client sends a valid Access-Request (containing a valid username/password) to a freeradius server, the server will respond with an Access-Accept packet. The Access-Accept packet must contain attributes named Service-Type, Movaz-Initial-CLI-Access-Level and Movaz-Max-CLI-Access-Level. If they don't, the Movaz will show the problem when you use a "show log security" command. With freeradius configured the default way, I got 

1991/03/09 04:09:20.966 (  TELNETD) CLI user 'siemsen' failed to log in via radius from 128.117.10.2
1991/03/09 04:09:20.799 (  TELNETD) radAuthenticate: returning Access-Reject [ReplyMsg="hello from NCAR NETS"]
1991/03/09 04:09:20.633 (  TELNETD) radServerTransaction: returning Access-Reject
1991/03/09 04:09:20.466 (  TELNETD) radRspParse: invalid service type 1, forcing Reject
1991/03/09 04:09:20.283 (  TELNETD) radServerTransaction: [Server 192.43.217.2:1812, user siemsen] sending (attempt 1)
RADIUS service types are defined in RFC 2865, which defines RADIUS. Email to Movaz support got me this:
Subject: RE: can't get RADIUS working
From: Dennis King
Date: Fri, 5 Aug 2005 15:00:37 -0400 (13:00 MDT)

Pete,

We only support the service-types as defined below: 

  Service-Type            Freeradius keyword      Corresponding Movaz Attribute Value
  7 (NAS Prompt)          NAS-Prompt-User         Read-Only
  6 (administrative)      Administrative-User     Administrator

Or alternatively movaz specific permissions:

Movaz-Initial-CLI-Access-Level = {readonly | readwrite |administrator |superadministrator}

Dennis A. King

The Movaz-Initial-CLI-Access-Level and Movaz-Max-CLI-Access-Level attributes are not documented by Movaz.

Later, I wanted to know how to store the user account data on the Radius server. So...

From: Pete Siemsen
Sent: Monday, December 05, 2005 1:29 PM
To: Support@movaz.com
Subject: RADIUS accounts

My RayExpress boxes authenticate passwords using a RADIUS server. This is nice, but all it really buys us that when a user wants to change their password, they can do it in one place instead of having to log into each Movaz box.

When I installed the RADIUS server, I hoped that it would allow me to maintain account information on the server. For instance, when we hire a new engineer, I wanted to just create a new account for him on the RADIUS server, and have him be able to log into all our Movaz boxes.

Is there a way to make the RayExpress authenticate the username and password with the RADIUS server, so I can maintain accounts on the RADIUS server?

-- Pete

Subject: RE: RADIUS accounts
Date: Mon, 5 Dec 2005 14:15:14 -0500
From: Dennis King
To: Pete Siemsen

Pete,

The RADIUS server does maintain a users file. The RADIUS servers are configured with usernames, passwords, and authorization levels and act in place of the user database local to an NE. Each user who logs into the NE via RADIUS authentication must be represented in the server's users file. The RADIUS-to-local fallback will only work when connectivity to the RADIUS server is down.

Dennis A. King

Date: Fri, 24 Mar 2006 09:55:12 -0700
From: David Mitchell
To: Pete Siemsen
Subject: Re: Fwd: RADIUS accounts

Pete,

so I added a rule to the movaz ACL on mlra so that the Movaz shelves can speak Radius to the frgp-ws-1. I had already set den-movaz-1 to check Radius before local for authentication. And imagine my surprise when everything worked. I don't have an account in the local user database on den-movaz-1 yet I can log into it. You were closer than you thought. We really just need to spiff up the radius configuration so that people get read-only or read-write as appropriate.

-David

Cisco Clients

Cisco clients can also be configured to use Radius for authentication. Like the Movaz clients, they also have different access levels for privledged and non-privledged access. In Cisco-speak privledged access is enable access.

Normally access to a Cisco device has two steps. The user first connects and authenticates with a password. If sucessful this gives them unprivledged access. They can then issue the command 'enable' and be prompted again for a password. If the correct password is given, the user is then in privledged "enable" mode.

This process can use Radius. The initial login request is passed to Radius and the username and password are checked in the usual manner. If the user then requests to enable, the Cisco will try to authenticate the user '$enab15$' via Radius. If this check succeeds, the user is given enable access. Unfortunately the username of the user requesting enable access is not passed to the Radius server in this second check. As a result, the Radius server cannot use that information as part of it's decision of whether or not to grant access.

When using Radius, it is also possible for the Radius server to specify that a user should be given enable access immediately upon logging in. This is done by specifying the exact same Service-Type attributes used on the Movaz clients. If enable access is provided via this method, there is no need to allow any later '$enab15$' requests to succeed. By doing things this way, it is possible to provide true read-only accounts which cannot escalate their privledge since there would be no valid enable password.

Common problems

This section explains what you might see in the log messages produced by "freeradius -X" in various scenarios. This is assuming the daemon is configured to use the local system's passwd file to authenticate requests.
  1. successful request

    When a request is successful, you'll see

    Sending Access-Accept of id 14 to 10.10.3.70:3203
  2. RADIUS server down or unreachable

    The Movaz user will see

    Cannot connect to remote authentication server. Login using local account.
  3. bad shared secret

    When the daemon receives an access-request packet with a shared secret that doesn't match, you'll see junk in the log message that shows the "User-Password". When the shared secret matches, the User-Password will show the actual password that the user typed.

  4. bad password

    When the daemon receives an access-request packet with a password that doesn't match one in the system passwd file, the logs will contain

    rlm_unix: [siemsen]: invalid password
    modcall[authenticate]: module "unix" returns reject for request 5
  5. "Invalid login" on Movaz even though RADIUS said "Access-Accept"

    This happens when the RADIUS server's response contains the wrong Service-Type.

  6. Backup Passwords On Cisco 2500 Terminal Servers

    Cisco IOS, under 12.0(28d) at least, behaves oddly if the Radius server is unavailable. If the backup password method is 'enable', then the terminal server issues a new 'password:' prompt to the user if the Radius server does not respond. If the backup method is 'line', it compares the password already provided by the user to the line password. Unless the users Radius password is the same as the line password, this check fails and it cycles back to the beginning and provides a Username prompt.

Address comments or questions about this Web page to the Network Engineering & Telecommunications Section at nets-www@ncar.ucar.edu. The NETS is part of the Computational & Information Systems Laboratory of the National Center for Atmospheric Research, which is sponsored by the National Science Foundation and managed by the University Corporation for Atmospheric Research. This website follows the UCAR General Privacy Policy and the NCAR/UCAR/UOP Terms of Use.