One of the main problems in huge and heterogeneous server environments is non-centralized authentication. It becomes hard to track, maintain and keep the server farm secure as the number of servers grows. Password synchronization enables a user to access resources across systems with a single password and provides simplicity for administrators.
There is a number of different ways to solve this potential problem. For example, NIS/NIS+, LDAP, etc. can be a solution for this. Undoubtedly, each of them has its own advantages, disadvantages and implementation areas. This document describes a password synchronization model based on the RADIUS server.
1. Why RADIUS?
There are two major reasons why you would want to deploy a RADIUS based authentication:
- Existing non-static password solutions
- Wide range of devices and applications which support RADIUS authentication
Yet RADIUS is an open standard and one of the most successful AAA (authentication, authorization and accounting) protocol implementations.
Several commercial and open-source RADIUS servers exist. Features can vary, but most can look up the users in text files, LDAP directory, various databases, etc. The most popular open-source implementation is FreeRADIUS. However, in this paper I will emphasize neither a RADIUS server installation nor configuration.
1.1. Non-static passwords
There are many different solutions which help to eliminate the risks presented by static, shared, stolen or easily guessed passwords from our lives. Following two non-static password authentication methods better fits RADIUS because it uses a challenge-response method for authentication:
- Hardware tokens: use of time-synchronous tokens or other crypto tokens
- One-Time Passwords (OTP): implementation such as S/KEY and its successor OPIE
Hardware tokens is the most popular two-factor authentication method in use today. There is a number of vendors providing their proprietary solutions. However, most of them provide a RADIUS interface as well.
In comparison with hardware tokens, software OTP is a more cost effective solution (maybe even free). It is possible to deploy the RADIUS server with OPIE (One-time Passwords In Everything) and thus have one’s own non-static password implementation for free.
However, to utilize these approaches your application also should support challenge-response authentication.
1.2. Everything over RADIUS
Wide range of different remote access devices, VPNs, firewalls, wireless access points and applications support RADIUS authentication. This abundance provides the ability to create a central authentication system not only for the UNIX server. You can use a single username on routers, databases and web applications as well. Even more, you can use a single password on all these devices in conjunction with the non-static password approach described above.
For example, you can set up Oracle RDBMS to use RADIUS authentication.
2. How it works
2.1. Closer look
This document focuses on the RADIUS based authentication deployment on various UNIX/Linux clients. The proposed solution assumes that all servers will use SSH for remote access, while you can use this approach for other services as well.
It is strongly recommended to eliminate the remote root login by disabling the direct root connection in the SSH daemon configuration to increase the server security.
The proposed approach involves Pluggable Authentication Module (PAM) for authentication configuration on clients. Most modern UNIX systems support PAM, which is a powerful capability that lets you tie a system to many network or local authentication systems, without reconfiguring all of your login services. As a RADIUS module for PAM we will use FreeRADIUS’
pam_radius_auth implementation. Installation and configuration instructions for different UNIX/Linux platforms are shown in Section 3.
Figure 1. RADIUS authentication process
The authentication process is clearly illustrated on Figure 1. Firstly, when the application retrieves the username it consults the
nsswitch.conf file where it looks up the user’s uid, gid and other attributes.
nsswitch.conf points to the
/etc/passwd file. This means that an appropriate record for a user should exists in local
/etc/passwd file on each OS. It will not be necessary if a RADIUS module for
nsswitch exists. Unfortunately, there is no such module, while there is a number of implementations for LDAP. If this is the case, then the solution could be a RADIUS server with a further lookup of user attributes in LDAP.
In our case, users are kept in local
/etc/passwd file without passwords (not with empty passwords). Thus, if the RADIUS server becomes unavailable, these local users will not be able to authenticate, even though they exist in the local database. Advantage of such a model is the independent uid, gid and home directory records which could be different on each system. The only constant is the username. On the other hand, it is hard to create and delete each user on each system.
Finally, the application authenticates the user at the RADIUS server through the
pam_radius_auth module using a number of rules from the application’s PAM configuration file. In our case, for SSH it would be the
2.2. Authorization: rights delegation and roles
After the successful authentication, you may want to assign specific privileges to the user. There are two major models for user authorization in UNIX systems:
- all-or-nothing superuser model – “su” command
- role-based access control (RBAC) or similar least privilege security model
The simplest way to delegate the rights is a superuser model. In this model it is possible to assign permission for regular users to become superusers using
su command. To achieve this regular users should become members of a special group usually know as “wheel”. Undoubtedly, usually no user should be given more privileges than necessary for performing their job.
Nowadays, almost all UNIX and Linux distributions have RBAC implementation. RBAC makes it possible to assign separate capabilities to a specific user or to special accounts that are called roles. Solaris has had it for years; in HP-UX it is implemented since 11i v2; Tru64 has a similar model named Division of Privilege (DOP); different RBAC implementations are available for Linux and xBSD distributions.
Nevertheless, current RBAC implementations are not standardized and should be configured and managed on each system separately. I hope that a standard RBAC database format will be developed soon with an ability to keep the configuration on a remote centralized server or directory. Yet, multi-system RBAC implementation is already becoming an integral part of the identity management technology.
2.3. Known disadvantages
As anything in this world, RADIUS has its own disadvantages. There are a few cryptographic problems which allow analyzing of sniffed traffic as well as a possibility of spoofing requests. Some implementation problems lead to DoS attacks. Thus, it is not recommended to allow public access to a RADIUS server. Detailed security problems of RADIUS protocol are emphasized in the “RADIUS protocol and implementation weakness” document.
Today, DIAMETER protocol is developed to replace RADIUS and fix weaknesses existing in the current implementation. However, DIAMETER is not fully backward compatible and there is no such abundance in hardware and software products which support it as with RADIUS.
2.4. Beyond password synchronization
Needless to say that password synchronization only on UNIX systems is not an option for a fast growing infrastructure. A more advanced version, called Single Sign-On (SSO), enables synchronization across applications as well as systems. Usually, it is hard to achieve single sign-on without a homogeneous IT infrastructure.
Although in broader enterprises even SSO will not help much. That is why today well known vendors provide a technology known as “Identity Management”, which delivers a centralized management of users’ identities and access rights over their complete life cycle; from initial registration through approval, provisioning,
ongoing maintenance, termination and auditing.
A well organized identity management may cover everything within a single IT infrastructure from analog devices such as physical access control to complicated web applications. ID management is not only intended to manage information about the identity of internal employees, but also contractors, customers, partners and vendors.
3. Deployment on UNIX servers
Different UNIX systems have different PAM and SSH implementations. Below I have shown examples for most widely spread UNIX operating systems such as Linux, FreeBSD, Solaris, HP-UX and Tru64.
Note: Tru64 has no native PAM support at the moment and probably will never have it due to its end of life announced after HP and Compaq merge. I have ported OpenPAM to work with Tru64. Patches
and porting guide are available here. If you are looking for Tru64 deployment, be sure to install OpenPAM before continuing with this section.
3.1. Check pam_radius existence
Before you start, check if your distribution already has pam_radius module in it. As different UNIX systems keep PAM modules in different locations, commands below are shown for each of them separately. If it is already installed on your system skip to step 4.3. Note that FreeBSD usually comes with radius module installed.
Linux, HP-UX: $ ls -l /lib/security/ | grep pam_radius Solaris : $ ls –l /usr/lib/security/ | grep pam_radius FreeBSD : $ ls –l /usr/lib/ | grep pam_radius
3.2. pam_radius Installation
FreeRADIUS has an implementation of RADIUS module for PAM. It allows any PAM-capable machine to become a RADIUS client for authentication and accounting requests. Download
pam_radius_auth source code from freeradius.org:
# wget ftp://ftp.freeradius.org/pub/radius/pam_radius-1.3.16.tar # tar xf pam_radius-1.3.16.tar
If you use Solaris, HP-UX or Tru64 you need to apply patches which are available for download here.
Solaris, HP-UX: # patch < pam_radius_hpux_sol.patch Tru64 : # patch < pam_radius_tru64.patch
Make and install PAM module:
Linux : # make; cp pam_radius_auth.so /lib/security/pam_radius_auth.so FreeBSD : # make; cp pam_radius_auth.so /usr/lib/pam_radius.so Solaris : # make; cp pam_radius_auth.so /usr/lib/security/ HP-UX : # make; cp pam_radius_auth.so /lib/security/libpam_radius.1 Tru64 : # make; cp pam_radius_auth.so /usr/local/lib/libpam_radius.so
3.3. RADIUS client configuration
pam_radius_auth will look into
/etc/raddb/server file for an appropriate radius server, shared secret and other server related parameters. Optionally, you can specify a different location for client configuration file (see section 4.5).
# mkdir /etc/raddb # cp pam_radius_auth.conf /etc/raddb/server # chown root /etc/raddb # chmod go-rwx /etc/raddb # chmod go-rwx /etc/raddb/server
Edit and add the existing radius server to your
/etc/raddb/server configuration file.
3.4. Check PAM support in application (SSH)
Check if your SSH distribution is compiled with PAM support. Otherwise it is required to recompile and reinstall SSH daemon with
“--with-pam” option. In this case it is recommended to use OpenSSH – an open source SSH implementation which completely supports PAM and many other useful features. Optionally, to enable non-static password support check challenge-response authentication availability. Also it is strongly
recommended to disable the direct root access. Check for following options in your
PermitRootLogin no ChallengeResponseAuthentication yes UsePAM yes
Certainly, PAM can be configured for any application which supports PAM authentication. For instance, such services as
login, ftp, pop3, etc. can be configured with PAM support and consequentially may be authenticated in RADIUS as well.
3.5. PAM configuration for application (SSH)
There are two different formats for PAM configuration –
pam.conf file and
pam.d folder which contains files with separate application configurations. The only real difference is that the first column in
pam.conf file is the service name instead of the filename being the service name in
pam.d folder format. Examples shown below are in more popular
/etc/pam.d/ssh file for
ssh application and add
pam_unix as shown below:
auth sufficient pam_radius.so no_warn try_first_pass
Here is a complete example for
/etc/pam.d/ssh taken from Linux:
3.6. User configuration
Finally, create users which exist in radius database in the local file
/etc/passwd with the same username and without a password. This will cause failed authentication through
pam_unix module and restrict access from applications which are not allowed (in our case, anything but ssh). If you want to enable these users to become root on the system add them to wheel or root group as well.
A. Porting OpenPAM for Tru64
OpenPAM is an open source PAM library implementation which gathers the best features of Solaris PAM, XSSO, Linux-PAM and some innovations of its own. Some funcions used by OpenPAM are not implemented in Tru64’s native C compiler.
Two of these functions –
vasprintf are neither POSIX nor standard C relevant but included in both GNU and BSD libc. Thus, it is required to use GCC and its
libiberty compatibility library. GCC binaries for Tru64 can be found here: http://gcc.gnu.org/install/binaries.html.
Another non-POSIX function missing in Tru64 is
vsyslog. Small patch which adds
vsyslog function to OpenPAM can be downloaded here.
After installing GCC binaries, download OpenPAM source from OpenPAM.org, apply patch, configure and install:
% gunzip openpam-20050616.tar.gz % tar xf openpam-20050616.tar % patch -d openpam-20050616/lib/ < openpam-20050616_tru64.patch % CPPFLAGS="-I/usr/local/include -I/opt/TWWfsw/gcc343/include" \ LDFLAGS="-L/opt/TWWfsw/gcc343/lib -liberty" \ ./configure --without-pam-su --with-pam-unix # make && make install
By default, OpenPAM will install files to
/usr/local directory and following options should be used to configure OpenSSH:
% ./configure --with-pam --with-zlib --with-ssl-dir=/usr/local/ssl \ --with-cppflags="-I/usr/local/include" --with-ldflags="-L/usr/local/lib"