DEFAULT user configurations match with all usernames that can get to them (i.e., the individual users must have a positive
Fall-Through attribute). Recall from the earlier discussion that
DEFAULT entries may also have
First, let's make sure that all users are checked against the system password file unless they have a password explicitly assigned in the entry.
DEFAULT Auth-Type := System Fall-Through = Yes
Now, include a
DEFAULT entry for all users connecting via a framed protocol, such as PPP or SLIP. Note that I tell the RADIUS client to assign the IP address via the
Framed-IP-Address attribute's value.
DEFAULT Service-Type = Framed-User Framed-IP-Address = 255.255.255.254, Framed-MTU = 576, Service-Type = Framed-User, Fall-Through = Yes
Finally, set the
DEFAULT entry for PPP users. I've already told FreeRADIUS to assign framed protocol users with a dynamic IP address, so all I need to do is set the compression method and explicitly designate PPP as the framed protocol for this default.
DEFAULT Framed-Protocol == PPP Framed-Protocol = PPP, Framed-Compression = Van-Jacobsen-TCP-IP
If a user attempts to connect and matches neither any of the explicit user entries nor any of the
DEFAULT entries, then he will be denied access. Notice that with the last
Fall-Through isn't set: this ensures the user is kicked off if he doesn't match any of the scenarios.
Prefixes and suffixes
You can use prefixes and suffixes appended to the user name to determine what kind of service to provision for that particular connection. For example, if a user adds .shell to their username, you add the following
DEFAULT entry to the users file to provision a shell service for her. FreeRADIUS authenticates her against the system password file, telnets to your shell account machine, and logs her in.
DEFAULT Suffix == ".shell", Auth-Type := System Service-Type = Login-User, Login-Service = Telnet, Login-IP-Host = shellacct1.rduinternet.com
Similarly, you can set up an entry in the users file where if a user connects with a prefix of "s.", then you can provision SLIP service for him. FreeRADIUS can authenticate him against the system passwords, and then fall through to pick up the SLIP attributes from another
DEFAULT entry. Here is an example:
DEFAULT Prefix == "s.", Auth-Type := System Service-Type = Framed-User, Framed-Protocol = SLIP, Fall-Through = Yes
callback feature of the RADIUS protocol is one of the most interesting and useful security measures that you, as an administrator, can enforce. You can configure FreeRADIUS to call a specific user back via his individual entry in the users file. (Of course, you could make a
DEFAULT entry that calls every user back, but the application of that technique is more limited and requires many more resources than a standard implementation.) The following is an example of a callback configuration for user rneis: she dials in, is then called back, is authenticated, and then given a session on the shell account machine.
rneis Auth-Type := System Service-Type = Callback-Login-User, Login-Service = Telnet, Login-IP-Host = shellacct1.rduinternet.com, Callback-Number = "9,1-919-555-1212"
Completely denying access to users
You can set up a specific user entry to deny access to him. For example, you may have an automated script that takes input from your billing system (a list of usernames that have not paid their bills, possibly) and re-writes user entries to deny access. They would write something like the following, for the user aslyter:
aslyter Auth-Type := Reject Reply-Message = "Account disabled for nonpayment."
Alternatively, you could also set up a group on your system called "suspended," and FreeRADIUS could detect whether an individual username was contained within that group and reject access as necessary. To do this, create a
DEFAULT entry much like the following:
DEFAULT Group == "suspended", Auth-Type := Reject Reply-Message = "Account suspended for late payment."
Troubleshooting Common Problems
In this section, I'll take a look at some of the most frequently occurring problems with a new FreeRADIUS setup and how to fix them.
Linking Errors When Starting FreeRADIUS
If you receive an error similar to the following:
Module: Loaded SQL rlm_sql: Could not link driver rlm_sql_mysql: file not found rlm_sql: Make sure it (and all its depend libraries!) are in the search path radiusd.conf: sql: Module instantiation failed.
It means that some shared libraries on the server are not available. There are a couple of possible causes from this.
First, the libraries that are needed by the module listed in the error messages couldn't be found when FreeRADIUS was being compiled. However, if a static version of the module was available, it was built at compile time. This would have been indicated with very prominent messages at compile time.
The other cause is that the dynamic linker on your server is not configured correctly. This would result in the libraries that are required being found at compile time, but not run time. FreeRADIUS makes use of standard calls to link to these shared libraries, so if these calls fail, the system is misconfigured. This can be fixed by telling the linker where these libraries are on your system, which can be done in one of the following ways:
Write a script that starts FreeRADIUS and includes the variable
LD_LIBRARY_PATH. This sets the paths where these libraries can be found.
If your system allows it, edit the /etc/ld.so.conf file and add the directory containing the shared libraries to the list.
Set the path to these libraries inside radiusd.conf using the libdir configuration directive. The radiusd.conf file has more details on this.
Incoming Request Passwords Are Gibberish
Gibberish is usually indicative of an incorrectly formed or mismatched shared secret, the phrase shared between the server and the RADIUS client machine and used to perform secure encryption on packets. To identify the problem, run the server in debugging mode, as described previously. The first password printed to the console screen will be inside a RADIUS attribute (e.g.,
Password = "rneis\dfkjdf7482odf") and the second will be in a logged message (e.g.,
Login failed [rneis/dfkjdf7482odf]). If the data after the slash is gibberish--ensure it's not just a really secure password--then the shared secret is not consistent between the server and the RADIUS client. This may even be due to hidden characters, so to be completely sure both are the same, delete and re-enter the secret on both machines.
The gibberish may also result from a shared secret that is too long. FreeRADIUS limits the secret length to 16 characters, since some NAS equipment has limitations on the length of the secret yet don't make it evident in error logs or the documentation.
NAS Machine Ignores a RADIUS Reply
You may be seeing duplicate accounting or authentication requests without accompanying successful user logins. In this case, it's likely that you have a multi-homed RADIUS server, or at least a server with multiple IP addresses. If the server receives a request on one IP address, but responds with a different one, even if the reply comes from the machine for which the original packet was destined, the NAS machine will not accept it. To rectify this, launch FreeRADIUS with the
-i command-line switch, which binds the daemon to one specific IP address.
CHAP Authentication Doesn't Work Correctly
If PAP authentication works normally, but users authenticating with the CHAP protocol receive errors and denials, you do not have plain text passwords in the users file. CHAP requires this, while PAP can take passwords from the system or from any other source. For each user who needs CHAP authentication, you must add the
Password = changeme check item to his individual entry, of course changing the value of the password as appropriate.
Some people may say using CHAP is much more secure, since the user passwords are not transmitted in plain text over the connection between the user and the NAS. This is simply not true in practice. While hiding the password during transmission is beneficial, the CHAP protocol requires you to leave plain text passwords sitting in a file on a server, completely unencrypted. Obviously, it's much more likely that a cracker will gain access to your RADIUS server, grab the users file with all of these plainly available passwords, and wreak havoc and harm on your network than it is that the same cracker would intercept one user's password during the establishment of the connection.
Jonathan Hassell is a system administrator, IT consultant, and industry author residing in Raleigh, North Carolina.
Return to ONLamp.com.