diff options
author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-28 09:49:46 +0000 |
---|---|---|
committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-28 09:49:46 +0000 |
commit | 50b37d4a27d3295a29afca2286f1a5a086142cec (patch) | |
tree | 9212f763934ee090ef72d823f559f52ce387f268 /doc/modules | |
parent | Initial commit. (diff) | |
download | freeradius-50b37d4a27d3295a29afca2286f1a5a086142cec.tar.xz freeradius-50b37d4a27d3295a29afca2286f1a5a086142cec.zip |
Adding upstream version 3.2.1+dfsg.upstream/3.2.1+dfsgupstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'doc/modules')
-rw-r--r-- | doc/modules/RADIUS-LDAP-eDirectory | 18 | ||||
-rw-r--r-- | doc/modules/ldap_howto.rst | 1648 | ||||
-rw-r--r-- | doc/modules/mschap.rst | 196 | ||||
-rw-r--r-- | doc/modules/rlm_dbm | 195 | ||||
-rw-r--r-- | doc/modules/rlm_eap | 395 | ||||
-rw-r--r-- | doc/modules/rlm_expiration | 23 | ||||
-rw-r--r-- | doc/modules/rlm_krb5 | 47 | ||||
-rw-r--r-- | doc/modules/rlm_pam | 108 | ||||
-rw-r--r-- | doc/modules/rlm_passwd | 50 | ||||
-rw-r--r-- | doc/modules/rlm_python | 76 | ||||
-rw-r--r-- | doc/modules/rlm_soh | 183 | ||||
-rw-r--r-- | doc/modules/rlm_sql | 283 | ||||
-rw-r--r-- | doc/modules/rlm_sqlcounter | 182 | ||||
-rw-r--r-- | doc/modules/rlm_sqlippool | 40 |
14 files changed, 3444 insertions, 0 deletions
diff --git a/doc/modules/RADIUS-LDAP-eDirectory b/doc/modules/RADIUS-LDAP-eDirectory new file mode 100644 index 0000000..abfa1cf --- /dev/null +++ b/doc/modules/RADIUS-LDAP-eDirectory @@ -0,0 +1,18 @@ +"Integrating Novell eDirectory with FreeRADIUS" + +Overview +You can integrate NovellĀ® eDirectoryTM 8.7.1 or later with FreeRADIUS +1.0.2 onwards to allow wireless authentication for eDirectory users. +By integrating eDirectory with FreeRADIUS, you can do the following: +* Use universal password for RADIUS authentication. + Universal password provides single login and authentication for + eDirectory users. Therefore, the users need not have a separate + password for RADIUS and eDirectory authentication. +* Enforce eDirectory account policies for users. + The existing eDirectory policies on the user accounts can still be + applied even after integrating with RADIUS. Also, you can make use + of the intruder lockout facility of eDirectory by logging the + failed logins into eDirectory. + +For configuration information please refer to the Novell documentation + http://www.novell.com/documentation/edir_radius/index.html diff --git a/doc/modules/ldap_howto.rst b/doc/modules/ldap_howto.rst new file mode 100644 index 0000000..53f0f3e --- /dev/null +++ b/doc/modules/ldap_howto.rst @@ -0,0 +1,1648 @@ +LDAP Configuration +================== + +This document describes how to setup Freeradius on a Freebsd machine +using LDAP as a backend. This is by no means complete and your +mileage may vary. If you are having any problems with the setup of +your freeradius installation, please read the documentation that comes +with Freeradius first as that is where all the information for this +project came from. If you find any bugs, typos, alternative ideas, or +just plain wrong information, please let me know by sending an email +to the address above. + +The radius servers in this document are built on Freebsd 4.8, using +Freeradius .81 with OpenLDAP 2.0.27 as the backend. The servers are +designed to support customers for multiple services. In this document +we will use regular dialup and dialup ISDN as examples of two +different services using the same radius server for authentication. + +OVERVIEW +-------- + +The radius servers are to be provisioned by a some sort of system we +will call Billing. Billing could simply be a script, a web front-end, +or an actual integration into a billing system. Billing will provision +to the master LDAP server. The master LDAP server is running slurpd, +which will replicate all changes to the other radius servers. Each +radius server will run a local instance of LDAP. + +The radius servers will be accepting Radius auth packets and Radius +acct packets. The accounting packets will be stored locally on each +radius server and then forwarded to the Accounting radius server, +using radrelay. The Accounting radius server will store all the +radius information in some sort of database such as MySQL, Postgres, +or Oracle. The configuration of the actual Accounting radius server +is outside the scope of this document. Please refer to the freeradius +documentation for setting up that server. + +The Accounting radius server will help to provide a searchable +interface to the accounting data for billing and usage purposes and +could allow a web front-end to be built for helpdesk/customer service +usage. If that is not needed for your purposes, then disregard all +details about the Accounting radius server. + +In order to make sure no data is lost in the event of the Accounting +radius server going down, the replication of data will take place +using radrelay. Radrelay will do the equivalent of a tail on the +detail file and will continually attempt to duplicate each radius +packet that is stored in the detail file and send it off to the +recipient(s) specified. Upon receipt of an accounting_response packet +radrelay will consider that packet completed and continue working on +the others. Each radius server will also be storing its own copy of +all accounting packets that are sent to it. + +Each NAS will be setup with a primary radius server and a failover +radius server. We will spread the load among the group of radius +servers that we have so some are acting as a primary to some NAS's and +acting as a secondary to others. In the event of a radius failure, +the NAS should failover to the backup radius server. How to configure +this is dependent on the particular NAS being used. + +:: + + Will use Radius acct data Billing will provision + for real-time billing out to the Master LDAP + server over LDAP + +------------+ + | Accounting | +---------+ + | Radius | | Billing | + +------------+ +----+----+ + /|\ | + | | + | | + | | + | Provisioning + | Message + | | + Duplicate | + Acct | + | | + | \|/ + | +------------+ + | +------------------| LDAP Master| + | | +------------+ + | | | + | Slurpd Slurpd Replication + | Replication | + | | | + | | \|/ + | | +------------+ + | | | Radius2 | + The Radius servers | | | LDAP Slave | + will create a local | \|/ +------------+ + copy of all acct +-------------+ + packets and then | Radius1 | + fwd a copy back | LDAP Slave | All Radius servers run a + to accounting +-------------+ local copy of LDAP for + /|\ /|\ Authorization and Authentication + | | + | | + | | + | | + Auth Acct + | | + | | + | | + | | + | | + \|/ \|/ + +-----------+ + | | + | | + | NAS | + | | + +-----------+ + The NAS will be setup to + use one of the Radius servers + as primary and the others as failover + + +LDAP +---- + +The LDAP directory is designed to start with the top level of +dc=mydomain,dc=com. The next level of the tree contains the different +services that will be stored within the ldap server. For the radius +users, it will be specified as ou=radius. Below ou=radius, will be +the different types of accounts. For example, ou=users will store the +users and ou=profiles will store the default radius profiles. The +profiles are entries that will be used to store group-wide radius +profiles. The group ou=admins will be a place to enter the users for +Billing, Freeradius, and any other administrative accounts that are +needed. + +:: + + +---------------------+ + | | + | Dc=mydomain,dc=com |Objectclass:organizationalUnit + | |Objectclass:dcObject + +---------------------+ + | + | + \|/ + +---------------+ + | | + | Ou=radius | Objectclass:organizationalUnit + | | + +---------------+ + | + +-----------------------+-------------------------| + | | | + \|/ \|/ \|/ + +---------+ +---------------+ +-------------+ + | | | | | | + |Ou=users | | Ou=profiles | | Ou=admins | + | | | | | | + +---------+ +---------------+ +------|------+ + | | | + | | | + \|/ | \|/ + ----- Objectclass: | ----- Objectclass: + // \\ radiusprofile | // \\ person + | | | | | + \\ // | \\ // + ----- \|/ ----- Dn:cn=freeradius + Dn: uid=example,ou=users, ----- ObjectClass: ou=admins,ou=radius + dc=mydomain,dc=com // \\ radiusprofile dc=mydomain,dc=com + | | + | | + \\ // + ----- + Dn: uid=dial,ou=profiles,ou=radius,dc=mydomain,dc=com + + +An example LDIF file is below. +NOTE: There are unique radius attribute types and objectclasses, these will be +explained in the configuration section. + +:: + + dn: dc=mydomain,dc=com + objectClass: dcObject + objectClass: organizationUnit + ou: Mydomain.com Radius + dc: mydomain + + dn: ou=radius,dc=mydomain,dc=com + objectclass: organizationalunit + ou: radius + + dn: ou=profiles,ou=radius,dc=mydomain,dc=com + objectclass: organizationalunit + ou: profiles + + dn: ou=users,ou=radius,dc=mydomain,dc=com + objectclass: organizationalunit + ou: users + + dn: ou=admins,ou=radius,dc=mydomain,dc=com + objectclass: organizationalunit + ou: admins + + dn: uid=dial,ou=profiles,ou=radius,dc=mydomain,dc=com + objectclass: radiusprofile + uid: dial + radiusServiceType: Framed-User + radiusFramedProtocol: PPP + radiusFramedIPNetmask: 255.255.255.0 + radiusFramedRouting: None + + dn: uid=isdn,ou=profiles,ou=radius,dc=mydomain,dc=com + objectclass: radiusprofile + uid: isdn + radiusServiceType: Framed-User + radiusFramedProtocol: PPP + radiusFramedIPNetmask: 255.255.255.0 + radiusFramedRouting: None + + dn: uid=example,ou=users,ou=radius,dc=mydomain,dc=com + objectclass: radiusProfile + uid: example + userPassword: test + radiusGroupName: dial + radiusGroupName: isdn + + dn: cn=freeradius,ou=admins,ou=radius,dc=mydomain,dc=com + objectclass: person + sn: freeradius + cn: freeradius + userPassword: freeradius + + dn: cn=billing,ou=admins,ou=radius,dc=mydomain,dc=com + objectclass: person + sn: freeradius + cn: freeradius + userPassword: billing + + dn: cn=replica,ou=admins,ou=radius,dc=mydomain,dc=com + objectclass: person + sn: replica + cn: replica + userPassword: replica + +In order to configure the ldap server to understand the radius schema that we +are using, the attribute types and objectclasses must be defined in slapd.conf. +The file is included with the following line in slapd.conf:: + + include /usr/local/etc/openldap/schema/RADIUS-LDAPv3.schema + +Below is the complete Schema:: + + ----Begin RADIUS-LDAPv3.schema---- + + ################################################# + ##### custom radius attributes ################## + + objectIdentifier myOID 1.1 + objectIdentifier mySNMP myOID:1 + objectIdentifier myLDAP myOID:2 + objectIdentifier myRadiusFlag myLDAP:1 + objectIdentifier myObjectClass myLDAP:2 + + attributetype + ( myRadiusFlag:1 + NAME 'radiusAscendRouteIP' + DESC 'Ascend VSA Route IP' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + (myRadiusFlag:2 + NAME 'radiusAscendIdleLimit' + DESC 'Ascend VSA Idle Limit' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + (myRadiusFlag:3 + NAME 'radiusAscendLinkCompression' + DESC 'Ascend VSA Link Compression' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + (myRadiusFlag:4 + NAME 'radiusAscendAssignIPPool' + DESC 'Ascend VSA AssignIPPool' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + + attributetype + (myRadiusFlag:5 + NAME 'radiusAscendMetric' + DESC 'Ascend VSA Metric' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + ################################################# + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.1 + NAME 'radiusArapFeatures' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.2 + NAME 'radiusArapSecurity' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.3 + NAME 'radiusArapZoneAccess' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.44 + NAME 'radiusAuthType' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.4 + NAME 'radiusCallbackId' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.5 + NAME 'radiusCallbackNumber' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.6 + NAME 'radiusCalledStationId' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.7 + NAME 'radiusCallingStationId' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.8 + NAME 'radiusClass' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.45 + NAME 'radiusClientIPAddress' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.9 + NAME 'radiusFilterId' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.10 + NAME 'radiusFramedAppleTalkLink' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.11 + NAME 'radiusFramedAppleTalkNetwork' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.12 + NAME 'radiusFramedAppleTalkZone' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.13 + NAME 'radiusFramedCompression' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.14 + NAME 'radiusFramedIPAddress' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.15 + NAME 'radiusFramedIPNetmask' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.16 + NAME 'radiusFramedIPXNetwork' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.17 + NAME 'radiusFramedMTU' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.18 + NAME 'radiusFramedProtocol' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.19 + NAME 'radiusFramedRoute' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.20 + NAME 'radiusFramedRouting' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.46 + NAME 'radiusGroupName' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.47 + NAME 'radiusHint' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.48 + NAME 'radiusHuntgroupName' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.21 + NAME 'radiusIdleTimeout' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.22 + NAME 'radiusLoginIPHost' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.23 + NAME 'radiusLoginLATGroup' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.24 + NAME 'radiusLoginLATNode' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.25 + NAME 'radiusLoginLATPort' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.26 + NAME 'radiusLoginLATService' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.27 + NAME 'radiusLoginService' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.28 + NAME 'radiusLoginTCPPort' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.29 + NAME 'radiusPasswordRetry' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.30 + NAME 'radiusPortLimit' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.49 + NAME 'radiusProfileDn' + DESC '' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.31 + NAME 'radiusPrompt' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.50 + NAME 'radiusProxyToRealm' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.51 + NAME 'radiusReplicateToRealm' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.52 + NAME 'radiusRealm' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.32 + NAME 'radiusServiceType' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.33 + NAME 'radiusSessionTimeout' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.34 + NAME 'radiusTerminationAction' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.35 + NAME 'radiusTunnelAssignmentId' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.36 + NAME 'radiusTunnelMediumType' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.37 + NAME 'radiusTunnelPassword' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.38 + NAME 'radiusTunnelPreference' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.39 + NAME 'radiusTunnelPrivateGroupId' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.40 + NAME 'radiusTunnelServerEndpoint' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.41 + NAME 'radiusTunnelType' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.42 + NAME 'radiusVSA' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.43 + NAME 'radiusTunnelClientEndpoint' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + ) + + + #need to change asn1.id + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.53 + NAME 'radiusSimultaneousUse' + DESC '' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.54 + NAME 'radiusLoginTime' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.55 + NAME 'radiusUserCategory' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.56 + NAME 'radiusStripUserName' + DESC '' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.57 + NAME 'dialupAccess' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.58 + NAME 'radiusExpiration' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.59 + NAME 'radiusCheckItem' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + ) + + attributetype + ( 1.3.6.1.4.1.3317.4.3.1.60 + NAME 'radiusReplyItem' + DESC '' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + ) + + + objectclass + ( 1.3.6.1.4.1.3317.4.3.2.1 + NAME 'radiusprofile' + SUP top STRUCTURAL + DESC '' + MUST ( uid ) + MAY ( userPassword $ + radiusArapFeatures $ radiusArapSecurity $ radiusArapZoneAccess $ + radiusAuthType $ radiusCallbackId $ radiusCallbackNumber $ + radiusCalledStationId $ radiusCallingStationId $ radiusClass $ + radiusClientIPAddress $ radiusFilterId $ radiusFramedAppleTalkLink $ + radiusFramedAppleTalkNetwork $ radiusFramedAppleTalkZone $ + radiusFramedCompression $ radiusFramedIPAddress $ + radiusFramedIPNetmask $ radiusFramedIPXNetwork $ + radiusFramedMTU $ radiusFramedProtocol $ + radiusCheckItem $ radiusReplyItem $ + radiusFramedRoute $ radiusFramedRouting $ radiusIdleTimeout $ + radiusGroupName $ radiusHint $ radiusHuntgroupName $ + radiusLoginIPHost $ radiusLoginLATGroup $ radiusLoginLATNode $ + radiusLoginLATPort $ radiusLoginLATService $ radiusLoginService $ + radiusLoginTCPPort $ radiusLoginTime $ radiusPasswordRetry $ + radiusPortLimit $ radiusPrompt $ radiusProxyToRealm $ + radiusRealm $ radiusReplicateToRealm $ radiusServiceType $ + radiusSessionTimeout $ radiusStripUserName $ + radiusTerminationAction $ radiusTunnelAssignmentId $ + radiusTunnelClientEndpoint $ radiusIdleTimeout $ + radiusLoginIPHost $ radiusLoginLATGroup $ radiusLoginLATNode $ + radiusLoginLATPort $ radiusLoginLATService $ radiusLoginService $ + radiusLoginTCPPort $ radiusPasswordRetry $ radiusPortLimit $ + radiusPrompt $ radiusProfileDn $ radiusServiceType $ + radiusSessionTimeout $ radiusSimultaneousUse $ + radiusTerminationAction $ radiusTunnelAssignmentId $ + radiusTunnelClientEndpoint $ radiusTunnelMediumType $ + radiusTunnelPassword $ radiusTunnelPreference $ + radiusTunnelPrivateGroupId $ radiusTunnelServerEndpoint $ + radiusTunnelType $ radiusUserCategory $ radiusVSA $ + radiusExpiration $ dialupAccess $ + radiusAscendRouteIP $ radiusAscendIdleLimit $ + radiusAscendLinkCompression $ + radiusAscendAssignIPPool $ radiusAscendMetric ) + ) + ----End RADIUS-LDAPv3.schema---- + + +Now we need to setup the permissions on the ldap server. Notice above we +created three users in the admin ou. These users will be specific for billing, +freeradius, and replication. + +On the master ldap server, we will set the following permissions:: + + access to attr=userPassword + by self write + by dn="cn=billing,ou=admins,ou=radius,dc=mydomain,dc=com" write + by anonymous auth + by * none + + access to * + by self write + by dn="cn=billing,ou=admins,ou=radius,dc=mydomain,dc=com" write + by anonymous auth + by * none + +This will give the billing user write access to add/delete users. For security +we will not give read access to any other users. You can easily add another +read-only user to this setup if you want to build some sort of web interface to +do only reads. + +Now on the slave ldap servers (aka the radius servers) we will setup the +following permissions:: + + access to attr=userPassword + by self write + by dn="cn=replica,ou=admins,ou=radius,dc=mydomain,dc=com" write + by anonymous auth + by * none + + access to dn="ou=users,ou=radius,dc=mydomain,dc=com" + by dn="cn=replica,ou=admins,ou=radius,dc=mydomain,dc=com" write + by dn="cn=freeradius,ou=admins,ou=radius,dc=mydomain,dc=com" read + by anonymous auth + by * none + + access to * + by self write + by dn="cn=replica,ou=admins,ou=radius,dc=mydomain,dc=com" write + by anonymous auth + by * none + + +This will give the replica user write access. This user will be discussed +below and it is involved in the process of replicating the master server to the +slaves. The freeradius user only needs read access to do the lookups for +authorization. + +Now we will want to setup indexes to speed up searches. At the minimum, below +will work. Since all radius lookups are currently using the uid, we will want +to index that. It is also a good idea to index the objectclass attribute. + +# Indices to maintain +index objectClass eq +index uid eq + +Now we need to setup the replication from the master to the slave servers. To +do this, we will add the following to the slapd.conf file on the master: + +On the master LDAP server:: + replica host=radius1.mydomain.com + binddn=cn=replica,ou=admins,ou=radius,dc=mydomain,dc=com + bindmethod=simple credentials=replica + + replica host=radius2.mydomain.com + binddn=cn=replica,ou=admins,ou=radius,dc=mydomain,dc=com + bindmethod=simple credentials=replica + +We will need to add a replica for each slave LDAP server. The binddn is the +name that is used to bind to the slave server, and the credentials is the +secret for that user. + +On the slave LDAP servers:: + + updatedn cn=replica,ou=admins,ou=radius,dc=mydomain,dc=com + updateref ldap://ldapmaster.mydomain.com + +Those will determine what name is allowed to update the LDAP server and if an +update is attempted directly, what server to refer the update to. + +RADIUS +------ + +The radius server is setup to use LDAP for both Authorization and +Authentication. This section will describe what events will take place during +an AAA session with a NAS. When the NAS sends a access_request to the radius +server, the radius server will perform authorization and authentication based +on a series of modules that are defined in radiusd.conf. For example, the +module defined as ldap, will be used to make connections to the LDAP directory. + +An example is seen in raddb/mods-config/ldap:: + +The first thing that is done is authorization of the user. The radius server +will process the modules in the order specified in the authorization section of +radiusd.conf. Currently, they are in the following order. + +1) preprocess +2) suffix +3) files +4) ldap + +The first module will be preprocess. This will first check the huntgroups of +the user coming in. The huntgroups are defined in the file huntgroups and they +are a group listing of the NAS-IP-Addresses that make the access_request. This +is useful in creating specific actions based on the NAS-IP that the request is +made from. An example, is below:: + + isdncombo NAS-IP-Address == 10.10.10.1 + dialup NAS-IP-Address == 10.10.10.2 + dialup NAS-IP-Address == 10.10.10.3 + +We will have one NAS that is used for both ISDN and regular dialup customers, +the other NAS's will be only used for dialup. + +The preprocess module may also use the hints file, to load hints to the radius +server, and add additional hacks that are based on the type of request that +comes in. This is to help with certain NAS's that don't conform to radius +RFC's. Check the comments in radiusd.conf for an explanation on those. + +The second module is suffix. This event will determine which realm the user is +in, based on the User-Name attribute. It is currently setup to split the +username at the occurence of the @symbol. For example, the username of +example@mydomain.com, will be split into example and mydomain.com. The realm +is then checked against the file proxy.conf, which will determine what actions +should be taken for that realm. Certain realms can be setup to be proxied to a +different radius server or set to authenticate locally. Also, the username can +be setup to be stripped from the realm or left intact. An example of +proxy.conf, is listed below. If the realm is to be proxied, then a secret is +needed, which is the secret of the radius server it is to be proxied to. +By default the User-Name will be stripped, unless the nostrip option is set. + +Currently we will not be using realms with our users, but adding this ability +in the future will be much easier with already incorporating proxy.conf into the +setup:: + + proxy server { + synchronous = no + retry_delay = 5 + retry_count = 3 + dead_time = 120 + servers_per_realm = 15 + default_fallback = yes + } + + realm NULL { + type = radius + authhost = LOCAL + accthost = LOCAL + #secret = testing123 + } + + realm DEFAULT { + type = radius + authhost = LOCAL + accthost = LOCAL + #secret = testing123 + } + +The next module is files, which is commonly know as the users file. The users +file will start with either a username to determine how to authorize a specific +user, or a DEFAULT setting. In each line it will define what items must be +present for there to be a match in the form of attribute == value. If all the +required attributes are matched, then attributes specified with attribute := +value will be set for that user. If no match is found the users file will +continue to be processed until there is a match. The last DEFAULT setting will +be set as a catch-all, in case there is no previous match. If a match is made, +the statement of Fall-Through determines if the users file should continue to +be processed or if it should stop right there. + +The Ldap-Group corresponds to the LDAP attribute of radiusGroupName (see ldap +configuration above). The user may be assigned multiple radiusGroupNames, one +for each of the services that the user is authorized for. If the user does +belong to the correct group, then the user will be authorized for that type of +access. If the user does not belong to that group, then there will not be a +match and the users file will continue to be processed. If a match is made and +there is a User-Profile set, then the radius server will lookup the attributes +that exist in that User-Profile in the LDAP directory. These are radius +attributes that will be sent to the NAS as a reply-item. + +An example users file is below:: + + DEFAULT Ldap-Group == disabled, Auth-Type := Reject + Reply-Message = "Account disabled. Please call the helpdesk." + + DEFAULT Huntgroup-Name == isdncombo, NAS-Port-Type == Async, Ldap-Group == dial, + User-Profile := "uid=dial,ou=profiles,ou=radius,dc=mydomain,dc=com" + Fall-Through = no + + DEFAULT Huntgroup-Name == isdncombo, NAS-Port-Type == ISDN, Ldap-Group == isdn, + User-Profile := "uid=isdn,ou=profiles,ou=radius,dc=mydomain,dc=com" + Fall-Through = no + + DEFAULT Huntgroup-Name == dial, Ldap-Group == dial, + User-Profile := "uid=dial,ou=profiles,ou=radius,dc=mydomain,dc=com" + Fall-Through = no + + DEFAULT Auth-Type := Reject + Reply-Message = "Please call the helpdesk." + +Notice that the catchall DEFAULT is set to Reject the user. This will stop the +authorization and immediately send back an access_reject message. Because +business rules are applied above to each scenario where the user will be +authorized for access, if no match is found, then we will want to stop the +process immediately to save resources. + +By using the Ldap-Group feature we can limit user logins to only the services +they are subscribed to. Some examples of possible user setups are below:: + + #user with access to dial-up + dn: uid=user1,ou=users,ou=radius,dc=mydomain,dc=com + objectclass: radiusprofile + uid: user1 + userPassword: whatever + radiusgroupname: dial + + #user with access to ISDN and dial + dn: uid=user2,ou=users,ou=radius,dc=mydomain,dc=com + objectclass: radiusprofile + uid: user2 + userPassword: whatever + radiusgroupname: dial + radiusgroupname: isdn + + #same user as above that was suspended for not paying + dn: uid=user2,ou=users,ou=radius,dc=mydomain,dc=com + objectclass: radiusprofile + uid: user2 + userPassword: whatever + radiusgroupname: dial + radiusgroupname: isdn + radiusgroupname: disabled + +Now that we have authorized the user, the final piece is to authenticate the +user. Authentication is currently done by checking if the password sent in the +access_request packet is correct. This action will be done with an attempted +bind to the LDAP server using the User-Name and User-Password attributes +passed to it from the access_request. If the user is successfully authorized, +then an access_accept message will be sent back to the NAS, with any reply +items that were defined in the authorization section. If the user did not +supply the correct password, then an access_reject message will be sent to the +user. + +If the NAS is sent an access_accept packet then the user will be given access +to the service and the NAS will then send an acct_request packet. This will be +a request packet to start a radius accounting session. The way the server will +log the accounting packets is determined in the detail module in the +radiusd.conf file. Since we will be storing a local copy and forwarding on all +accounting to the Accounting radius server, we will store two local copies on +the machine. The first one is done in a regular detail file as defined in the +following:: + + detail detail1 { + filename = ${radacctdir}/%{Client-IP-Address}/detail-%Y%m%d + permissions = 0600 + dir_permissions = 0755 + } + +The second detail file will be used by the program radrelay to relay a copy of +all accounting packets to the Accounting radius server. This file is stored as +a catchall for all accounting packets. The radrelay program will basically do +a tail on that file and will then attempt to send a copy of each addition to it +to the Accounting server. If the copy is successfully sent, then it will be +deleted from this file. If the Accounting server were to go down, then this +file will continue to build up entries. As soon as the Accounting server is +back online, an attempt to re-send the packets to the Accounting server will +made. This file is defined in the following section of radiusd.conf:: + + detail detail2 { + filename = ${radacctdir}/detail-combined + permissions = 0600 + dir_permissions = 0755 + locking = yes + } + +INSTALLATION +------------ + +The new radius servers are currently built on Freebsd 4.8. As the version may +eventually change, these instructions may no longer apply. The steps for +building the server are the following: + +* Install FreeBSD +* Install other FreeBSD items +* Install OpenLDAP *NOTE: this must be done before installing Freeradius* +* Install FreeRadius + +Under the assumption that FreeBSD is already installed and the kernel rebuilt +to the specifications needed for the machine, there are several other things +that may be needed at this time and the purpose of this is just as a reminder. + +install cvsup-without-gui from the ports collection + +run cvsup on all to update the ports to the most recent versions + +might be a good idea to upgrade the src + +edit and run cvsup on /usr/share/examples/cvsup/standard-supfile + +cd /usr/src - vi Makefile and follow instructions + +install sendmail from ports to keep up to date with the most recent versions. +In the ports collection /ports/mail/sendmail run make; make install; make +mailer.conf. Then edit rc.conf and change to sendmail_enable=NO +radius servers only need the local interface to send daily reports + +edit rc.conf to make sure inetd_enable=NO + +no reason to have extra services running + +if you rebuilt the kernel to add support for IPFIREWALL, then remember to add a +firewall rule to rc.conf + +firewall_enable=YES +firewall_type=OPEN (or actually create a real firewall rule) + +add crontab to keep date accurate for accounting:: + + 15 03 * * * /usr/sbin/ntpdate -s thetimeserver.mydomain.com + +install openldap from ports + +download the freeradius source as the ports collection is often outdated +the default settings are /usr/local/etc/raddb, /var/log/radius.log, /var/log/radacct + +since openldap was installed first, you should not need any special flags to +add ldap support + +Now its time to configure openlap and freeradius. First we will be looking at +configuring OpenLDAP + + +copy RADIUS-LDAPv3.schema to /usr/local/etc/openldap/schema + +edit /usr/local/etc/openldap/slapd.conf + +:: + + ----Begin slapd.conf---- + # $OpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v 1.23.2.7 2003/03/24 03:54:12 + #kurt Exp $ + # + # See slapd.conf(5) for details on configuration options. + # This file should NOT be world readable. + # + include /usr/local/etc/openldap/schema/core.schema + include /usr/local/etc/openldap/schema/RADIUS-LDAPv3.schema + + # Define global ACLs to disable default read access. + + # Do not enable referrals until AFTER you have a working directory + # service AND an understanding of referrals. + #referral ldap://root.openldap.org + + loglevel 296 + + pidfile /var/run/slapd.pid + argsfile /var/run/slapd.args + + # Load dynamic backend modules: + # modulepath /usr/local/libexec/openldap + # moduleload back_bdb.la + # moduleload back_ldap.la + # moduleload back_ldbm.la + # moduleload back_passwd.la + # moduleload back_shell.la + + password-hash {SSHA} + + access to attr=userPassword + by self write + by dn="cn=replica,ou=admins,ou=radius,dc=mydomain,dc=com" write + by anonymous auth + by * none + + access to dn="ou=users,ou=radius,dc=mydomain,dc=com" + by dn="cn=replica,ou=admins,ou=radius,dc=mydomain,dc=com" write + by dn="cn=freeradius,ou=admins,ou=radius,dc=mydomain,dc=com" read + by anonymous auth + by * none + + access to * + by self write + by dn="cn=replica,ou=admins,ou=radius,dc=mydomain,dc=com" write + by anonymous auth + by * none + + + ####################################################################### + # ldbm database definitions + ####################################################################### + + database bdb + suffix "dc=mydomain,dc=com" + rootdn "cn=root,dc=mydomain,dc=com" + # Cleartext passwords, especially for the rootdn, should + # be avoid. See slappasswd(8) and slapd.conf(5) for details. + # Use of strong authentication encouraged. + rootpw {SSHA}Eu5EwPxTrwhEGrXQ9SaQZyfpu4iHt3NP + # The database directory MUST exist prior to running slapd AND + # should only be accessible by the slapd and slap tools. + # Mode 700 recommended. + directory /var/db/openldap-data + # Indices to maintain + index objectClass eq + index uid eq + mode 0600 + cachesize 2000 + + # replica one for each + #replica host=radius1.mydomain.com + # binddn="cn=replica,ou=admins,ou=radius,dc=mydomain,dc=com" + # bindmethod=simple credentials=secret + + replogfile /var/db/openldap-slurp/replog + + ## REMEMBER TO ADD THIS TO THE SLAVES + updatedn "cn=freeradius,ou=admins,ou=radius,dc=mydomain,dc=com" + updateref ldap://ldapmaster.mydomain.com + ----End slapd.conf---- + + +To create a rootdn that is not stored in plain text, enter the following command:: + + $ slappasswd + +it will ask for password and verification:: + + New password: + Re-enter new password:: + +while in the shell create the directory for the ldap database, this must be created before slapd can start:: + + $ mkdir /var/db/openldap-data + +move the slapd.sh.sample file to slapd.sh in /usr/local/etc/rc.d:: + + $ mv /usr/local/etc/rc.d/slapd.sh.sample slapd.sh + +enable logging in /etc/syslog.conf by adding the following:: + + local4.* /var/log/ldap.log + restart syslogd + +start it up on both the master and slave ldap servers:: + + $ /usr/local/etc/rc.d/slapd start + +create the structural ldif, schema.ldif:: + + ----Begin schema.ldif---- + dn: dc=mydomain,dc=com + objectClass: dcObject + objectClass: organizationUnit + ou: Mydomain.com Radius + dc: mydomain + + dn: ou=radius,dc=mydomain,dc=com + objectclass: organizationalunit + ou: radius + + dn: ou=profiles,ou=radius,dc=mydomain,dc=com + objectclass: organizationalunit + ou: profiles + + dn: ou=users,ou=radius,dc=mydomain,dc=com + objectclass: organizationalunit + ou: users + + dn: ou=admins,ou=radius,dc=mydomain,dc=com + objectclass: organizationalunit + ou: admins + + dn: uid=dial,ou=profiles,ou=radius,dc=mydomain,dc=com + objectclass: radiusprofile + uid: dial + radiusServiceType: Framed-User + radiusFramedProtocol: PPP + radiusFramedIPNetmask: 255.255.255.0 + radiusFramedRouting: None + + dn: uid=isdn,ou=profiles,ou=radius,dc=mydomain,dc=com + objectclass: radiusprofile + uid: isdn + radiusServiceType: Framed-User + radiusFramedProtocol: PPP + radiusFramedIPNetmask: 255.255.255.0 + radiusFramedRouting: None + + dn: uid=example,ou=users,ou=radius,dc=mydomain,dc=com + objectclass: radiusProfile + uid: example + userPassword: test + radiusGroupName: dial + radiusGroupName: isdn + + dn: cn=freeradius,ou=admins,ou=radius,dc=mydomain,dc=com + objectclass: person + sn: freeradius + cn: freeradius + userPassword: freeradius + + dn: cn=billing,ou=admins,ou=radius,dc=mydomain,dc=com + objectclass: person + sn: freeradius + cn: freeradius + userPassword: billing + + dn: cn=replica,ou=admins,ou=radius,dc=mydomain,dc=com + objectclass: person + sn: replica + cn: replica + userPassword: replica + ----End schema.ldif---- + +add the organizational structure to the master ldap database:: + + $ ldapadd -D uid=billing,ou=admins,ou=radius,dc=mydomain,dc=com -w billing -f + schema.ldif -h ldapmaster.mydomain.com + +run slapcat to see what the directory looks like:: + + $ slapcat + +If all went well the LDAP directory should be up and running and propagated to +the slaves. Now you can add your users to the master. + +Now its time to setup FreeRadius. First cd into /usr/local/etc/raddb and take +a look at all the configuration files, they are heavily documented so you may +wish to read through them all before making and changes. + + +edit huntgroups to specify a NAS to a huntgroup:: + + ----Begin huntgroups---- + # dialup and isdn + isdncombo NAS-IP-Address == 10.10.10.1 + + # just dialup + dialup NAS-IP-Address == 10.10.10.2 + dialup NAS-IP-Address == 10.10.10.3 + ----End huntgroups---- + +* edit proxy.conf to setup the different realms:: + + ----Begin proxy.conf---- + proxy server { + synchronous = no + retry_delay = 5 + retry_count = 3 + dead_time = 120 + servers_per_realm = 15 + default_fallback = yes + } + + realm NULL { + type = radius + authhost = LOCAL + accthost = LOCAL + #secret = testing123 + } + + realm DEFAULT { + type = radius + authhost = LOCAL + accthost = LOCAL + #secret = testing123 + } + ----End proxy.conf---- + + -edit clients.conf to setup the NAS's that can talk to it + + + ----Begin clients.conf---- + client 127.0.0.1 { + secret = example + shortname = localhost + nas_type = other + } + + + # isdn and dialup nas + client 10.10.10.1 { + secret = example + shortname = isdn + nas_type = cisco + } + + #dialup only + client 10.10.10.2 { + secret = example + shortname = dialup1 + nas_type = cisco + } + + client 10.10.10.3 { + secret = example + shortname = dialup2 + nas_type = cisco + } + ----End clients.conf---- + + +You may wish to look at the other files, but they should all be OK by default. + +create startup files in /usr/local/etc/rc.d + +radiusd.sh - the radiusd startup file:: + + ----Begin radiusd.sh---- + #!/bin/sh + case "$1" in + start) + /usr/local/sbin/radiusd + echo -n ' radiusd' + ;; + stop) + if [ -f /usr/local/var/run/radiusd/radiusd.pid ]; then + kill -TERM `cat /usr/local/var/run/radiusd/radiusd.pid` + rm -f /usr/local/var/run/radiusd/radiusd.pid + echo -n ' radiusd' + fi + ;; + restart) + if [ -f /usr/local/var/run/radiusd/radiusd.pid ]; then + kill -HUP `cat /usr/local/var/run/radiusd/radiusd.pid` + echo 'radiusd restarted' + fi + ;; + *) + echo "Usage: ${0##*/}: { start | stop | restart }" 2>&1 + exit 65 + ;; + esac + ----End radiusd.sh---- + +radrelay.sh - the radrelay startup file:: + + + ----Begin radrelay.sh---- + #!/bin/sh + case "$1" in + + start) + /usr/local/bin/radrelay -a /var/log/radacct -d /usr/local/etc/raddb \ + -S /usr/local/etc/raddb/radrelay_secret -f -r accounting.mydomain.com:1813 \ + detail-combined + echo -n ' radrelay started' + ;; + + + stop) + /usr/bin/killall radrelay + echo ' radrelay stopped' + ;; + + *) + echo "Usage: $[0##*/}: { start | stop }" 2>&1 + exit 65 + ;; + + esac + ----End radrelay.sh---- + +create radrelay_secret in /usr/local/etc/radddb +This file will contain the secret to connect to the Accounting radius server:: + + ----Begin radrelay_secret---- + example + ----End radrelay_secret---- + +Now fire them up:: + $ /usr/local/etc/rc.d/radiusd.sh start + $ /usr/local/etc/rc.d/radrelay.sh start + +You should be all set to start testing now. + +OTHER RANDOM NOTES AND THOUGHTS +------------------------------- + +The client programs used to connect to the ldap directory are: + +ldapadd: + to add a record +ldapmodify: + to modify a record +ldapdelete: + to delete a record +ldapsearch: + to search for a record +slapcat: + to show the entire directory +slappaswd: + to generate a crypted password + +Read the man pages on those commands, they tell you everything you +need to know. + +They all follow this basic syntax:: + + $ ldapwhatever -D "uid=someone,ou=admins,ou=radius,dc=mydomain,dc=com" -w thesecret -andthenotherstuff + +Finally, if you are having trouble with LDAP, run it in debug mode by +changing the following in slapd.sh:: + + slapd_args= + +to:: + + slapd_args= '-d 3' + +There is a program included with freeradius to test the radius server, +its called radclient. Typing it alone will tell you all the options. +You will need to create a file that contains radius attributes, such +as:: + + User-Name = example + User-Password = test + Service-Type = Framed-User + NAS-IP-Address = 10.10.10.1 + NAS-Port-Type = Async + +Then you fire that radius packet at the server by issuing:: + + $ radclient -f testradiusfile localhost auth thesecret + +-f = filename +localhost is the server you are hitting +auth or acct depending on the type of packet +thesecret to connect to that server + +Finally, if you are having trouble you can run radius in debug mode +and it will output everything that happens to the screen. To do that, +kill the current process and run:: + + $ radiusd -X + + +LINKS +----- + +FREERADIUS +++++++++++ + +* _`FreeRADIUS`: http://www.freeradius.org +* _`FreeRADIUS Documentation`: http://freeradius.org/documentation/ +* _`FreeRADIUS Wiki`: http://wiki.freeradius.org/ + +OPENLDAP +++++++++ + +* _`OpenLDAP`: http://www.openldap.org +* _`OpenLDAP Administrator's Guide`: http://www.openldap.org/doc/admin21 + +RFCs +++++ + +* _`RFC2865: RADIUS Authentication`: http://freeradius.org/rfc/rfc2865.txt +* _`RFC2866: RADIUS Accounting`: http://freeradius.org/rfc/rfc2866.txt +* _`RFC2869: RADIUS Extentions`: http://freeradius.org/rfc/rfc2869.txt +* _`RFC2251: LDAP v3`: http://www.ietf.org/rfc/rfc2251.txt +* _`RFC2252: LDAP v3 Attribute Syntax Definitions`: http://www.ietf.org/rfc/rfc2252.txt +* _`RFC2253: LDAP UTF-8 String Representation of Distinguishe d Names (DNs)`: http://www.ietf.org/rfc/rfc2252.txt +* _`RFC2849: LDAP Data Interchange Fromat (LDIFs)`: http://www.ietf.org/rfc/rfc2849.txt +* _`RFC3377: LDAP v3 Technical Specs`: http://www.ietf.org/rfc/rfc3377.txt diff --git a/doc/modules/mschap.rst b/doc/modules/mschap.rst new file mode 100644 index 0000000..37fcb9d --- /dev/null +++ b/doc/modules/mschap.rst @@ -0,0 +1,196 @@ +rlm_mschap +========== + +The mschap module provides support for MS-CHAPv1 and MS-CHAPv2, which is +a common authentication mechanisms for Microsoft clients. + +If you want to support mschap, there are only 3 possibilities: + + 1. You have access to the users plaintext password, and you configure + FreeRADIUS to read this, and set the Cleartext-Password control attribute. + + 2. You have access to the NT (MS-CHAPv2) or LM (MS-CHAPv1) hashes, + and you configure FreeRADIUS to read this and set the NT/LM-Password + control attribute. + + 3. You have Samba installed, joined into a windows domain, and use + the ntlm_auth helper binary to pass authentication onwards to + a domain controller. + +These are the ONLY possibilities; MS-CHAP is IMPOSSIBLE if you e.g. only +have the unix/md5/sha crypt of your users password. + +For more info, see: + + http://deployingradius.com/documents/protocols/compatibility.html + +EAP-MSCHAPv2 +============ + +The EAP module provides MS-CHAPv2 support as well. It simply passes the +data through to the mschap module, so you must configure mschap properly. + +ntlm_auth +========= + +Method 3 above involves configuring the mschap module to call the Samba +ntlm_auth helper: + +:: + + mschap { + ntlm_auth = "/path/to/bin ..." + } + +You need to be careful about setting this command line. There are several +options for the arguments, in particular username and domain: + + * --username=%{User-Name} - this will fail if you're using realms or host-based auth + * --username=%{mschap:User-Name} - this will fail if using using suffix i.e. user@domain + +You'll need to fit this to your local needs. + +Disabling ntlm_auth for some users +---------------------------------- + +You might have some users in the domain, and others in files or SQL that you +want to authenticate locally. To do this, set:: + + MS-CHAP-Use-NTLM-Auth := 0 + +This will disable ntlm_auth for that user/group. This is also obeyed +for password changes (see below). + +Password changes +================ + +From FreeRADIUS version 3.0.0 the mschap module supports password changes. + +There are two options, ntlm_auth and local. + +ntlm_auth +--------- + +If you are using ntlm_auth to check passwords, you must also use +ntlm_auth to change passwords. In modules/mschap you should configure:: + + mschap { + ntlm_auth = "...." + passchange { + + # path to the binary + ntlm_auth = "/path/to/ntlm_auth --helper-protocol=ntlm-change-password-1" + + # initial data to send + # this MUST be supplied + ntlm_auth_username = "username: %{mschap:User-Name}" + ntlm_auth_domain = "nt-domain: %{%{mschap:NT-Domain}:-YOURDOMAIN}" + + # Or, you could try: + ntlm_auth_username = "full-username: %{User-Name}" + # ntlm_auth_domain - disabled + + } + + +If you are using ntlm_auth, then domain controllers might say +"Password expired" if the user password is valid but has expired; the +mschap module will detect this and return error 648 to the client, +instructing it to try a password change. + +Note: if you have disabled ntlm_auth for a user/group, this will apply +for password changes too - they will fall through to using the Local +method. + +Local +----- + +If you are performing mschap locally with Cleartext-Password/NT-Password, you +can decrypt and process the password change locally. To do this, you configure +the "local_cpw" string:: + + mschap { + passchange { + local_cpw = "%{xlat:...} + } + } + +To actually force a client to change passwords, you must set the expiry bit +in the SMB-Account-Ctrl value - for example:: + + update control { + # U == user + # e == expired + SMB-Account-Ctrl-Text := '[Ue]' + } + +This will cause the client to receive "error 648 - password +expired". Obviously you will need to ensure your local_cpw xlat clears +this value, or else the client password will be expired the next time +they log in. For example, you might use an SQL stored procedure to +change passwords:: + + mschap { + passchange { + local_cpw = "%{sql:select change_password('%{SQL-User-Name}','%{MS-CHAP-New-NT-Password}')}" + } + } + +...and an example stored procedure for Postgres might be:: + + CREATE FUNCTION change_password(raduser text, ntpassword text) RETURNS text + LANGUAGE plpgsql + AS $$ + BEGIN + update radcheck set value=ntpassword where username=raduser and attribute='NT-Password'; + if not FOUND then + -- the user does not exist; die + return ''; + end if; + update radcheck set value=replace(value,'e','') where username=raduser and attribute='SMB-Account-Ctrl-Text' and value like '%e%'; + return 'ok'; + END; + $$; + + +The local_cpw xlat has access to two variables: + + * MS-CHAP-New-NT-Password - the new value of NT-Password + * MS-CHAP-New-Cleartext-PAssword - the new value of Cleartext-Password + +This allows you to do things like:: + + # update via SQL + local_cpw = "%{sql:update radcheck set value='%{MS-CHAP-New-NT-Password}' where username='%{SQL-User-Name} and attribute='NT-Password'}" + +Or:: + + # update via exec/script + local_cpw = "%{exec:/my/script %{User-Name} %{MS-CHAP-New-Cleartext-Password}}" + +WARNING - wherever possible, you should use +MS-CHAP-New-NT-Password. The reason is that cleartext passwords have +undergone unicode transformation from the client encoding (utf-16) to +the server encoding (utf-8) and the current code does this in a very +ad-hoc way. The reverse transformation is also not done - when the +server reads Cleartext-Password out of files/database, it assumes +US-ASCII and thus international characters will fail. + +N.B. this could be fixed, if we wanted to pull in something like iconv. + +In addition, you should beware of Cleartext-Password when using SQL; +any password character not in safe_characters will be encoded as a hex +number, e.g. =20. + +Password changes over EAP +========================= + +You must set the following in eap.conf:: + + eap { + mschapv2 { + send_error = yes + } + } + +Otherwise password changes for PEAP/MSCHAPv2 will not work. diff --git a/doc/modules/rlm_dbm b/doc/modules/rlm_dbm new file mode 100644 index 0000000..8ace2ff --- /dev/null +++ b/doc/modules/rlm_dbm @@ -0,0 +1,195 @@ +Radius DBM module + +0. INTRODUCTION + + rlm_dbm uses a Berkeley or GDBM <** database to store use information. It + is a lot faster than the files and passwd modules, takes less memory than + the fastusers module and does not require additional server software as + the LDAP and SQL modules does. In addition it supports groups, and of + course multiple entries per user or group. + +1. WHAT DOES IT DO + + Basically, it opens the file you specifies in radiusd.conf and authenticates + users out of it. The file has to be a Berkeley or GDBM <** file database, + and may be created by rlm_dbm_parse or by a custom program of your choice. + +2. HOW TO USE IT + + Put the module declaration in your radiusd.conf. It should in general look + like this: + + dbm { + usersfile = ${confdir}/users.db + } + Note: some dbm libraries add .db suffix by itself. + + Then put "dbm" in the "authorize {}" section of your radiusd.conf: + + authorize { + preprocess + realms + dbm + } + +3. MODULE OPTIONS + + The only option is "usersfile", which is the path and filename of the + database file you want rlm_dbm to look for users and groups in. This + file needs to be generated, either by the rlm_dbm_parse program or by + some custom program, for instance a Perl program using the DB_File or + GDBM_File <** modules. + +4. EXTERNAL UTILITIES + + rlm_dbm_cat + + rlm_dbm_cat: [-f file] [-w] [-i number] [-l number] [-v] [username ...] + + rlm_dbm_cat simply lists the definition(s) of the username(s) or group + name(s), or the entire database. It takes the following options: + + -f <filename> + + The file name of the database to list. + + -w + Long lines should be wrapped + + -i <number> +Set the left margin then wrapped. + -l <number> +How long line should be to be wrapped (wrap threshold) + + -v + + Print the version number and exit. + + rlm_dbm_parse + + rlm_dbm_parser [-c] [-d raddb] [-i inputfile] [-o outputfile] [-x] + [-v] [-q] [username ...] + + rlm_dbm_parses reads a file of the syntax defined below, and writes + a database file usable by rlm_dbm or edits current database. + It takes the following options: + + -i <file> + + Use <file> as the input file. If not defined then use standard input. + + -o + + Use <file> as the output file. + + -c + + Create a new database (empty output file before writing) + + -x + + Enable debug mode. +; Multiple x flag increase debug level + + -q + + Do not print statistics (quiet). + + -v + + Print the version and exit. + + -r + + Remove a username or group name from the database. + +5. INPUT FORMAT + + rlm_dbm_parse reads a format similar to the one used by the files + module. In incomplete RFC2234 ABNF, it looks like this: + + entries = *entry + entry = identifier TAB definition + identifier = username / group-name + username = +PCHAR + groupname = +PCHAR + definition = (check-item ",")* LF ( *( reply-item ",") / ";" ) LF + check-item = AS IN FILES + reply-item = AS IN FILES + +*** need definition of username and groupname *** + + As an example, these are the standard files definitions (files module). + +---8<--- + DEFAULT Service-Type == Framed-User + Framed-IP-Address = 255.255.255.254, + Framed-MTU = 576, + Service-Type = Framed-User, + Fall-Through = Yes + +#except who call from number 555-666 + DEFAULT Auth-Type := Reject,Service-Type ==Framed-User, + Calling-Station-ID == "555-666" + +#or call number 555-667 + DEFAULT Auth-Type := Reject,Service-Type ==Framed-User, + Calling-Station-ID == "555-667" +---8<--- + + To be a valid rlm_dbm input file, it should look like this: + +---8<--- + DEFAULT Service-Type == Framed-User # (1) + Framed-IP-Address = 255.255.255.254, # comma, list cont'd + Framed-MTU = 576, + Service-Type = Framed-User, + Fall-Through = Yes # \n, end of list + Auth-Type := Reject,Service-Type ==Framed-User, # (2) + Calling-Station-ID == "555-666" + ; # ;, no reply items + Auth-Type := Reject,Service-Type ==Framed-User, # (3) + Calling-Station-ID == "555-667" + ; # ditto +---8<--- + + This user (the DEFAULT user) contains three entries, 1, 2 and 3. The + first entry has a list of reply items, terminated by a reply item + without a trailing comma. Entries 2 and 3 has empty reply lists, as + indicated by the semicolon. This is necessary to separate an empty + line (which is ignored) from the empty list. + Definition Fall-Through = Yes used in order to say module to check next + record. By default Fall-Through = Yes. + + Groups + + This is implemented with the special User-Category attribute. Simply + set this as a reply item, and rlm_dbm will include the groups definition + when evaluating the check and reply items of the user. The group defined + the same way as users. Here is a short example: + +---8<--- +# group definitions +gendialup + Service-Type = Framed-User, + Cisco-AVPair += "ip:addr-pool=SANDY", + Framed-Protocol = PPP + +locked Auth-Type := Reject + Reply-Message = "Your account has been disabled." + +# user definitions +ssalex Auth-Type := Local, Password == "passs" + User-Category = "GenDialup" + +ssmike Auth-Type := Local, Password == "pass1" + User-Category = "Locked" +---8<--- + +6. ACKNOWLEDGMENTS + + Author - Andrei Koulik <rlm_dbm@agk.nnov.ru> + Documentation - Bjųrn Nordbų <bn@nextra.com> +8. Bug reports: + rlm_dbm_bug@agk.nnov.ru + diff --git a/doc/modules/rlm_eap b/doc/modules/rlm_eap new file mode 100644 index 0000000..4f903af --- /dev/null +++ b/doc/modules/rlm_eap @@ -0,0 +1,395 @@ + + + Extensible Authentication Protocol (EAP) + + +INTRODUCTION + + Extensible Authentication Protocol(EAP), rfc2284, is a general protocol + that allows network access points to support multiple authentication + methods. Each EAP-Type indicates a specific authentication mechanism. + 802.1x standard authenticates wireless LAN users trying to access + enterprise networks. + + RADIUS attribute used for EAP is EAP-Message, 79(rfc2869). RADIUS + communicates all EAP messages by embedding them in this attribute. + + General Terminology + Supplicant/EAP Client - is the software on the end-user/client machine + (machine with the wireless card). + Authenticator/NAS/Access Point(AP) - A network device providing users + with a point of entry into the network. + EAPOL - EAP over LAN as defined in 802.1x standard. + EAPOW - EAP over Wireless. + + + +----------+ +----------+ +----------+ + | | EAPOL | | RADIUS | | + | EAP |<------>| Access |<------>| RADIUS | + | Client | EAPOW | Point | (EAP) | Server | + | | | | | | + +----------+ +----------+ +----------+ + + + The sequence of events, for EAP-MD5, runs as follows: + 1. The end-user associates with the Access Point(AP). + 2. The supplicant specifies AP to use EAP by sending EAP-Start. + 3. AP requests the supplicant to Identify itself (EAP-Identity). + 4. Supplicant then sends its Identity (username) to the AP. + 5. AP forwards this EAP-response AS-IS to the RADIUS server. + (The supplicant and the RADIUS server mutually authenticate via AP. + AP just acts as a passthru till authentication is finished.) + 6. The server sends a challenge to the supplicant. + 7. The supplicant carries out a hash on the password and sends + this hashed password to the RADIUS server as its response. + 8. The RADIUS server performs a hash on the password for that supplicant + in its user database and compares the two hashed values and + authenticates the client if the two values match(EAP-Success/EAP-Failure) + 9. AP now opens a port to accept data from the end-user. + + Currently, EAP is widely used in wireless networks than in wired networks. + In 802.11/wireless based networking, following sequence of events happen in + addition to the above EAP events. + + 10. RADIUS server and the supplicant agree to a specific WEP key. + 11. The supplicant loads the key ready for logging on. + 12. The RADIUS server sends the key for this session (Session key) to the AP. + 13. The AP encrypts its Broadcast key with the Session key + 14. The AP sends the encypted key to the supplicant + 15. The supplicant decrypts the Broadcast key with the Session key and + the session continues using the Broadcast and Session keys until + the session ends. + + References: + The Implementation of EAP over RADIUS is based on the following RFCs + rfc2869 -- RADIUS Extensions + rfc2284 -- PPP Extensible Authentication Protocol (EAP) + rfc2716 -- PPP EAP TLS Authentication Protocol + + Following links help to understand HOW EAP works + www.ieee802.org/1/mirror/8021/docs2000/ieee_plenary.PDF + + +EAP CODE ORGANIZATION + + EAP is implemented as a module in freeradius + and the code is placed in src/modules/rlm_eap. + All EAP-Types are organized as subdirectories in rlm_eap/types/. + + Each EAP-Type, like types/rlm_eap_md5, contains a chunk of code that + knows how to deal with a particular kind of authentication mechanism. + + To add a new EAP-Type then a new directory should be created as + rlm_eap/types/rlm_eap_XXXX, where XXXX is EAP-Type name + ie for EAP-Type like ONE TIME PASSWORD (OTP) it would be rlm_eap_otp + + src/modules/rlm_eap -- contains the basic EAP and generalized interfaces + to all the EAP-Types. + rlm_eap/types -- contains all the supported EAP-Types + rlm_eap/types/rlm_eap_md5 -- EAP-MD5 authentication. + rlm_eap/types/rlm_eap_tls -- EAP-TLS based authentication. + rlm_eap/types/rlm_eap_ttls -- TTLS based authentication. + rlm_eap/types/rlm_eap_peap -- Windows PEAP based authentication. + rlm_eap/types/rlm_eap_sim -- EAP-SIM (GSM) based authentication + +CONFIGURATION + + Add the eap configuration stanza to the modules section in radiusd.conf + to load and control rlm_eap and all the supported EAP-Types: + + For example: + modules { + ... + eap { + default_eap_type = md5 + + md5 { + } + ... + } + ... + } + + NOTE: You cannot have empty eap stanza. At least one EAP-Type sub-stanza + should be defined as above, otherwise the server will not know what type + of eap authentication mechanism to be used and the server will exit + with error. + + All the various options and their associated default values for each + EAP-Type are documented in the sample radiusd.conf that is provided + with the distribution. + + Since the EAP requests may not contain a requested EAP type, the + 'default_eap_type' configuration options is used by the EAP module + to determine which EAP type to choose for authentication. + + NOTE: EAP cannot authorize a user. It can only authenticate. + Other Freeradius modules authorize the user. + + +EAP SIM server + + To configure EAP-SIM authentication, the following attributes must be + set in the server. This can be done in the users file, but in many cases + will be taken from a database server, via one of the SQL interface. + + If one has SIM cards that one controls (i.e. whose share secret you know), + one should be able to write a module to generate these attributes + (the triplets) in the server. + + If one has access to the SS7 based settlement network, then a module to + fetch appropriate triplets could be written. This module would act as + an authorization only module. + + The attributes are: + EAP-Sim-Rand1 16 bytes + EAP-Sim-SRES1 4 bytes + EAP-Sim-KC1 8 bytes + EAP-Sim-Rand2 16 bytes + EAP-Sim-SRES2 4 bytes + EAP-Sim-KC2 8 bytes + EAP-Sim-Rand3 16 bytes + EAP-Sim-SRES3 4 bytes + EAP-Sim-KC3 8 bytes + + EAP-SIM will send WEP attributes to the resquestor. + +EAP CLIENTS + + 1. eapol_test, from wpa_supplicant. + + 2. Freeradius has an "radeapclient" that can do EAP-MD5 (passwords), + as well as EAP-SIM. It is in modules/rlm_eap/radeapclient. + +TESTING + + You will find several test cases in src/tests/ for the EAP-SIM code. + + +HOW DO I USE IT (FAQ/Examples) + + 1. How can I enable EAP-MD5 authentication ? + + In radiusd.conf + + modules { + ... + eap { + default_eap_type = md5 + md5 { + } + ... + } + ... + } + + # eap sets the authenticate type as EAP + authorize { + ... + eap + } + + # eap authentication takes place. + authenticate { + eap + } + + # If you are proxying EAP-LEAP requests + # This is required to make LEAP work. + post-proxy { + eap + } + + 2. My Userbase is in LDAP and I want to use EAP-MD5 authentication + + In radiusd.conf + + modules { + ... + eap { + default_eap_type = md5 + md5 { + } + ... + } + ... + } + + # ldap gets the Configured password. + # eap sets the authenticate type as EAP + authorize { + ... + ldap + eap + ... + } + + # eap authentication takes place. + authenticate { + ... + eap + ... + } + + 3. How can I Proxy EAP messages, with/without User-Name attribute + in the Access-Request packets + + With User-Name attribute in Access-Request packet, + EAP-proxying is just same as RADIUS-proxying. + + If User-Name attribute is not present in Access-Request packet, + Freeradius can proxy the request with the following configuration + in radiusd.conf + + # eap module should be configured as the First module in + # the authorize stanza + + authorize { + eap + ... other modules. + } + + With this configuration, eap_authorize creates User-Name attribute + from EAP-Identity response, if it is not present. + Once User-Name attribute is created, RADIUS proxying takes care + of EAP proxying. + + 4. How Freeradius can handle EAP-START messages ? + + In most of the cases this is handled by the Authenticator. + + Only if it is required then, in radiusd.conf + + authorize { + eap + ... other modules. + } + + With the above configuration, RADIUS server immediately responds with + EAP-Identity request. + + NOTE: EAP does not check for any Identity or maintains any state in case + of EAP-START. It blindly responds with EAP-Identity request. + Proxying is handled only after EAP-Identity response is received. + + 5. I want to enable multiple EAP-Types, how can I configure ? + + In radiusd.conf + + modules { + ... + eap { + default_eap_type = tls + md5 { + } + tls { + ... + } + ... + } + ... + } + + The above configuration will let the server load all the EAP-Types, + but the server can have only one default EAP-Type, as above. + + Once EAP-Identity response is received by the server, based on the + default_eap_type, the server will send a new request (MD5-Challenge + request incase of md5, TLS-START request incase of tls) to the supplicant. + If the supplicant is rfc2284 compliant and does not support the + EAP-Type sent by the server then it sends EAP-Acknowledge with the + supported EAP-Type. If this EAP-Type is supported by the server then it + will send the respective EAP-request. + + Example: If the supplicant supports only EAP-MD5 but the server + default_eap_type is configured as EAP-TLS, as above, then the server + will send TLS-START after EAP-Identity is received. Supplicant will + respond with EAP-Acknowledge(EAP-MD5). Server now responds with + MD5-Challenge. + + +INSTALLATION + EAP, EAP-MD5, and Cisco LEAP do not require any additional packages. + Freeradius contains all the required packages. + + For EAP-TLS, EAP-TTLS, and PEAP, OPENSSL, <http://www.openssl.org/>, + is required to be installed. + Any version from 0.9.7, should fairly work with this module. + + EAP-SIM should not require any additional packages. + + +IMPLEMENTATION (For Developers) + + The rlm_eap module only deals with EAP specific authentication mechanism + and the generic interface to interact with all the EAP-Types. + + Currently, these are the existing interfaces, + int attach(CONF_SECTION *conf, void **type_arg); + int initiate(void *type_arg, EAP_HANDLER *handler); + int authenticate(void *type_arg, EAP_HANDLER *handler); + int detach(void **type_arg); + + attach() and detach() functions allocate and deallocate all the + required resources. + + initiate() function begins the conversation when EAP-Identity response + is received. Incase of EAP-MD5, initiate() function sends the challenge. + + authenticate() function uses specific EAP-Type authentication mechanism + to authenticate the user. During authentication many EAP-Requests and + EAP-Responses takes place for each authentication. Hence authenticate() + function may be called many times. EAP_HANDLER contains the complete + state information required. + + +HOW EAP WORKS + as posted to the list, by John Lindsay <jlindsay@internode.com.au> + + To make it clear for everyone, the supplicant is the software on the + client (machine with the wireless card). + + The EAP process doesn't start until the client has associated with + the Access Point using Open authentication. If this process isn't + crystal clear you need to go away and gain understanding. + + Once the association is made the AP blocks all traffic that is not + 802.1x so although associated the connection only has value for EAP. + Any EAP traffic is passed to the radius server and any radius traffic + is passed back to the client. + + So, after the client has associated to the Access Point, the + supplicant starts the process for using EAP over LAN by asking the + user for their logon and password. + + Using 802.1x and EAP the supplicant sends the username and a one-way + hash of the password to the AP. + + The AP encapsulates the request and sends it to the RADIUS server. + + The radius server needs a plaintext password so that it can perform + the same one-way hash to determine that the password is correct. If + it is, the radius server issues an access challenge which goes back + via to the AP to the client. (my study guide says client but my + brain says 'supplicant') + + The client sends the EAP response to the challenge via the AP to the + RADIUS server. + + If the response is valid the RADIUS server sends a success message + and the session WEP key (EAP over wireless) to the client via the + AP. The same session WEP key is also sent to the AP in the success + packet. + + The client and the AP then begin using session WEP keys. The WEP key + used for multicasts is then sent from the AP to the client. It is + encrypted using the session WEP key. + +ACKNOWLEDGEMENTS + Primary author - Raghu <raghud@mail.com> + + EAP-SIM - Michael Richardson <mcr@sandelman.ottawa.on.ca> + The development of the EAP/SIM support was funded by + Internet Foundation Austria (http://www.nic.at/ipa). + + diff --git a/doc/modules/rlm_expiration b/doc/modules/rlm_expiration new file mode 100644 index 0000000..eb7918b --- /dev/null +++ b/doc/modules/rlm_expiration @@ -0,0 +1,23 @@ +Module to expire user accounts. + +This module can be used to expire user accounts. Expired users receive +an Access-Reject on every authentication attempt. Expiration is based +on the Expiration attribute which should be present in the check item +list for the user we wish to perform expiration checks. + + + +Expiration attribute format: + +You can use Expiration := "23 Sep 2004" and the user will +no longer be able to connect at 00:00 (midnight) on September 23rd, +2004. If you want a certain time (other than midnight) you can do +use Expiration := "23 Sep 2004 12:00". +The nas will receive a Session-Timeout attribute calculated to kick +the user off when the Expiration time occurs. + + + +Example entry (users files): + +user1 Expiration := "23 Sep 2004" diff --git a/doc/modules/rlm_krb5 b/doc/modules/rlm_krb5 new file mode 100644 index 0000000..d70017f --- /dev/null +++ b/doc/modules/rlm_krb5 @@ -0,0 +1,47 @@ +The `rlm_krb5` FreeRADIUS module enables the use of Kerberos 5 for +authentication. + +Compilation issues +================== + +MIT libraries +------------- + +The `rlm_krb5` module, by default, presumes you have the MIT Kerberos 5 +distribution. Notes from that distribution: + +On linux, you may have to change: + + deplibs_test_method="pass_all" + +in `../libtool` + +Otherwise, it complains if the krb5 libs aren't shared. + +Heimdal libraries +----------------- + +If you are using the Heimdal Kerberos 5 distribution, pass an +`--enable-heimdal-krb5` option to `configure`. + +Configuration parameters +======================== + +You can configure the module with the following parameters: + + krb5 { + # Keytab containing the key used by rlm_krb5 + keytab = /path/to/keytab + + # Principal that is used by rlm_krb5 + service_principal = radius/some.host.com + } + +Make sure the keytab is readable by the user that is used to run `radiusd` and +that your authorization configuration really uses `rlm_krb5` to do the +authentication. You will need to add the following to the 'authenticate' +section of your radiusd.conf file: + + Auth-Type Kerberos { + krb5 + } diff --git a/doc/modules/rlm_pam b/doc/modules/rlm_pam new file mode 100644 index 0000000..8a6673c --- /dev/null +++ b/doc/modules/rlm_pam @@ -0,0 +1,108 @@ + + PAM Support for FreeRadius + + +0. INTRODUCTION + + PAM support was done by Jeph Blaize. Miguel a.l. Paraz <map@iphil.net> + ported it to FreeRADIUS' parent, Cistron-Radius. Chris Dent <cdent@kiva.net> + added the Pam-Auth attribute. + +1. USAGE + + Use Auth-Type = Pam in the users file. You cannot use User-Password = "PAM" + as in other radius servers. Sorry. + + You can also use ``Pam-Auth = "somestring"'' to specify an entry in + /etc/pam.d. The default is "radius". + + Compile and install freeradius with pam support (./configure --help + will tell you how) + + Within your radiusd.conf file, in the 'modules' section, make sure + that the pam section is enabled: + + pam { + # + # The name to use for PAM authentication. + # PAM looks in /etc/pam.d/${pam_auth_name} + # for it's configuration. + # + # Note that any Pam-Auth attribute set in the 'users' + # file over-rides this one. + # + pam_auth = radiusd + } + + In the 'authenticate' section, do the same: + + authenticate { + # Uncomment this if you want to use PAM (Auth-Type = PAM) + pam + ... + + + In your /etc/pam.d/ directory create a file called radiusd with the + following contents (or whatever you want for your pam configuration, + this seems to work for me): + +#%PAM-1.0 +auth required /lib/security/pam_unix_auth.so shadow md5 nullok +auth required /lib/security/pam_nologin.so +account required /lib/security/pam_unix_acct.so +password required /lib/security/pam_cracklib.so +password required /lib/security/pam_unix_passwd.so shadow md5 nullok use_authtok +session required /lib/security/pam_unix_session.so + + + If you don't want to run your freeradius server in debug mode as + root (ie, run as an unpriviledged user) you will need to run + freeradius with a group membership that is able to read the + /etc/shadow file - otherwise pam will be unable to read the + /etc/shadow file and will fail. I suggest a group called 'shadow' or + the like. + + $ chgrp /etc/shadow shadow + $ chmod g+w /etc/shadow + + And in the radiusd.conf file: + + # On systems with shadow passwords, you might have to set 'group = shadow' + # for the server to be able to read the shadow password file. + # + # Change below to suit your setup. + user = radius + group = shadow + + + Please understand that giving anything except root read permissions + to the /etc/shadow file is something that you want to think a bit + upon!! + +2. NOTES + + None. + +3. TODO: + + Real PAM support, figure out how we can write a module that will make + it blend in with PAM more seamlessly. With this, we can replace the + DENY_SHELL with something more flexible such as a database. + +4. EXAMPLE: + +DEFAULT Auth-Type = Pam, NAS-IP-Address = 206.97.64.5 + Service-Type = Framed-User, + Framed-Protocol = PPP, + Framed-IP-Address = 255.255.255.254, + Filter-Id = "std.ppp", + Framed-MTU = 1500, + Framed-Compression = Van-Jacobson-TCP-IP +DEFAULT Auth-Type = Pam, Pam-Auth = "radius2", NAS-IP-Address = 127.0.0.1 + Service-Type = Framed-User, + Framed-Protocol = PPP, + Framed-IP-Address = 255.255.255.254, + Filter-Id = "std.ppp", + Framed-MTU = 1500, + Framed-Compression = Van-Jacobson-TCP-IP + diff --git a/doc/modules/rlm_passwd b/doc/modules/rlm_passwd new file mode 100644 index 0000000..59f4a59 --- /dev/null +++ b/doc/modules/rlm_passwd @@ -0,0 +1,50 @@ +RADIUS rlm_passwd (passwd-like files authorization module) + +FAQ + +Q: Can I use rlm_passwd to authenticate user against Linux shadow password + file or BSD-style master.passwd? +A: Yes, but you need RADIUS running as root. Hint: use Crypt-Password + attribute. You probably don't want to use this module with + FreeBSD to authenticate against system file, as it already takes care + of caching passwd file entries, but it may be helpfull to authenticate + against alternate file. + +Q: Can I use rlm_passwd to authenticate user against SAMBA smbpasswd? +A: Yes, you can. Hint: use LM-Password/NT-Password attribute, set + authtype = MS-CHAP. + +Q: Can I use rlm_password to authenticate user against BLA-BLA-BLApasswd? +A: Probably you can, if BLA-BLA-BLA stores password in some format supported + by RADIUS, for example cleartext, NT/LM hashes, crypt, Netscape MD5 format. + You have to set authtype to corresponding type, for example + authtype = NS-MTA-MD5 + for Netscape MD5. + +Q: Are where are differences between rlm_passwd and rlm_unix? +A: rlm_passwd supports passwd files in any format and may be used, for + example, to parse FreeBSD's master.passwd or SAMBA smbpasswd files, but + it can't perform system authentication (for example to authenticate + NIS user, like rlm_unix does). If you need system authentication you + need rlm_unix, if you have to authenticate against files only under + BSD you need rlm_passwd, if you need to authenticate against files only + under Linux, you can choose between rlm_unix and rlm_passwd, probably + you will have nearly same results in performance (I hope :) ). + +Q: I'm using realms with rlm_passwd. I see rlm_passwd do not strip realm + from user name. How to configure rlm_passwd to strip realm? + +A: In case you configured realm to strip username, User-Password attribute + is not changed. Instead, rlm_realm creates new attribute Stripped-User-Name. + All you need is to use Stripped-User-Name instead of User-Name as a key + field for passwd file. + +Q: How can I say passwd to add attribute even if it's value is empty? + +A: set ignore_empty to "no" in module configuration. + + +5. Acknowlegements: + + ZARAZA, <3APA3A@security.nnov.ru> + Michael Chernyakhovsky <mike@mgn.ru> - reply-items support diff --git a/doc/modules/rlm_python b/doc/modules/rlm_python new file mode 100644 index 0000000..ef35f1b --- /dev/null +++ b/doc/modules/rlm_python @@ -0,0 +1,76 @@ +Python module for freeradius +Copyright 2002 Miguel A Paraz <mparaz@mparaz.com> +Copyright 2002 Imperium Technology, Inc. + +PURPOSE: +To allow module writers to write modules in a high-level language, +for implementation or for prototyping. + +REQUIRES: +Python - tested with 2.2 + +BUILDING: +./configure --with-experimental-modules + + +USAGE: +Make your module available to the Python interpreter by either putting it +in a standard location, or 'EXPORT PYTHONPATH=$location'. + + + + + +BUGS: +1. Can't compile statically (./configure --enable-shared=no) - causes +SIGSEGV on the first malloc() in main(). + +Design: +1. Support for all module functions. +2. One module per function allowed, for example, from experimental.conf: + + python { + mod_instantiate = radiusd_test + func_instantiate = instantiate + + mod_authorize = radiusd_test + func_authorize = authorize + + mod_accounting = radiusd_test + func_accounting = accounting + + mod_preacct = radiusd_test + func_preacct = preacct + + mod_detach = radiusd_test + func_detach = detach + + } + + +3. Different functions are wrappers around the same core. +4. func_detach is passed no parameters, returns module return value. +5. If functions returns None (plain 'return' no return), default to RLM_OK +6. Python instantation function can return -1 to signal failure and abort + startup. + +Available to module: +import radiusd +radiusd.rad_log(radiusd.L_XXX, message_string) +radiusd.RLM_XXX + + + +TODO: +1. Do we need to support other pair operations beyond set (:=) ? +2. Should we pass the value pair info as a dict and not a tuple? Faster? +2. Give access to more radiusd variables like the dictionary. +3. Give access to other C functions. + Let the Python module deal with the structures directly, instead of + letting our C code do it afterwards. + What's a good way to represent this? + + + + + diff --git a/doc/modules/rlm_soh b/doc/modules/rlm_soh new file mode 100644 index 0000000..eda5c4c --- /dev/null +++ b/doc/modules/rlm_soh @@ -0,0 +1,183 @@ +== Intro == + +This release adds support for Microsoft Statement-of-Health (SoH), which is +a form of network access protection. + +Client support is present in Windows XP SP3, Vista and 7. + +SoH data can come in from several places: + + * inside EAP-PEAP packets for 802.1x wireless/wired connections + * inside a radius packet (Microsoft VSA #55, MS-Quarantine-SOH) - VPN and + terminal services gateways can act as the radius client + * inside a DHCP request, in vendor-specific options + +FreeRadius supports all three types. The SoH statement is decoded into +radius-style attributes, and you can write a policy in "unlang" to act +on them, and permit, restrict or deny network access. + +== PEAP support == + +SoH support in peap is enabled in eap.conf using config like so: + + eap { + peap { + soh = yes + soh_virtual_server = "soh-server" + } + } + +When SoH is enabled, an EAP-PEAP client will be challenged to provide an +SoH statement after providing it's identity (or resuming a PEAP session via +SSL session resumption). Clients which do not support PEAP will NAK the +request, and clients which do will answer it. + +The client reply will be written into a fake radius request and sent to the +virtual server specified above; it will either look like: + + SoH-Supported = no + +...or (from a Vista machine): + + SoH-Supported = yes + SoH-MS-Machine-OS-vendor = Microsoft + SoH-MS-Machine-OS-version = 6 + SoH-MS-Machine-OS-release = 0 + SoH-MS-Machine-OS-build = 6001 + SoH-MS-Machine-SP-version = 1 + SoH-MS-Machine-SP-release = 0 + SoH-MS-Machine-Processor = x86_64 + SoH-MS-Machine-Name = "netbios.example.com" + SoH-MS-Correlation-Id = 0x54468936cb494374b127a6a3cc3bb11c01ca78d858ee1ef0 + SoH-MS-Machine-Role = client + SoH-MS-Windows-Health-Status = "firewall ok snoozed=0 microsoft=1 up2date=1 enabled=1" + SoH-MS-Windows-Health-Status = "antivirus error not-installed" + SoH-MS-Windows-Health-Status = "antispyware ok snoozed=0 microsoft=1 up2date=1 enabled=1" + SoH-MS-Windows-Health-Status = "auto-updates ok action=install" + SoH-MS-Windows-Health-Status = "security-updates warn some-missing" + +If you have "copy_request_to_tunnel = yes" set on the peap module, the +request variables like NAS-IP-Address and so on will be copied to the fake +request as well. + +Clients without SoH seem to just NAK the SoH request and continue with the inner +EAP auth. This has been tested as working with Windows XP SP2 and lower, Linux +clients using NetworkManager & wpa_supplicant, MacOS 10.5, Nokia/Symbian S60 and +iPhone OS 3.x. It should therefore be safe to deploy. + +== Radius support == + +If you are running a Microsoft VPN or Terminal Services Gateway, these can +be configured to send the SoH data to an upstream radius server, in this +case presumably FreeRadius. To take advantage of this you will need to add +the "soh" module to the "authorize" section of your virtual server, like so: + +server tsgateway { + preprocess + soh + if () { + ... policy goes here + } +} + +The SoH module simply looks for the Microsoft VSA #55 and decodes the SoH +data, adding the SoH attributes to the request - see above for an example +of the available attributes. + +The SoH module also does dynamic expansions - see below for more info. + +== DHCP support == + +If you compile FreeRadius with DHCP support, the "soh" module can challenge +a DHCP client for SoH data in the DHCPOFFER packet. As with normal radius, +the SoH attributes are added to the request. You would use like so: + +server dhcp { + dhcp DHCP-Discover { + soh + # note - no SoH attributes are added here, the client hasn't sent them yet + + # other DHCP config + } + + dhcp DHCP-Request { + soh + if () { + # SoH policy + } + # other DHCP config + } +} + +== soh module == + +The "soh" module decodes the radius & DHCP payloads. It also makes some dynamic +variables available, for example: + +authorize { + soh + update request { + Tmp-String-0 = "%{soh:OS}" + } +} + +...will give you a string like "Windows Vista 6.1.100 sp 1.0" or "Windows XP 5.x.x sp 3.0" + +At the moment, this is the only dynamic expansion; in future, we will make +various bits of info available, for example non-Microsoft SoH records (see below) + +== Non-microsoft SoH data == + +The Windows SoH structure is extensible and, in principle, clients can be +extended with .dll plugins to add vendor-specific info to the SoH, which +can then be checked on the server. + +At the present time, few plugins are known and I have seen none, so can't +add support for them. + +== Client configuration == + +The code works fine with Win XP SP3 & Vista on both wired & wireless. However +contrary to what some sites claim, the NAP service is disabled by default, as +are the many NAP remediation agents. These can be enabled from the command prompt +with (for XP; instructions may differ for other windows versions): + + sc config napagent start= auto + sc start napagent + + # optionally for wired 802.1x; the dot3svc should usually be made dependent + # on the napagent service, else the machine might attempt 802.1x before NAP + # has started... + + sc config dot3svc start= auto depend= napagent + sc start dot3svc + + # enable the EAP agent + netsh nap client show config + + # get the "ID" value for the "EAP Quarantine Enforcement Client" + netsh nap client set enforce id=$ID admin=enable + + # repeat for DHCP, VPN or Terminal Services agents + +This can be automated via Group Policy. + +You then need to enable EAP, PEAP, Quarantine Checks & the relevant auth method +on the relevant adapters. This can be done with "netsh xml profiles" or Group +Policy - google for the relevant terms, or see the MS article: + + http://technet.microsoft.com/en-us/library/bb726965.aspx + +...and related links. + +== TODO == + +Currently the code does not support sending the final SoH reply. This +is because the SoH reply (see section 2.2.9 of MS-SOH version +v20091104) needs various fields formatted in a manner which is not +obvious to me, and I don't currently have access to a windows NAP +server to look at a working example. The clients I have access don't +seem to mind. + + Phil Mayers <p.mayers@imperial.ac.uk> + December 2009 diff --git a/doc/modules/rlm_sql b/doc/modules/rlm_sql new file mode 100644 index 0000000..0f06660 --- /dev/null +++ b/doc/modules/rlm_sql @@ -0,0 +1,283 @@ + SQL Module + +0. Introduction + + The SQL module is composed of two parts: a generic SQL front-end + (rlm_sql), and a series of database-dependent back-end drivers, + (rlm_sql_mysql, rlm_sql_postgresql, etc.) + + In order to build the drivers, you MUST ALSO install the development + versions of the database. That is, you must have the appropriate + header files and client libraries for (say) MySQL. The + rlm_sql_mysql driver is NOT a complete MySQL client implementation. + Instead, it is a small 'shim' between the FreeRADIUS rlm_sql module, + and the MySQL client libraries. + + + In general, the SQL schemas mirror the layout of the 'users' file. + So for configuring check items and reply items, see 'man 5 users', + and the examples in the 'users' file. + + +1. Schema and usage + + The schemas are available in raddb/sql/<DB>/*, where <DB> is the + name of the database (mysql, postgresql, etc.) + + The SQL module employs two sets of check and reply item tables for + processing in the authorization stage. One set of tables (radcheck and + radreply) are specific to a single user. The other set of tables + (radgroupcheck and radgroupreply) is used to apply check and reply items + to users that are members of a certain SQL group. The usergroup table + provides the list of groups each user is a member of along with a priority + field to control the order in which groups are processed. + + When a request comes into the server and is processed by the SQL module, + the flow goes something like this: + + 1. Search the radcheck table for any check attributes specific to the user + 2. If check attributes are found, and there's a match, pull the reply items + from the radreply table for this user and add them to the reply + 3. Group processing then begins if any of the following conditions are met: + a. The user IS NOT found in radcheck + b. The user IS found in radcheck, but the check items don't match + c. The user IS found in radcheck, the check items DO match AND + Fall-Through is set in the radreply table + d. The user IS found in radcheck, the check items DO match AND + the read_groups directive is set to 'yes' + 4. If groups are to be processed for this user, the first thing that is + done is the list of groups this user is a member of is pulled from the + usergroup table ordered by the priority field. The priority field of + the usergroup table allows us to control the order in which groups are + processed, so that we can emulate the ordering in the users file. This + can be important in many cases. + 5. For each group this user is a member of, the corresponding check items + are pulled from radgroupcheck table and compared with the request. If + there is a match, the reply items for this group are pulled from the + radgroupreply table and applied. + 6. Processing continues to the next group IF: + a. There was not a match for the last group's check items OR + b. Fall-Through was set in the last group's reply items + (The above is exactly the same as in the users file) + 7. Finally, if the user has a User-Profile attribute set or the Default + Profile option is set in the sql.conf, then steps 4-6 are repeated for + the groups that the profile is a member of. + + For any fairly complex setup, it is likely that most of the actual + processing will be done in the groups. In these cases, the user entry in + radcheck will be of limited use except for things like setting the user's + password. So, one might have the following setup: + + radcheck table: + joeuser Cleartext-Password := somepassword + + radreply table: + joeuser Fall-Through = Yes + + radgroupcheck table: + Check items for various connection scenarios + + radgroupreply table: + reply items for the groups + + usergroup table: + joeuser WLANgroup 1(this is the priority) + joeuser PPPgroup 2 + + +2. What NOT to do. + + One of the fields of the SQL schema is named 'op' This is for the + 'operator' used by the attributes. e.g.: + + Framed-IP-Address = 1.2.3.4 + ^ ATTRIBUTE ----^ ^ OP ^ VALUE + + If you want the server to be completely misconfigured, and to never + do what you want, leave the 'op' field blank. If you want to be + rudely told to RTFM, then post questions on the mailing list, asking + + "why doesn't my SQL configuration work when I leave the 'op' field empty?" + + + The short answer is that with the op field empty, the server does + not know what you want it to do with the attribute. Should it be + added to the reply? Maybe you wanted to compare the operator to one + in the request? The server simply doesn't know. + + So put a value in the field. The value is the string form of the + operator: "=", ">=", etc. See Section 4, below, for more details. + + +3. Authentication versus Authorization + + Many people ask if they can "authenticate" users to their SQL + database. The answer to this question is "You're asking the wrong + question." + + An SQL database stores information. An SQL database is NOT an + authentication server. The ONLY users who should be able to + authenticate themselves to the database are the people who + administer it. Most administrators do NOT want every user to be + able to access the database, which means that most users will not be + able to "authenticate" themselves to the database. + + Instead, the users will have their authorization information (name, + password, configuration) stored in the database. The configuration + files for FreeRADIUS contain a username and password used to + authenticate FreeRADIUS to the SQL server. (See raddb/sql.conf). + Once the FreeRADIUS authentication server is connected to the SQL + database server, then FreeRADIUS can pull user names and passwords + out of the database, and use that information to perform the + authentication. + +4. Operators + + The list of operators is given below. + + Op Example and documentation + -- ------------------------- + + = "Attribute = Value" + + Not allowed as a check item for RADIUS protocol attributes. It is + allowed for server configuration attributes (Auth-Type, etc), and sets + the value of on attribute, only if there is no other item of the + same attribute. + + As a reply item, it means "add the item to the reply list, but + only if there is no other item of the same attribute." + + + := "Attribute := Value" + + Always matches as a check item, and replaces in the + configuration items any attribute of the same name. If no + attribute of that name appears in the request, then this + attribute is added. + + As a reply item, it has an identical meaning, but for the + reply items, instead of the request items. + + == "Attribute == Value" + + As a check item, it matches if the named attribute is present + in the request, AND has the given value. + + Not allowed as a reply item. + + + += "Attribute += Value" + + Always matches as a check item, and adds the current attribute + with value to the list of configuration items. + + As a reply item, it has an identical meaning, but the + attribute is added to the reply items. + + + != "Attribute != Value" + + As a check item, matches if the given attribute is in the + request, AND does not have the given value. + + Not allowed as a reply item. + + + > "Attribute > Value" + + As a check item, it matches if the request contains an + attribute with a value greater than the one given. + + Not allowed as a reply item. + + + >= "Attribute >= Value" + + As a check item, it matches if the request contains an + attribute with a value greater than, or equal to the one + given. + + Not allowed as a reply item. + + < "Attribute < Value" + + As a check item, it matches if the request contains an + attribute with a value less than the one given. + + Not allowed as a reply item. + + + <= "Attribute <= Value" + + As a check item, it matches if the request contains an + attribute with a value less than, or equal to the one given. + + Not allowed as a reply item. + + + =~ "Attribute =~ Expression" + + As a check item, it matches if the request contains an + attribute which matches the given regular expression. This + operator may only be applied to string attributes. + + Not allowed as a reply item. + + + !~ "Attribute !~ Expression" + + As a check item, it matches if the request contains an + attribute which does not match the given regular expression. + This operator may only be applied to string attributes. + + Not allowed as a reply item. + + + =* "Attribute =* Value" + + As a check item, it matches if the request contains the named + attribute, no matter what the value is. + + Not allowed as a reply item. + + + !* "Attribute !* Value" + + As a check item, it matches if the request does not contain + the named attribute, no matter what the value is. + + Not allowed as a reply item. + +5. Instances + + Just like any other module, multiple instances of the rlm_sql + module can be defined and used wherever you like. + + The default .conf files for the different database types, + contain 1 instance without a name like so: + sql { + ... + } + + You can create multiple named instances like so: + sql sql_instance1 { + ... + } + sql sql_instance2 { + ... + } + + And then you can use a specific instance in radiusd.conf, like + so: + authorize { + ... + sql_instance1 + ... + } + accounting { + ... + sql_instance1 + sql_instance2 + ... + } diff --git a/doc/modules/rlm_sqlcounter b/doc/modules/rlm_sqlcounter new file mode 100644 index 0000000..54ad170 --- /dev/null +++ b/doc/modules/rlm_sqlcounter @@ -0,0 +1,182 @@ +rlm_sqlcounter installation and running guide +by Ram Narula ram@princess1.net +Internet for Education (Thailand) + +*) Pre-requisites: +Make sure to have configured radiusd with rlm_sqlcounter +installed + +> make clean +> ./configure --with-experimental-modules +> make +> make install + +Make sure to have radiusd running properly under sql +and there must be a "sql" entry under accounting{ } section +of radiusd.conf + +*) Configuration: + +[1] Create a text file called sqlcounter.conf in the same +directory where radiusd.conf resides (usually /usr/local/etc/raddb) +with the following content (for mysql): + +#-----# +sqlcounter noresetcounter { + sql_module_instance = sqlcca3 + counter_name = Max-All-Session-Time + check_name = Max-All-Session + reply_name = Session-Timeout + key = User-Name + reset = never + + query = "SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='%{%k}'" + + } + + +sqlcounter dailycounter { + sql_module_instance = sqlcca3 + driver = "rlm_sqlcounter" + counter_name = Daily-Session-Time + check_name = Max-Daily-Session + reply_name = Session-Timeout + key = User-Name + reset = daily + + query = "SELECT SUM(AcctSessionTime - GREATEST((%b - UNIX_TIMESTAMP(AcctStartTime)), 0)) FROM radacct WHERE UserName='%{%k}' AND UNIX_TIMESTAMP(AcctStartTime) + AcctSessionTime > '%b'" + + } + +sqlcounter monthlycounter { + sql_module_instance = sqlcca3 + counter_name = Monthly-Session-Time + check_name = Max-Monthly-Session + reply_name = Session-Timeout + key = User-Name + reset = monthly + + query = "SELECT SUM(AcctSessionTime - GREATEST((%b - UNIX_TIMESTAMP(AcctStartTime)), 0)) FROM radacct WHERE UserName='%{%k}' AND UNIX_TIMESTAMP(AcctStartTime) + AcctSessionTime > '%b'" + + } + +#-----# + +The respective lines for postgresql are: + +query = "SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='%{%k}'" +query = "SELECT SUM(AcctSessionTime - GREATEST((%b - EXTRACT(epoch FROM AcctStartTime)), 0)) FROM radacct WHERE UserName='%{%k}' AND EXTRACT(epoch FROM AcctStartTime) + AcctSessionTime > '%b'" +query = "SELECT SUM(AcctSessionTime - GREATEST((%b - EXTRACT(epoch FROM AcctStartTime)), 0)) FROM radacct WHERE UserName='%{%k}' AND EXTRACT(epoch FROM AcctStartTime) + AcctSessionTime > '%b'" + +If you are running postgres 7.x, you may not have a GREATEST function. + +An example of one is: + +CREATE OR REPLACE FUNCTION "greater"(integer, integer) RETURNS integer AS ' +DECLARE + res INTEGER; + one INTEGER := 0; + two INTEGER := 0; +BEGIN + one = $1; + two = $2; + IF one IS NULL THEN + one = 0; + END IF; + IF two IS NULL THEN + two = 0; + END IF; + IF one > two THEN + res := one; + ELSE + res := two; + END IF; + RETURN res; +END; +' LANGUAGE 'plpgsql'; + +[2] Include the above file to radiusd.conf by adding a line in +modules{ } section + +modules { + +$INCLUDE ${confdir}/sqlcounter.conf + +...some other entries here... + +[3] Make sure to have the sqlcounter names under authorize section +like the followings: + +authorize { +...some entries here... +...some entries here... +...some entries here... +...some entries here... + +noresetcounter +dailycounter +monthlycounter +} + +noresetcounter: the counter that never resets, can be used +for real session-time cumulation + +dailycounter: the counter that resets everyday, can be used +for limiting daily access time (eg. 3 hours a day) + +monthlycounter: the counter that resets monthly, can be used for +limiting monthly access time (eg. 50 hours per month) + +You can make your own names and directives for resetting the counter +by reading the sample sqlcounter configuration in +raddb/experimental.conf + + + +*) Implementation: + +Add sqlcounter names to be used into radcheck or radgroupcheck +table appropriately for sql. For users file just follow the +example below. + +Note: The users in the example below must be able to login +normally as the example will only show how to apply sqlcounter +counters. + +Scenarios +[1] username test0001 have total time limit of 15 hours +(user can login as many times as needed but can be online for +total time of 15 hours which is 54000 seconds) +If using normal users file authentication the entry can look like: + +test0001 Max-All-Session := 54000, User-Password == "blah" + Service-Type = Framed-User, + Framed-Protocol = PPP + +or for sql make sure to have Max-All-Session entry under either +radcheck or radgroup check table: +> INSERT into radcheck VALUES ('','test0001','Max-All-Session','54000',':='); + +[2] username test0002 have total time limit of 3 hours a day + +test0002 Max-Daily-Session := 10800, User-Password == "blah" + Service-Type = Framed-User, + Framed-Protocol = PPP +or in sql: +> INSERT into radcheck VALUES ('','test0002','Max-Daily-Session','10800',':='); + + +[3] username test0003 have total time limit of 90 hours a month + +test0003 Max-Monthly-Session := 324000, User-Password == "blah" + Service-Type = Framed-User, + Framed-Protocol = PPP +in sql: +> INSERT into radcheck VALUES ('','test0003','Max-Monthly-Session','10800',':='); + + +Note that Max-All-Session, Max-Daily-Session and Max-Monthly-Session are +definied in sqlcounter.conf + +VERY IMPORTANT: +Accounting must be done via sql or this will not work. diff --git a/doc/modules/rlm_sqlippool b/doc/modules/rlm_sqlippool new file mode 100644 index 0000000..3d2840f --- /dev/null +++ b/doc/modules/rlm_sqlippool @@ -0,0 +1,40 @@ +Welcome to the SQL Based IP Pool module. + +********************************************************************** +As of September 2006 this module is still under some development and +currently is only tested by the developers on PostgreSQL (Version 8.1) + Use it at your own risk! +If plan to attempt to use a DB other than PostgreSQL please expect to +have to do extra work which is not for SQL newbies. +Having said that it works great for us in production and should (with +some work) function correctly with other SQL server types. +********************************************************************** + + +To use the sqlipool module you simply need to have an IP-Pool Attribute +(Keep in mind that its a **CHECK** item, not reply) in the required +configuration file, which is either in files(users), sql or any other +type of configuration schema. + +The initialization of the radippool table is left to the user instead of +being handled inside the module. This allows pool management to be done +from any sql capable programming language and pools can be created, +resized, deleted at run time without radiusd needing to be restarted. + +The only required fields are, pool_name and ip_address. A pool consists +of one or more rows in the table with the same pool_name and a different +ip_address. There is no restriction on which ip addresses/ranges may be in +the same pool, and addresses do not need to be concurrent. + +We are currently using the variable definitions of the xlat module, so +before editing the sqlippool.conf file, please go and read the +variables.rst in the doc/configuration directory. It will help you alot!.. + +As you may noticed, there is a pool-key variable in the config file which +allows you to select which attribute is unique according to your NAS setup. +On a standard dialup NAS this is going to be "NAS-Port" but on an ethernet +or wireless network it will probably be "Calling-Station-Id". Other more +exotic options like "3GPP-IMSI" may also exist depending on your NAS. +The only requirement is that the pool-key must be unique and must be +received in both Access-Request and Accounting packages so that we know to +clear the lease on the ip when the session disconnects. |