SQL Freeradius Tutorial PDF
SQL Freeradius Tutorial PDF
SQL Freeradius Tutorial PDF
guide/SQL HOWTO
guide/SQL HOWTO
Table of Contents
Before You Start Getting Started Basic configuration Setting up the RADIUS database Create MySQL Database Create PostgreSQL Database Configuring FreeRadius to use SQL Populating SQL Test Additional Snippets See Also
Search
Home
All
Files
New
Rename
Edit
History
Quick Links
Wiki Home Concepts for beginners Basic Configuration Pre-built packages Installing from source code Troubleshooting Contributing with GitHub Browse the Source Main web site Always use r a d i u s dX when debugging!
FreeRADIUS Server works out of the box with a large list of SQL servers Unfortunately there are a number of configuration guides available on the internet that are either for very old versions of FreeRADIUS Server, or are wrong, or both. This article will attempt to correct some of the misinformation. These instructions were originally written for FreeRADIUS Server version 1.1.x and had been tested on openSUSE 10.2, CentOS 5.0 and CentOS 5.1. Table of Contents
Before You Start Getting Started Basic configuration Setting up the RADIUS database Create MySQL Database Create PostgreSQL Database Configuring FreeRadius to use SQL Populating SQL Test Additional Snippets See Also
Getting Started
Firstly, you need to install FreeRADIUS Server on your system. As the premiere open source RADIUS suite it is included as a standard package with numerous Operating Systems and has packages for many others. Installation is most easily accomplished by installing a binary package (rpm, deb), but if you have a less well known operating system you may need to build your own.
Basic configuration
http://wiki.freeradius.org/guide/SQL-HOWTO#Create-MySQL-Database 1/5
24/2/2014
See Basic configuration HOWTO
guide/SQL HOWTO
Note: CentOS/RHEL Schema Files Location: /etc/raddb/sql/mysql/schema.sql Note: Ubuntu Schema Files Location: Ubuntu schema files are not called mysql.sql, but schema.sql. The location is: /etc/freeradius/sql/mysql/ m y s q lur o o tpr a d i u s</ e t c / f r e e r a d i u s / s q l / m y s q l / s c h e m a . s q l You might to additionally create this table if you're managing your NASses with FreeRadius: m y s q lur o o tpr a d i u s</ e t c / f r e e r a d i u s / s q l / m y s q l / n a s . s q l
http://wiki.freeradius.org/guide/SQL-HOWTO#Create-MySQL-Database
2/5
24/2/2014
guide/SQL HOWTO
If you're stripping all realm names (i.e. you want user joe@domain.com to authenticate as just 'joe'), then in file raddb/sql/database/dialup.conf , under the 'query config: username' section, you MAY need to adjust the line(s) referring to sql_user_name. I needed to do this originally because we want to dump all realms, but you probably won't need to do this with the latest FreeRadius. For example, in our case I needed to uncomment the line: s q l _ u s e r _ n a m e=' % { S t r i p p e d U s e r N a m e } ' ...and comment out the following line referring to just User-Name. If you want to see what's happening here, switch on all the logging options in radiusd.conf and run radiusd in debug mode (-X) to see what's happening : you'll see " user@domain" being passed to SQL when using User-Name, but just "user" when using Stripped-User-Name. Using the latter, realms worked for me (basically, I strip everything, as all user names are unique on the server anyway). Of course, set all your other SQL options as needed (database login details, etc) Edit /etc/raddb/sites-available/default and uncomment the line containing 'sql' in the authorize{} section. The best place to put it is just after the 'files' entry. Indeed, if you'll just be using SQL, and not falling back to text files, you could comment out or delete the 'files' entry altogether. Additionally, edit /etc/raddb/sites-available/inner-tunnel and uncomment the line containing 'sql' under "authorize {}". See below. Also uncomment the line saying 'sql' in the accounting{} section to tell FreeRADIUS to store accounting records in SQL as well. Optionally add or uncomment 'sql' to the session{} section if you want to do Simultaneous-Use detection. Optionally add or uncomment 'sql' to the post-auth{} section if you want to log all Authentication attempts to SQL. You should not change/delete any other lines in the config file without reading and understanding the comments! Your radiusd.conf should then look something like this: a c c o u n t i n g{ #W el e a v e" d e t a i l "e n a b l e dt o_ a d d i t i o n a l l y _l o ga c c o u n t i n gt o/ v a r / l o g / r a d i u s / r a d a c c t d e t a i l s q l }
Populating SQL
You should now created some dummy data in the database to test against. It goes something like this: In usergroup, put entries matching a user account name to a group name. In radcheck, put an entry for each user account name with a 'Cleartext-Password' attribute with a value of their password. In radreply, create entries for each user-specific radius reply attribute against their username In radgroupreply, create attributes to be returned to all group members Here's a dump of some example 'radius' tables from a MySQL database (With PostgreSQL the formating will look slightly different but it uses exactly the same content). This example includes three users, one with a dynamically assigned IP by the NAS (fredf), one assigned a static IP (barney), and one representing a dial-up routed connection (dialrouter): m y s q l >s e l e c t*f r o mr a d c h e c k ; + + + + + + |i d|U s e r N a m e |A t t r i b u t e |V a l u e |O p | + + + + + + | 1|f r e d f |C l e a r t e x t P a s s w o r d|w i l m a |: = | | 2|b a r n e y |C l e a r t e x t P a s s w o r d|b e t t y |: = | | 2|d i a l r o u t e r |C l e a r t e x t P a s s w o r d|d i a l u p |: = | + + + + + + 3r o w si ns e t( 0 . 0 1s e c ) m y s q l >s e l e c t*f r o mr a d r e p l y ; + + + + + + |i d|U s e r N a m e |A t t r i b u t e |V a l u e |O p | + + + + + +
http://wiki.freeradius.org/guide/SQL-HOWTO#Create-MySQL-Database
3/5
24/2/2014
guide/SQL HOWTO
| 1|b a r n e y |F r a m e d I P A d d r e s s|1 . 2 . 3 . 4 |: = | | 2|d i a l r o u t e r|F r a m e d I P A d d r e s s|2 . 3 . 4 . 1 |: = | | 3|d i a l r o u t e r|F r a m e d I P N e t m a s k|2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 |: = | | 4|d i a l r o u t e r|F r a m e d R o u t i n g |B r o a d c a s t L i s t e n |: = | | 5|d i a l r o u t e r|F r a m e d R o u t e |2 . 3 . 4 . 02 5 5 . 2 5 5 . 2 5 5 . 2 4 8 |: = | | 6|d i a l r o u t e r|I d l e T i m e o u t |9 0 0 |: = | + + + + + + 6r o w si ns e t( 0 . 0 1s e c ) m y s q l >s e l e c t*f r o mr a d g r o u p r e p l y ; + + + + + + |i d|G r o u p N a m e|A t t r i b u t e |V a l u e |O p | + + + + + + |3 4|d y n a m i c |F r a m e d C o m p r e s s i o n|V a n J a c o b s e n T C P I P|: = | |3 3|d y n a m i c |F r a m e d P r o t o c o l |P P P |: = | |3 2|d y n a m i c |S e r v i c e T y p e |F r a m e d U s e r |: = | |3 5|d y n a m i c |F r a m e d M T U |1 5 0 0 |: = | |3 7|s t a t i c |F r a m e d P r o t o c o l |P P P |: = | |3 8|s t a t i c |S e r v i c e T y p e |F r a m e d U s e r |: = | |3 9|s t a t i c |F r a m e d C o m p r e s s i o n|V a n J a c o b s e n T C P I P|: = | |4 1|n e t d i a l |S e r v i c e T y p e |F r a m e d U s e r |: = | |4 2|n e t d i a l |F r a m e d P r o t o c o l |P P P |: = | + + + + + + 1 2r o w si ns e t( 0 . 0 1s e c )
In this example, 'barney' (who is a single user dialup) only needs an attribute for IP address in radreply so he gets his static IP - he does not need any other attributes here as all the others get picked up from the 'static' group entries in radgroupreply. 'fred' needs no entries in radreply as he is dynamically assigned an IP via the NAS - so he'll just get the 'dynamic' group entries from radgroupreply ONLY. 'dialrouter' is a dial-up router, so as well as needing a static IP it needs route and mask attributes (etc) to be returned. Hence the additional entries. 'dialrouter' also has an idle-timeout attribute so the router gets kicked if it's not doing anything - you could add this for other users too if you wanted to. Of course, if you feel like or need to add any other attributes, that's kind of up to you! Note the operator ('op') values used in the various tables. The password check attribute MUST use :=. Most return attributes should have a := operator, although if you're returning multiple attributes of the same type (e.g. multiple Cisco- AVpair's) you should use the += operator instead otherwise only the first one will be returned. Read the docs for more details on operators. If you're stripping all domain name elements from usernames via realms, remember NOT to include the domain name elements in the usernames you put in the SQL tables - they should get stripped BEFORE the database is checked, so name@domain will NEVER match if you're realm stripping (assuming you follow point 2 above) you should just have 'name' as a user in the database. Once it's working without, and if you want more complex realm handling, go back to work out not stripping (and keeping name@domain in the db) if you really want to.
Test
Fire up radiusd again in debug mode (radiusd -X). The debug output should show it connecting to the SQL database. Use radtest (or NTradPing) to test again - the user should authenticate and the debug output should show FreeRADIUS talking to SQL. Congratulations. You're done!
Additional Snippets
To use encrypted passwords in radcheck use the attribute 'Crypt-Password', instead of 'CleartextPassword', and just put the encrypted password in the value field. ( i.e. UNIX crypt'd password). To get NTradPing to send test accounting (e.g. stop) packets it needs arguments, namely acctsession-time. Put something like 'Acct-Session-Time=99999' into the 'Additional RADIUS Attributes' box when sending stops. If you have a Cisco nas, set the cisco-vsa-hack Running a backup FreeRADIUS server and need to replicate the RADIUS database to it? I followed
http://wiki.freeradius.org/guide/SQL-HOWTO#Create-MySQL-Database
4/5
24/2/2014
guide/SQL HOWTO
Colin Bloch's basic instructions at http://www.ls-l.net/mysql/ and got replication setup between two MySQL servers. Real easy. Read the MySQL docs on replication for more details. On the subject of backup servers. If you want to run TWO MySQL servers and have FreeRadius fall over between them, you'll need to do something like this: duplicate your sql.conf and edit the second copy to reflect connecting to your backup server ; then name the files something like sql1.conf and sql2.conf ; in radiusd.conf change and duplicate the include line for sql.conf to include sql1.conf and sql2.conf instead ; in the 'authorize' section of radiusd.conf change the 'sql' entry to a 'group' one, like this: g r o u p{ s q l 1{ f a i l =1 n o t f o u n d=r e t u r n n o o p =2 o k =r e t u r n u p d a t e d=3 r e j e c t=r e t u r n u s e r l o c k=4 i n v a l i d=5 h a n d l e d=6 } s q l 2{ f a i l =1 n o t f o u n d=r e t u r n n o o p =2 o k =r e t u r n u p d a t e d=3 r e j e c t=r e t u r n u s e r l o c k=4 i n v a l i d=5 h a n d l e d=6 } }
Note that if FreeRadius fails over to the second MySQL server and tries to update the accounting table (radacct), nasty things might possibly happen to your replication setup and database integrity as the first MySQL server won't have got the updates... EAP utilizes an inner-tunnel authentication mechanism. I was curious why I wasn't seeing an attempt to use my password after completing the EAP-TLS authentication but a local radclient test showed the correct password. I uncommented "sql" in sites-enabled/inner-tunnel and that was all that was needed to pass authentication. Obviously, this could be explained further or better but if you're stuck give this a try. I'll try to add to this note at a later time.
See Also
SQL rlm_sql rlm_sqlcounter rlm_sqlippool
http://wiki.freeradius.org/guide/SQL-HOWTO#Create-MySQL-Database
5/5