Using RADIUS to authenticate users with RSA SecurID

Posted by JacobAppelbaum on Fri 16 Mar 2007 at 10:02

Tags: , ,

Recently I was tasked with authenticating users who carry RSA SecurID tokens. I was highly inspired by Jeff Wirth and his success using RADIUS to authenticate with SecurID Tokens on FreeBSD. While I'm not a fan of non-free software, it's possible to make each server authenticate against the non-free RSA Ace server using only free software. This isn't a perfect solution but it's useful when such a requirement is thrust upon you.

The requirements are simple. Your RSA Authentication server must be configured to allow authentication through a RADIUS server. This means that your RSA server has some sort of RADIUS server running on it or somehow you have a RADIUS server authenticating against your RSA ACE server.

As a result of the simple nature of a RADIUS server, you'll have authentication but you'll be lacking directory services. This is suboptimal but still useful in specific cases. This is an example where you want to authenticate and you can handle creating a user name, a user ID and a group ID on the local system.

First we're going to install the PAM module that authenticates against our RADIUS server:

apt-get install -y libpam-radius-auth

The aforementioned package installs the configuration file /etc/pam_radius_auth.conf

If you're savvy enough to read the (mostly worthless) documentation, you'll note that the PAM module uses the odd configuration file location of: /etc/raddb/server. You can safely ignore that file location and only modify /etc/pam_radius_auth.conf

So we'll create a new pam_radius_auth configuration file:

cat << 'EOF' > /etc/pam_radius_auth.conf
#  pam_radius_auth configuration file.
# server[:port] shared_secret      timeout (s)
# Here are two example servers (change this to fit your needs):        SECRETGOESHERE       3        SECRETGOESHERE       3

Now we're going to change the permissions of the file so that the PAM module doesn't complain:

chown root /etc/pam_radius_auth.conf
chmod go-rwx /etc/pam_radius_auth.conf

Now we're going to configure PAM to authenticate against RADIUS. We're also going to cause PAM to create a home directory for any user that successfully authenticates with PAM. I highly suggest you read the previous article on this subject.

We're going to clobber our PAM common-auth file with the next command. This essentially includes every single service we might want to authenticate with. You could authenticate different applications based on needs, though nearly all PAM application specific files include common-auth

Here's an example common-auth for pam_radius_auth:

cat << 'EOF' > /etc/pam.d/common-auth
# Radius auth
# For these next three lines to grant auth, you must have a local user name
# This must be the same as your RADIUS name
# Remove the "debug" argument on the next line after everything works
auth    sufficient debug
account required
session required

# Generic unix auth services below
auth    required nullok_secure

# Automatic home directory creation
# See this article for more information: 
session    required skel=/etc/skel/ umask=0022 silent

Because RADIUS doesn't provide a directory service, we have to have UID and GID information pre-populated on our system. There are a number of methods for doing this. Generally this means using a system other than RADIUS (such as LDAP) to handle authentication. This clearly isn't an option when our goal is to use RADIUS. However, we can simply add the UID and GID information to each system to get around this issue. This allows a user to attempt to login and if they can successfully authenticate with RADIUS, PAM will create their home directory according to their system wide UID and GID. If the user doesn't have a username on the system that matches their RADIUS login name, they won't be able to login to the system.

Here's an example method that pre-populates a system to add a user that can use sudo to gain root entirely authenticated with RADIUS:

useradd ioerror -G admin

At this point, we can login with RADIUS. Your login is your SecurID login name. For a user to login, they require a local unix account name (such as the example pre-populated above) and it must match this SecurID login name. Your password during login is your private pin number and your RSA SecurID token code as one concatenated numeric string.



Posted by thoger (62.168.xx.xx) on Fri 16 Mar 2007 at 15:00
[ Send Message ]
What's /target/etc/raddb? Upstream version of pam_radius_auth uses /etc/raddb/server. Debian version should use /etc/pam_radius_auth.conf.

Have you checked README.Debian.gz?

--- 8< ---

NOTE: The Debian version of libpam-radius-auth uses as default configuration
file /etc/pam_radius_auth.conf.
Upstream has a default set to /etc/raddb/server that does not fit in Debian.
Be aware that the documentation references has not been changed and they
reflect upstream setups.

--- 8< ---

I doubt location /target is FHS-compliant. If package version you have installed really expects configuration only in /target/..., you should definitely file a bug report.

[ Parent | Reply to this comment ]

Posted by JacobAppelbaum (207.7.xx.xx) on Fri 16 Mar 2007 at 20:29
[ Send Message | View Weblogs ]
Yeah, disregard what I previously wrote. I really should have waited until morning to push it out the article! Sorry about that.

[ Parent | Reply to this comment ]

Posted by Anonymous (58.28.xx.xx) on Fri 16 Mar 2007 at 22:37
It's probably worth mentioning freeauth at this point too. The token is generated by a java midlet which runs on a mobile phone, and the whole system plugs into pam.

[ Parent | Reply to this comment ]

Posted by JacobAppelbaum (207.7.xx.xx) on Fri 16 Mar 2007 at 22:40
[ Send Message | View Weblogs ]
That sounds great! Can you share some more information?

[ Parent | Reply to this comment ]

Posted by Anonymous (58.28.xx.xx) on Sat 17 Mar 2007 at 03:12
Take a look at the following link, I've been using this for about 2 weeks now. The midlet is still under heavy development, but it's working fine for me.

[ Parent | Reply to this comment ]

Posted by JacobAppelbaum (207.7.xx.xx) on Sat 17 Mar 2007 at 03:19
[ Send Message | View Weblogs ]
Perhaps you'd like to write up a small article on using it with Debian?

[ Parent | Reply to this comment ]

Posted by MaxLock (58.28.xx.xx) on Sat 17 Mar 2007 at 10:10
[ Send Message ]
Done :)

[ Parent | Reply to this comment ]

Posted by JacobAppelbaum (64.142.xx.xx) on Sun 18 Mar 2007 at 01:21
[ Send Message | View Weblogs ]
Great job!

[ Parent | Reply to this comment ]

Posted by Anonymous (144.34.xx.xx) on Mon 19 Mar 2007 at 17:57
For those who have a bit more control over the whole environment, take a look at CryptoCard ( Its a hardware token solution like SecurID, but is much more open about their software. Its not quite open source, but better than RSA's stuff. I've gotten it working well with Debian and freeradius.

[ Parent | Reply to this comment ]

Posted by Anonymous (83.79.xx.xx) on Wed 30 Jan 2008 at 20:43
wondering how you did this ? (sorry for the off topic)

i'm messing around with libpam-radius-auth & my cryptoserver. always getting some "NullPointerExceptions". Looks like the libpam-radius-auth creates a malformed request (at least for the cryptocard radius server). which version libpam-radius-auth did you use with your debian ?
mine's debian etch with libpam-radius-auth (1.3.16-4.3). :o)

[ Parent | Reply to this comment ]

Posted by Anonymous (193.186.xx.xx) on Tue 24 Jun 2008 at 12:37
I try to use radius to authenticate, but I also would like to have a "Failover root", who I can use to authenticate on my server if my RSA SecureID Server is down. Perhaps anyone can help me. Till now I found nothing for this.

[ Parent | Reply to this comment ]

Posted by JacobAppelbaum (64.142.xx.xx) on Tue 24 Jun 2008 at 17:13
[ Send Message | View Weblogs ]
You can set a static password with the passwd program if you have pam.d configured to allow unix logins as normal with the failed radius password. Personally, I'd suggested only allowing that on the physical console. If at all.

[ Parent | Reply to this comment ]

Posted by Anonymous (193.186.xx.xx) on Thu 26 Jun 2008 at 13:33
Is there any possibility to use radius without predefined local users.

Radius authentication with a Radius ACS Server works, but only if I defined the User with "adduser xxxxx" before. That´s not very comfortable to manage our User at work. If a new User starts working at our company I have to connect to all debian-server and to do the adduser command. Isn´t there any easier way?

[ Parent | Reply to this comment ]

Posted by JacobAppelbaum (64.142.xx.xx) on Thu 26 Jun 2008 at 20:40
[ Send Message | View Weblogs ]
Sadly (or perhaps happily), RADIUS is not a directory service. So you only need to have their user information in /etc/{passwd,group,shadow}. Or you need a way to look them up without using flat files. You can probably combine this with ldap for the directory service information and use radius for authentication.

Either way, you should probably invest in automation (puppet or cfengine) if you don't want to waste a lot of time.

[ Parent | Reply to this comment ]

Posted by Anonymous (217.108.xx.xx) on Fri 20 Aug 2010 at 14:30

When I chmod 600 the file /etc/pam_radius_auth.conf I got the following error when I logout

Aug 20 14:57:09 debian su[11840]: pam_unix(su:session): session opened for user chris by root(uid=1001)
Aug 20 14:57:10 debian su[11840]: pam_radius_auth: Could not open configuration file /etc/pam_radius_auth.conf: Permission denied
Aug 20 14:57:10 debian su[11840]: pam_unix(su:session): session closed for user chris
Aug 20 14:57:10 debian su[11840]: pam_close_session: Cannot make/remove an entry for the specified session

I did this RADIUS configuration but can't figure out why it needs to read this file at logout, is it for accounting ?
Do you see a workaround ? like a local RADIUS proxy ?



[ Parent | Reply to this comment ]

Posted by Anonymous (115.249.xx.xx) on Thu 13 Dec 2012 at 16:11
My ssh server which uses the Radius for authentication kicks me out even when correct the Radius server gives the comment of "Access Accepted"

[ Parent | Reply to this comment ]

Sign In







Current Poll

Which init system are you using in Debian?

( 1068 votes ~ 7 comments )