summaryrefslogtreecommitdiffstats
path: root/doc/modules
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-28 09:49:46 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-28 09:49:46 +0000
commit50b37d4a27d3295a29afca2286f1a5a086142cec (patch)
tree9212f763934ee090ef72d823f559f52ce387f268 /doc/modules
parentInitial commit. (diff)
downloadfreeradius-upstream.tar.xz
freeradius-upstream.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 '')
-rw-r--r--doc/modules/RADIUS-LDAP-eDirectory18
-rw-r--r--doc/modules/ldap_howto.rst1648
-rw-r--r--doc/modules/mschap.rst196
-rw-r--r--doc/modules/rlm_dbm195
-rw-r--r--doc/modules/rlm_eap395
-rw-r--r--doc/modules/rlm_expiration23
-rw-r--r--doc/modules/rlm_krb547
-rw-r--r--doc/modules/rlm_pam108
-rw-r--r--doc/modules/rlm_passwd50
-rw-r--r--doc/modules/rlm_python76
-rw-r--r--doc/modules/rlm_soh183
-rw-r--r--doc/modules/rlm_sql283
-rw-r--r--doc/modules/rlm_sqlcounter182
-rw-r--r--doc/modules/rlm_sqlippool40
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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-29 05:23:08 +0000