How to install RADIUS Last modified 96/1/30 The below examples assume you're putting it in /etc/raddb but you can place it anywhere if you change radius.h and recompile or use the -d flag to tell it what directory to find its configuration files in. If you have pminstall and aren't running NIS (Yellow Pages), run pminstall and choose "Install RADIUS", then as root run "chmod 700 /etc/raddb", then skip down to SETTING UP CLIENTS. If you don't have pminstall, do the following: Add the following 2 lines to /etc/services on your RADIUS server, or if you're running NIS (Yellow Pages) add these lines to your services NIS map on your NIS master and push the maps. radius 1645/udp radiusd radacct 1646/udp Now execute the following commands as root: umask 22 mkdir /etc/raddb /usr/adm/radacct chmod 700 /etc/raddb /usr/adm/radacct Copy the contents of /usr/portmaster/radius/raddb into /etc/raddb. Compile radiusd from /usr/portmaster/radius/src and place it in /etc/radiusd or wherever you prefer. SETTING UP CLIENTS The PortMaster's hostname and the shared secret are placed in /etc/raddb/clients, separated by a tab. Your user entries are placed in /etc/raddb/users. You shouldn't need to change the dictionary file. Start radiusd (you'll probably want to add this to /etc/rc.local or some other file that gets run at system boot time). /etc/radiusd radiusd -x will produce debugging output which may be helpful if things don't seem to be working. If radiusd has problems it'll print to /etc/raddb/logfile or /dev/console if it can. Note that Framed-Compression defaults to on if you don't specify it, so SLIP users who don't want VJ header compression MUST include Framed-Compression = None. Configure your PortMaster so that it knows which host the radiusd is running on and what the shared secret is. On the PortMaster, set the RADIUS server and the shared secret using the "set authentic" and "set secret" commands, or from the Edit RADIUS menu on pmconsole. The secret is case-sensitive and can be up to 16 characters long. Do not use control characters in the secret. You can configure a backup RADIUS server with "set alternate" but it's not required. Make sure all ports have passthrough disabled with "set all security on" followed by "reset all" (Warning! "reset all" will drop off anyone who's on the port at the moment.) On older versions of ComOS you'll need to do "set s0 security on", "set s1 security on", etc. Do a "save all" to save the changes to nonvolatile memory. The PortMaster will check its local User Table first, and if it doesn't find the user there AND passthrough is disabled AND a RADIUS server is set, it will then query the RADIUS server. Make sure your DNS has an in-addr.arpa entry for the PortMaster if you're using Rlogin to Linux. If you're using Rlogin or PortMaster service and get prompted for the password twice, you can add the PortMaster's hostname to your /etc/hosts.equiv file to get rid of the second password prompt. Do NOT do this if you're using Passthrough and not RADIUS!!! If you're already in production with the User Table, I've found the best way to switch over to using RADIUS is first to add a user to RADIUS that's not in the PortMaster's User Table, test with that, and when everything checks out use pmreadpass (if on a supported platform) to copy everyone from the PortMaster to the /etc/raddb/users file, then get rid of the users in the PortMaster's local User Table. pmreadpass is available as part of the PMconsole utilities on supported platforms. Edit the output from pmreadpass to remove the ", Client-ID = 192.9.200.1" clause (the IP address will match your PortMaster's IP address). You'll also need to modify Framed-Filter-Id if you have any. Framed-Filter-Id = "std.ppp" means that the input filter is std.ppp.in (if it exists) and the output filter is std.ppp.out (if it exists). If you have any questions or problems send email to support@livingston.com or call us between 8 a.m. and 5 p.m. Pacific Time Monday through Friday at 800-458-9966 and we'd be glad to help you. ACCOUNTING You'll see two radiusd processes running when you run radiusd 1.16; the child is a RADIUS accounting server. To use RADIUS accounting you must use ComOS 3.1 and RADIUS 1.16. Set up the client as described above, then use "set accounting
" on the PortMaster to set an accounting server, and optionally "set accounting 2 " to set up a backup accounting server. Both local User Table entries and RADIUS entries get logged via accounting, but passthrough entries do NOT get logged. You should see accounting records showing up in /usr/adm/radacct/{portmastername}/detail. Troubleshooting Checklist for RADIUS Accounting: Make sure the directory /usr/adm/radacct exists and is writeable by whatever uid you're running radiusd as. Make sure the radiusd you're running is 1.16, use the -v flag to check. Make sure that you don't have any other process bound to port 1646. Kill radiusd and use netstat -a, there shouldn't be anything on UDP port 1645 or 1646. Start radiusd and use netstat -a again; you should now see something listening on both those ports. Some Operating Systems will display the sockets symbolically, as .radius and .radacct instead of .1645 and .1646. make sure you've done "set accounting
" on the PortMaster, where
is the IP address of the host running radiusd. You can check with "show global". Check /etc/raddb/logfile for error messages. In normal use it should be non-existent or empty or have a few log messages about duplicate IDs. ping the PortMaster from your radiusd host to make sure there's connectivity. If none of that turns up the problem, run radiusd -x on your UNIX host and see if accounting records are displayed. Password Expiration To enable password expiration you must uncomment the Password-Expiration line in /etc/raddb/dictionary and give it a non-zero value. The time is checked on the host radiusd runs on, since the PortMaster doesn't have a time-of-day clock. You may also want to set Password-Warning; the user will receive warnings each time he logs in starting that many days before his password expires. VALUE Server-Config Password-Expiration 30 VALUE Server-Config Password-Warning 5 What the messages in /etc/raddb/logfile mean: > Fri Jan 20 19:14:29 1995: Dropping duplicate: from pm1.eg.com - ID: 125 The RADIUS client on the PortMaster sends its request at 3 second intervals until it gets a reply or has tried 10 times. This logfile message from radiusd (the RADIUS server) means that it got another copy of a request it had already answered; the most common reason for this is that radiusd is taking more than 3 seconds to answer, and the most common reason for THAT is either a loaded host or slow password lookups. If you get lots of these and your users file is quite large, you may want to use radiusd.dbm. Do a "make dbm" in the RADIUS source directory to create builddbm and radiusd.dbm, run builddbm on your /etc/raddb/users file to create a users DBM database, then run radiusd.dbm instead of radiusd. If it's just that your radiusd host is too heavily loaded, consider boosting the priority for radiusd or moving it to a less-loaded host. /etc/raddb/users File A useful way to think of the users file is that you have 3 fields: user check-items reply-items Where check-items are separated by commas and reply-items are indented by white space and seperated by comma & newline. If the User-Name is user, RADIUS checks that all the check-items are present, and if so returns an accept with the list of reply-items, otherwise returns a reject. IPX The IPX network number in the /etc/raddb/users file must be specified in quad decimal notation like an IP address. Here's a PERL program to make it easier to convert them. #!/usr/local/bin/perl # hex - convert ip addresses to hexadecimal and vice versa for (@ARGV) { if (/\./) { # convert . to hex @octets = split(/\./,$_); for $octet (@octets) { printf "%02X",$octet; } print "\n"; } else { # convert hex to . $buf = ''; while (s/\w\w//) { $buf .= hex($&).'.'; } $buf =~ s/\.$/\n/; print $buf; } } Porting Linux On some versions of Linux, and on other systems that use :*: for shadow passwords rather than :x:, modify line 1429 or so of radiusd.c as follows, change if(strcmp(pwd->pw_passwd, "x") == 0) { to if((strcmp(pwd->pw_passwd, "x") == 0) || (strcmp(pwd->pw_passwd, "*") == 0)) { To use shadow passwords on Linux, you usually must also add LIBS=-lshadow to the Makefile. Since there are lots of versions of Linux, your mileage may vary. BSDI 1.16 is for BSDI 1.1. If you're running BSDI 1.0 do not define NOSHADOW, and remove the #include from conf.h If you're running BSD/OS 2.0 use gcc and -DNOSHADOW. You must run radiusd as root if you are using Password = "UNIX" so that getpwnam will return the user password. If you want to use the DBM version of radiusd you'll need to get the GDBM source from prep.ai.mit.edu and link that in, most likely. HPUX A user reports that The default compiler on HPUX 9.01 will not properly compile radiusd 1.16 correctly, and the resulting binary sends packets that the Portmaster doesn't like. The two get in a loop and eventually the Portmaster gives up. "Not the first time that the HP compiler has given me fits." He compiled with gcc and everything worked Livingston has confirmed that the default compiler on HP/UX 9.03 does not compile radiusd 1.16 correctly. "gcc -traditional" works properly. UNIXWARE The comments in the Makefile apply to Unixware before 2.0. In 2.0 and later, do those changes and then edit the Makefile to remove "-o version.o" and to remove -lucb and add -lcrypt. If you're making the DBM version of radiusd, you'll need to change the versiondbm.o and usersdbm.o make entries to avoid the use of the -o flag with the -c flag; Unixware doesn't like that. SCO SCO requires "LIBS = -lsocket -lcrypt". Their encryption libraries are not packaged with their operating systems, but are available on request from SCO, in the SLS supplement "lng190". SOLARIS/X86 2.4 Run radiusd with the -s flag. SGI There's a user-contributed patch for SGI available on ftp://ftp.livingston.com/pub/livingston/contrib/radius.sgi.patch RADIUS TROUBLESHOOTING TIPS Port s1 is assumed in the following examples. If using port s0, make sure the console dipswitch is down. If using another port, adjust the commands described accordingly. * Checking the RADIUS daemon (radiusd) - "radiusd -v" To display the version should say 1.16 - Make sure /etc/radiusd is running - Make sure in the /etc/raddb directory (or wherever you specify with the -d flag) that you have the files: dictionary, users, clients, optionally (but a good idea) logfile - "radiusd -x" to view incoming and outgoing packets from RADIUS * Getting a "Host Unavailable" message after entering username at login: prompt Usually caused by having security on the port off and no rlogind or in.pmd running on the host set for that port. The PortMaster is attempting to do a pass-through login to a host that's not ready for it. To verify that this is the problem, do a "show s1" and if you don't see "(Security)", this is the likely problem. To fix, do a "set s1 security on" followed by "reset s1" and "save all". * 30 sec wait for "Invalid Login" - PortMaster sends 10 Access Requests at 3 second intervals and then gives up with this message (at 30 seconds). - Possible problems: - RADIUS is not running on the server, check that /etc/radiusd is running - "set authentic xxx.xxx.xxx.xxx" is not pointing to the host running radiusd, use "show global" and "show netcon" to check - There is no entry for the PortMaster in the /etc/clients file check this by running radiusd -x; you'll see 10 Access Requests come in with the same ID, but no Access Accept or Access Reject going back - radiusd responses are not getting back to PortMaster check routing table on radiusd host and try ping and traceroute - radiusd responses are getting ignored by PortMaster rare, but can happen if radiusd host has multiple IP addresses or ethernet ports and source of RADIUS Access Accept or Reject is not the same as destination of RADIUS Access Request. * Checking the PortMaster - Make sure that the RADIUS host is pingable from the PortMaster - Make sure ports are set with "set sx security on" - Make sure that "set authentic xxx.xxx.xxx.xxx" points to the host running RADIUS. - Make sure the secret in "set secret somethingclever" matches the secret in the /etc/raddb clients file on the RADIUS server * Checking the /etc/raddb/clients file - Make sure that the entry in the /etc/raddb/clients file is pingable from the server running radiusd - Some platforms running radiusd require a hostname in the clients file and will not accept an ip address. In this case check to see if the PortMaster has a proper Reverse DNS entry using % nslookup > pmacct.livingston.com. Name: pmacct.livingston.com Address: 149.198.96.7 > set q=ptr > 7.96.198.149.in-addr.arpa. Server: server.livingston.com Address: 149.198.1.70 7.96.198.149.in-addr.arpa host name = pmacct.livingston.com > quit * Checking the /etc/raddb/users file - verify spelling and case of each line of user entry. Compare keywords against /etc/raddb/dictionary file to make sure; case IS significant. - Verify that the user can login with a clear text password, then a UNIX password. * If radiusd -x shows more than 1 Access Reject going out for the same ID - Check route back to PortMaster to ensure packets are getting back to the PortMaster. - Check to see if radiusd host is multihomed (more than one ethernet port) - Check for filters between radiusd host and PortMaster is filtering out the RADIUS return packets. - On PortMaster use ptrace to show packets returning from host running radiusd Command> add filter r Command> set filter r 1 permit udp src eq 1645 Command> set filter r 2 permit icmp Command> ptrace r Note that ptrace on a PortMaster never shows UDP or ICMP packets generated on the PortMaster itself, so you won't see your outgoing RADIUS access requests, but you should see the returning packets. * If radiusd -x shows multiple Rejects for same ID and still getting timeouts - check to see if multihomed RADIUS host is using wrong source address when replying (can be done by checking source address of packet from ptrace output) * If logfile shows lots of "Dropping Duplicates" - Check /etc/raddb/logfile (create one if it doesn't exist) - A few "Dropping Duplicates" is no problem. - Host, DNS, NIS too slow is a common cause, but most common cause is - /etc/raddb/users file getting too big and getting timeouts while waiting for radiusd to parse file. The fix to this is to switch to using the DBMized RADIUS (See above section for instructions on how to do that). * If radiusd -x shows one access reject right away - Check spelling for username and password - verify user is not in the PortMaster's local User Table with "show table user", the local User Table is ALWAYS checked first - try cleartext password then UNIX password - if using Password = "UNIX" on a system that has shadow passwords, make sure you run the radiusd as root so it can access the shadow passwords. - verify spelling, case, and syntax of /etc/raddb/users file - check that the shared secret in /etc/raddb/clients matches the one you set on the PortMaster with the "set secret" command - If you're using PMconsole and you hit return in the RADIUS Secret field and then click apply or modify, you've just set your secret to be nothing. This is very easy to do by accident, so don't do it.