diff options
Diffstat (limited to 'man/man5')
| -rw-r--r-- | man/man5/checkrad.5 | 95 | ||||
| -rw-r--r-- | man/man5/clients.conf.5 | 46 | ||||
| -rw-r--r-- | man/man5/dictionary.5 | 185 | ||||
| -rw-r--r-- | man/man5/radiusd.conf.5 | 202 | ||||
| -rw-r--r-- | man/man5/radrelay.conf.5 | 146 | ||||
| -rw-r--r-- | man/man5/rlm_always.5 | 119 | ||||
| -rw-r--r-- | man/man5/rlm_attr_filter.5 | 145 | ||||
| -rw-r--r-- | man/man5/rlm_chap.5 | 30 | ||||
| -rw-r--r-- | man/man5/rlm_counter.5 | 89 | ||||
| -rw-r--r-- | man/man5/rlm_detail.5 | 89 | ||||
| -rw-r--r-- | man/man5/rlm_digest.5 | 79 | ||||
| -rw-r--r-- | man/man5/rlm_expr.5 | 113 | ||||
| -rw-r--r-- | man/man5/rlm_files.5 | 95 | ||||
| -rw-r--r-- | man/man5/rlm_idn.5 | 45 | ||||
| -rw-r--r-- | man/man5/rlm_mschap.5 | 110 | ||||
| -rw-r--r-- | man/man5/rlm_pap.5 | 137 | ||||
| -rw-r--r-- | man/man5/rlm_passwd.5 | 136 | ||||
| -rw-r--r-- | man/man5/rlm_realm.5 | 94 | ||||
| -rw-r--r-- | man/man5/rlm_sql.5 | 152 | ||||
| -rw-r--r-- | man/man5/rlm_unbound.5 | 82 | ||||
| -rw-r--r-- | man/man5/rlm_unix.5 | 66 | ||||
| -rw-r--r-- | man/man5/unlang.5 | 900 | ||||
| -rw-r--r-- | man/man5/users.5 | 228 |
23 files changed, 3383 insertions, 0 deletions
diff --git a/man/man5/checkrad.5 b/man/man5/checkrad.5 new file mode 100644 index 0000000..68a33f4 --- /dev/null +++ b/man/man5/checkrad.5 @@ -0,0 +1,95 @@ +.TH CHECKRAD 5 "13 January 2006" +.SH NAME +checkrad -- See if a user is (still) logged in on a certain port. +.SH SYNOPSIS +.B checkrad +.RB [ -d ] +.I nas-type nas-ip nas-port login session-id +.SH DESCRIPTION +\fBCheckrad\fP is used by the radius server to check if its idea of a user logged in +on a certain port/NAS is correct if a double login is detected. + +Returns: 0 = no duplicate, 1 = duplicate, >1 = error. + +.SH OPTIONS + +.IP -d +Enable printing of debugging information. + +.IP nas-type +Type of port/NAS. Can be one of: + +.RS +.IP \(bu +ascend +.IP \(bu +bay +.IP \(bu +cisco +.IP \(bu +cisco_l2tp +.IP \(bu +computone +.IP \(bu +cvx +.IP \(bu +digitro +.IP \(bu +dot1x +.IP \(bu +livingston +.IP \(bu +max40xx +.IP \(bu +mikrotik +.IP \(bu +mikrotik_snmp +.IP \(bu +multitech +.IP \(bu +netserver +.IP \(bu +other +.IP \(bu +pathras +.IP \(bu +patton +.IP \(bu +portslave +.IP \(bu +pr3000 +.IP \(bu +pr4000 +.IP \(bu +redback +.IP \(bu +tc +.IP \(bu +usrhiper +.IP \(bu +versanet +.P +The "other" type cause \fBcheckrad\fP to skip any check and always returns 1. +.RE + + +.IP nas-ip +IP address of the NAS to check. + +.IP nas-port +The NAS port to check (may be ignored by some nas-type). + +.IP login +The login name to check. + +.IP session-id +Session to check. (actually ignored by all nas-type) + +.SH SEE ALSO +radiusd(8) + +.SH AUTHOR +Written by Miquel van Smoorenburg, miquels@cistron.nl. + +This manual page was written by Marco Nenciarini <mnencia@debian.org> for +the Debian project (but may be used by others). diff --git a/man/man5/clients.conf.5 b/man/man5/clients.conf.5 new file mode 100644 index 0000000..6c6b3ee --- /dev/null +++ b/man/man5/clients.conf.5 @@ -0,0 +1,46 @@ +.TH clients.conf 5 "13 June 2005" "" "FreeRADIUS client configuration" +.SH NAME +clients.conf \- FreeRADIUS client configuration +.SH DESCRIPTION +The +.I clients.conf +file contains definitions of RADIUS clients. +.PP +The information in this file overrides any information provided in +the deprecated +.BR clients +and +.BR naslist +files. +.PP +The file format is the same as that used for +.I radiusd.conf. +See +.BR radiusd.conf (5) +for more details. +.PP +Each RADIUS client entry has the following basic form: +.IP +.nf +client <short-name> { + <attribute> = <value> + } +.fi +.PP +Clients have many configuration parameters. Most are documented in the file +itself as comments. This page documents only the format of the file. Please +read the \fBclients.conf\fP file itself for more information. + +The old-style format from 1.x is still accepted by the server, but +that form is deprecated. +.SH FILES +.I /etc/raddb/clients.conf + +.I /etc/raddb/radiusd.conf +.SH "SEE ALSO" +.BR radiusd (8), +.BR radiusd.conf (5) + +.SH AUTHOR +FreeRADIUS is authored by the FreeRADIUS team. +http://freeradius.org/ diff --git a/man/man5/dictionary.5 b/man/man5/dictionary.5 new file mode 100644 index 0000000..ec63309 --- /dev/null +++ b/man/man5/dictionary.5 @@ -0,0 +1,185 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH dictionary 5 "12 Jun 2015" +.SH NAME +dictionary \- RADIUS dictionary file +.SH DESCRIPTION +The master RADIUS dictionary file resides in +\fI/etc/raddb/dictionary\fP. It references other \fIdictionary\fP +files located in \fI/usr/local/share/freeradius/\fP. Each dictionary +file contains a list of RADIUS attributes and values, which the server +uses to map between descriptive names and on-the-wire data. The names +have no meaning outside of the RADIUS server itself, and are never +exchanged between server and clients. +.PP +That is, editing the dictionaries will have NO EFFECT on anything +other than the server that is reading those files. Adding new +attributes to the dictionaries will have NO EFFECT on RADIUS clients, +and will not make RADIUS clients magically understand those +attributes. The dictionaries are solely for local administrator +convenience, and are specific to each version of FreeRADIUS. +.PP +The dictionaries in \fI/usr/local/share\fP SHOULD NOT be edited unless +you know exactly what you are doing. Changing them will most likely +break your RADIUS deployment. +.PP +If you need to add new attributes, please edit the +\fI/etc/raddb/dictionary\fP file. It's sole purpose is to contain +site-local definitions that are added by the local administrator. + +.SH FORMAT +Every line starting with a hash sign +.RB (' # ') +is treated as comment and ignored. +.PP +Each line of the file can contain one of the following strings: +.TP 0.5i +.B ATTRIBUTE name oid type [flags] +Define a RADIUS attribute name to number mapping. + +The \fIname\fP field is a printable field, taken from various +specifications or vendor definitions. It is most commonly used as a +series of words, separated by hyphens. e.g. "User-Name". +Vendor-specific attributes (VSAs) are prefixed by the vendor name, +e.g. "Cisco-AVPair". The names should be globally unique, as they are +used as a key to look up the properties of the attribute. + +The \fIoid\fP field is taken from the relevant specification for that +name. In most cases, it is a decimal number, such as "256". For +certain attributes, a "dotted number" notation is used, e.g. "1.2". +The "dotted number" notation is used only for certain attributes. + +The \fItype\fP field can be one of the standard types: + + string UTF-8 printable text (the RFCs call this "text") + octets opaque binary data (the RFCs call this "string") + ipaddr IPv4 address + date Seconds since January 1, 1970 (32-bits) + integer 32-bit unsigned integer + ipv6addr IPv6 Address + ipv6prefix IPV6 prefix, with mask + ifid Interface Id (hex:hex:hex:hex) + integer64 64-bit unsigned integer + +The \fItype\fP field can be one of the following non-standard types: + + ether Ethernet MAC address + abinary Ascend binary filter format + byte 8-bit unsigned integer + short 16-bit unsigned integer + signed 31-bit signed integer (packed into 32-bit field) + tlv Type-Length-Value (allows nested attributes) + ipv4prefix IPv4 Prefix as given in RFC 6572. + +The last (optional) field of an attribute definition are additional +flags for that attribute, in a comma-separated list. Previous +versions of the server allowed these flags to include a vendor name. +This behavior may still work, but it is deprecated, and is not +recommended. + +The options are: + + encrypt=# set encryption type 1, 2, or 3. + has_tag The attribute can have an RFC 2868 style tag + +The "encrypt" flag marks the attribute as being encrypted with one of +three possible methods. "1" means that the attribute is encrypted +with the method as defined in \fIRFC2865\fP for the User-Password +attribute. "2" means that the password is encrypted with the method +as defined in \fIRFC2868\fP for the Tunnel-Password attribute. "3" +means that the attribute is encrypted as per Ascend's definitions for +the Ascend-Send-Secret attribute. + +The "has_tag" flag marks the attribute as being permitted to have a +tag, as defined in \fIRFC2868\fP. The purpose of the tag is to allow +grouping of attributes for tunneled users. See \fIRFC2868\fP for +more details. + +When the server receives an encoded attribute in a RADIUS packet, it +looks up that attribute by number in the dictionary, and uses the +definition found there for printing diagnostic and log messages. When +the server sees an attribute name in a configuration file, it looks up +that attribute by name in the dictionary, and uses the definition +found there. + +.TP 0.5i +.B VALUE attribute-name value-name number +Define an attribute value name to number mapping, for an attribute of +type \fIinteger\fP. The \fIattribute-name\fP field MUST be previously +defined by an \fIATTRIBUTE\fP entry. The \fIvalue-name\fP field can +be any non-space text, but is usually taken from \fIRFC2865\fP, or +other documents.. The \fInumber\fP field is also taken from the +relevant documents, for that name. + +When the server receives an encoded value in a RADIUS packet, it looks +up the value of that attribute by number in the dictionary, and uses +the name found there for printing diagnostic and log messages. +.TP 0.5i +.B VENDOR vendor-name number [format=...] +Define a Vendor Specific Attribute encapsulation for \fIvendor-name\fP +to \fInumber\fP. For a list of vendor names and numbers, see +http://www.iana.org/enterprise-numbers.txt. + +The "format=t,l" statement tells the server how many octets to use to +encode/decode the vendor "type" and "length" fields in the attributes. +The default is "format=1,1", which does not have to be specified. For +USR VSA's, the format is "format=4,0", for Lucent VSA's it's +"format=2,1", and for Starent VSA's it's "format=2,2". + +The supported values for the number of type octets (i.e. the first +digit) are 1, 2, and 4. The support values for the number of length +octets (i.e. the second digit) are 0, 1, and 2. Any combination of +those values will work. + +.TP 0.5i +.B BEGIN-VENDOR vendor-name +Define the start of a block of Vendor-Specific attributes. All of the +following \fIATTRIBUTE\fP definitions are interpreted as being for the +named vendor, until the block is closed by an "END-VENDOR" statement. + +This practice is preferred to placing the vendor name at the end of an +\fIATTRIBUTE\fP definition. + +For VSAs in the RFC 6929 "Extended vendor-specific" space, a format +can be specified following the "vendor-name". The format should be +"format=Extended-Vendor-Specific-1", through +"format=Extended-Vendor-Specific-6". The matching "END-VENDOR" should +just have the "vendor-name", without the format string. +.TP 0.5i +.B END-VENDOR vendor-name +End a previously defined BEGIN-VENDOR block. The "vendor-name" must match. +.TP 0.5i +.B $INCLUDE filename +Include dictionary entries from the file \fIfilename\fP. The +\fIfilename\fP is taken as relative to the location of the file which +is asking for the inclusion. +.TP 0.5i +.B BEGIN-TLV name +This feature is supported for backwards compatibility with older +dictionaries. It should not be used. The new "oid" form for defining +the attribute number should be used instead. +.TP 0.5i +.B END-TLV name +This feature is supported for backwards compatibility with older +dictionaries. It should not be used. The new "oid" form for defining +the attribute number should be used instead. +.PP +.SH FILES +.I /etc/raddb/dictionary, +.I /usr/share/freeradius/dictionary.* +.SH "SEE ALSO" +.BR radiusd (8), +.BR RFC2865, +.BR RFC2866, +.BR RFC2868 +.BR RFC6929 diff --git a/man/man5/radiusd.conf.5 b/man/man5/radiusd.conf.5 new file mode 100644 index 0000000..3f7caa6 --- /dev/null +++ b/man/man5/radiusd.conf.5 @@ -0,0 +1,202 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH radiusd.conf 5 "28 Jun 2013" "" "FreeRADIUS configuration file" +.SH NAME +radiusd.conf \- configuration file for the FreeRADIUS server +.SH DESCRIPTION +The \fBradiusd.conf\fP file resides in the radius database directory, +by default \fB/etc/raddb\fP. It defines the global configuration for +the FreeRADIUS RADIUS server. +.SH "CONTENTS" +There are a large number of configuration parameters for the server. +Most are documented in the file itself as comments. This page +documents only the format of the file. Please read the +\fBradiusd.conf\fP file itself for more information. + +The configuration file parser is independent of the server +configuration. This means that you can put almost anything into the +configuration file. So long as it is properly formatted, the server +will start. + +When the server parses the configuration file, it looks only for those +configurations it understands. Extra configuration items are ignored. +This "feature" can be (ab)used in certain interesting ways. +.SH "FILE FORMAT" +The file format is line-based, like many other Unix configuration +files. Each entry in the file must be placed on a line by itself, +although continuations are supported. + +The file consists of configuration items (variable = value pairs), +sections, and comments. +.IP Variables +Variables can be set via: + +.DS +.br + name = value +.DE + +Single and double-quoted strings are permitted: + +.DS +.br + string1 = "hello world" +.br + string2 = 'hello mom' +.DE +.IP Sections +A section begins with a section name, followed on the same line by an +open bracket '\fB{\fP'. Section may contain other sections, comments, or +variables. Sections may be nested to any depth, limited +only by available memory. A section ends with a close bracket +\'\fB}\fP', on a line by itself. + +.DS +.br + section { +.br + ... +.br + } +.DE + +Sections can sometimes have a second name following the first one. +The situations where this is legal depend on the context. See the +examples and comments in the \fBradiusd.conf\fP file for more +information. + +.DS +.br + section foo { +.br + ... +.br + } +.DE +.IP Comments +Any line beginning with a (\fB#\fP) is deemed to be a comment, and is +ignored. Comments can appear after a variable or section definitions. + +.DS +.br + # comment +.br + foo = bar # set variable 'foo' to value 'bar' +.br + section { # start of section +.br + ... +.br + } # end of section +.DE +.IP Continuations +Long lines can be broken up via continuations, using '\\' as the last +character of the line. For example, the following entry: + +.DS +.br + foo = "blah \\ +.br + blah \\ +.br + blah" +.DE + +will set the value of the variable "foo" to "blah blah blah". Any CR +or LF is not turned into a space, but all other whitespace is +preserved in the final value. +.SH "REFERENCES" +The value of a variable can reference another variable. These +references are evaluated when the configuration file is loaded, which +means that there is no run-time cost associated with them. This +feature is most useful for turning long, repeated pieces of text into +short ones. + +Variables are referenced by ${variable_name}, as in the following examples. + +.DS + foo = bar # set variable 'foo' to value 'bar' +.br + who = ${foo} # sets variable 'who' to value of variable 'foo' +.br + my = "${foo} a" # sets variable 'my' to "bar a" +.DE + +If the variable exists in a section or subsection, it can be +referenced as ${section.subsection.variable}. Forward references are +not allowed. Relative references are allowed, by pre-pending the name +with one or more period. + +.DS + blogs = ${.foo} + +.DE +Will set variable \fBblogs\fP to the value of variable \fBfoo\fP, +from the current section. + +.DS + blogs = ${..foo} + +.DE +Will set variable \fBblogs\fP to the value of variable \fBfoo\fP, from the +section which contains the current section. + +.DS + blogs = ${modules.detail.filename} + +.DE +Will set variable \fBblogs\fP to the value of variable \fBfilename\fP, +of the \fBdetail\fP module, which is in the \fBmodules\fP section of +the configuration file. + +Properties of anonymous parent sections may also be referenced, currently +\fBname\fP and \fBinstance\fP are supported. + +.DS + modules { + example foo { + file = ${.:name} + } + } + +.DE +Will set variable \fBfile\fP to the name of the containing section (example). + +.DS + modules { + example foo { + file = ${.:instance} + } + } + +.DE +Will set variable \fBfile\fP to the instance name of the containing +section (foo). + +.DS + modules { + example foo { + file = ${..:name} + } + } + +.DE +Will set variable \fBfile\fP to the name of the parent of the containing +section (modules). +.SH FILES +/etc/raddb/radiusd.conf +.SH "SEE ALSO" +.BR radiusd (8) +.BR unlang (5) +.SH AUTHOR +Alan DeKok <aland@freeradius.org> diff --git a/man/man5/radrelay.conf.5 b/man/man5/radrelay.conf.5 new file mode 100644 index 0000000..db74d83 --- /dev/null +++ b/man/man5/radrelay.conf.5 @@ -0,0 +1,146 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH radrelay.conf 5 "27 May 2005" "" "FreeRADIUS configuration file" +.SH NAME +radrelay.conf - configuration file for the FreeRADIUS server "radrelay" personality +.SH DESCRIPTION +The \fBradrelay.conf\fP file resides in the radius database directory, +by default \fB/etc/raddb\fP. It defines the global configuration for +the FreeRADIUS server, when the server is operating as "radrelay". +.SH "FILE FORMAT" +For a detailed description of the file format, see "man radiusd.conf". +The configuration entries are much the same for radrelay.conf, with a +few differences as noted here. +.SH "REPLICATION FOR BACKUPS" +Many sites run multiple radius servers; at least one primary and one +backup server. When the primary goes down, most NASes detect that and +switch to the backup server. + +That will cause your accounting packets to go to the backup server - +and some NASes don't even switch back to the primary server when it +comes back up. + +The result is that accounting records are missed, and/or the +administrator must jump through hoops in order to combine the +different detail files from multiple servers. It also means that the +session database ("radutmp", used for radwho and simultaneous use +detection) gets out of sync. + +radrelay solves this issue by "relaying" packets from one server to +another, so they both have the same set of accounting data. +.SH "BUFFERING FOR HIGH-LOAD SERVERS" +If the RADIUS server suddenly receives a many accounting packets, +there may be insufficient CPU power to process them all in a timely +manner. This problem is especially noticeable when the accounting +packets are going to a back-end database. + +Similarly, you may have one database that tracks "live" sessions, and +another that tracks historical accounting data. In that case, +accessing the first database is fast, as it is small. Accessing the +second database many be slower, as it may contain multiple gigabytes +of data. In addition, writing to the first database in a timely +manner is important, while data may be written to the second database +with a few minutes delay, without any harm being done. +.SH "RELAYING OF ACCOUNTING PACKETS" +The \fBradrelay.conf\fP file controls the "radrelay" personality of +the server, which can perform both of the functions above at the same +time. +.SH USAGE +First, you should configure the main radius server to log to an extra, +single detail file. This may be done by adding an extra instance of +the detail module to \fBradiusd.conf\fP: + +For example: + +.DS + detail radrelay-detail { +.br + filename = ${radacctdir}/radrelay/detail +.br + permissions = 0600 +.br + dir_permissions = 0755 +.br + locking = yes +.br + } +.br + ... +.br + accounting { +.br + ... +.br + radrelay-detail +.br + ... +.br + } +.br +.DE +This configuration will cause accounting packets to be logged to the +\fI${radacctdir}/radrelay/detail\fP file. This file should not be +rotated by standard log rotation scripts, as the \fBradrelay\fP +program will read and rotate it. +.SH RADRELAY.CONF EXAMPLE +See the \fBradrelay.conf\fP file for detailed instructions on +configuration entries, what they mean, and how to use them. + +To have the "radrelay" portion of the server read the above detail +file, configure \fBradrelay.conf\fP with the following section: + +.DS +.br + listen { +.br + type = detail +.br + filename = ${radacctdir}/radrelay/detail +.br + max_outstanding = 100 +.br + identity = radrelay +.br + } +.br +.DE + +The server will read the accounting packets from the detail file, and +process them just as if it had received them from the NAS. Therefore, +you should configure the "accounting" section of \fBradrelay.conf\fP +to write the accounting records to an "sql" module, or to proxy them +to another RADIUS server. + +Then, start the server via the following command: + +$ radiusd \-n radrelay + +The server should start up, read the detail file, and process +accounting packets from it. +.SH NOTES +The \fBradiusd.conf\fP file is not read at all when the server is +running as radrelay. Please edit \fBradrelay.conf\fP. +.SH CREDITS +The original "radrelay" program was written by Miquel van Smoorenburg +for the Cistron radius project, and ported to FreeRADIUS by Simon +Ekstrand. The "radsqlrelay" was written by Kostas Kalavras. It was +never released as part of an official FreeRADIUS release, but served as +a basis for the design of this implementation. +.PP +.SH FILES +/etc/raddb/radrelay.conf +.SH "SEE ALSO" +.BR radiusd (8), +.BR radiusd.conf (5) +.SH AUTHOR +Alan DeKok <aland@ox.org> diff --git a/man/man5/rlm_always.5 b/man/man5/rlm_always.5 new file mode 100644 index 0000000..383b271 --- /dev/null +++ b/man/man5/rlm_always.5 @@ -0,0 +1,119 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH rlm_always 5 "10 January 2015" "" "FreeRADIUS Module" +.SH NAME +rlm_always \- FreeRADIUS Module +.SH DESCRIPTION +The \fIrlm_always\fP module provides a simple way to "always" return a +value during the processing of a configuration section. +.PP +The main configuration item is \fIrcode\fP, which sets the return code that +this instantiation of the module will return. The default, if none +specified, is 'fail'. +.PP +The valid options for rcode are as follows: +.RS +.TP +reject +reject the user; +.IP fail +a failure has occurred; +.IP ok +success; +.IP handled +the request has been handled: processing should be stopped and the response +sent; +.IP invalid +request is invalid; +.IP userlock +the user account has been locked out; +.IP notfound +the user account cannot be found; +.IP noop +no-op: nothing has happened; +.IP updated +the request has been updated. +.RE +.SH CONFIGURATION +.PP +.IP "rcode = <code>" +This module will always return with the code specified, as listed in the +table above. If unspecified, the default is 'fail'. +.IP "simulcount = <n>" +If this module is used in the session{} section, the simulcount option +simulates the user having 'n' current sessions. The default is to not +override the number of sessions. +.IP "mpp = <yes|no>" +If set to yes, and this module is used in the session{} section, this +simulates the user having multilink sessions. The default is 'no'. +.PP +.SH EXAMPLE +.PP +.DS +modules { + ... +.br + # instantiate the "always" module with the name "ok" +.br + always ok { +.br + # return code for this instantiation is "ok": +.br + rcode = ok +.br + } +.br + ... +.br +} +.br + +.br +authorize { + ... +.br + redundant { + sql1 # try to find the user in sql1 +.br + sql2 # try to find the user in sql2 +.br + # the default here would be to fail, but... +.br + ok # if still not found, it's OK. +.br + } + ... +.br +} +.DE +.SH SECTIONS +.BR authorization, +.BR authentication, +.BR postauthentication, +.BR preaccounting, +.BR accounting, +.BR preproxy, +.BR postproxy +.PP +.SH FILES +.I /etc/raddb/mods-available/always +.PP +.SH "SEE ALSO" +.BR radiusd (8), +.BR radiusd.conf (5), +.BR unlang (5) +.PP +Further details of how module return codes operate can be found at <http://wiki.freeradius.org/config/Fail-over>. +.SH AUTHOR +Chris Parker <cparker@segv.org>, Matthew Newton +<matthew@newtoncomputing.co.uk>. diff --git a/man/man5/rlm_attr_filter.5 b/man/man5/rlm_attr_filter.5 new file mode 100644 index 0000000..adb6130 --- /dev/null +++ b/man/man5/rlm_attr_filter.5 @@ -0,0 +1,145 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH rlm_attr_filter 5 "27 June 2013" "" "FreeRADIUS Module" +.SH NAME +rlm_attr_filter \- FreeRADIUS Module +.SH DESCRIPTION +The \fIrlm_attr_filter\fP module exists for filtering certain +attributes and values in received ( or transmitted ) radius packets. +It gives the server a flexible framework to filter the attributes we +send to or receive from home servers or NASes. This makes sense, for +example, in an out-sourced dialup situation to various policy +decisions, such as restricting a client to certain ranges of +Idle-Timeout or Session-Timeout. +.PP +Filter rules are normally defined and applied on a per-realm basis, +where the realm is anything that is defined and matched based on the +configuration of the \fIrlm_realm\fP module. Filter rules can +optionally be applied using another attribute, by editing the +\fIkey\fP configuration for this module. +.PP +In 2.0.1 and earlier versions, the "accounting" section filtered the +Accounting-Request, even though it was documented as filtering the +response. This issue has been fixed in version 2.0.2 and later +versions. The "preacct" section may now be used to filter +Accounting-Request packets. The "accounting" section now filters +Accounting-Response packets. Administrators using "attr_filter" in +the "accounting" section SHOULD move the reference to "attr_filter" +from "accounting" to "preacct". +.PP +The file that defines the attribute filtering rules follows a similar +syntax to the \fIusers\fP file. There are a few differences however: +.PP +.DS + There are no check-items allowed other than the name of the key. +.PP + There can only be a single DEFAULT entry. +.PP +The rules for each entry are parsed to top to bottom, and an +attribute must pass *all* the rules which affect it in order to +make it past the filter. Order of the rules is important. +The operators and their purpose in defining the rules are as +follows: +.TP +.B = +THIS OPERATOR IS NOT ALLOWED. If used, and warning message is +printed and it is treated as == +.TP +.B := +Set, this attribute and value will always be placed in the +output A/V Pairs. If the attribute exists, it is overwritten. +.TP +.B == +Equal, value must match exactly. +.TP +.B =* +Always Equal, allow all values for the specified attribute. +.TP +.B !* +Never Equal, disallow all values for the specified attribute. +( This is redundant, as any A/V Pair not explicitly permitted +will be dropped ). +.TP +.B != +Not Equal, value must not match. +.TP +.B >= +Greater Than or Equal +.TP +.B <= +Less Than or Equal +.TP +.B > +Greater Than +.TP +.B < +Less Than +.PP +If regular expressions are enabled the following operators are +also possible. ( Regular Expressions are included by default +unless your system doesn't support them, which should be rare ). +The value field uses standard regular expression syntax. +.PP +.TP +.B =~ +Regular Expression Equal +.TP +.B !~ +Regular Expression Not Equal +.PP +See the default \fI/etc/raddb/mods-config/attr_filter/\fP for working examples of +sample rule ordering and how to use the different operators. +.DE +.PP +The configuration items are: +.IP file +This specifies the location of the file used to load the filter rules. +This file is used to filter the accounting response, packet before it +is proxied, proxy response from the home server, or our response to +the NAS. +.IP key +Usually %{Realm} (the default). Can also be %{User-Name}, or other +attribute that exists in the request. Note that the module always +keys off of attributes in the request, and NOT in any other packet. +.IP relaxed +If set to 'yes', then attributes which do not match any filter rules +explicitly, will also be allowed. This behaviour may be overridden +for an individual filter block using the Relax-Filter check item. +The default for this configuration item is 'no'. +.PP +.SH SECTIONS +.IP preacct +Filters Accounting-Request packets. +.IP accounting +Filters Accounting-Response packets. +.IP pre-proxy +Filters Accounting-Request or Access-Request packets prior to proxying +them. +.IP post-proxy +Filters Accounting-Response, Access-Accept, Access-Reject, or +Access-Challenge responses from a home server. +.IP authorize +Filters Access-Request packets. +.IP post-auth +Filters Access-Accept or Access-Reject packets. +.PP +.SH FILES +.I /etc/raddb/radiusd.conf +.I /etc/raddb/mods-config/attr_filter/* +.PP +.SH "SEE ALSO" +.BR radiusd (8), +.BR radiusd.conf (5) +.SH AUTHOR +Chris Parker, cparker@segv.org + diff --git a/man/man5/rlm_chap.5 b/man/man5/rlm_chap.5 new file mode 100644 index 0000000..de0b8c0 --- /dev/null +++ b/man/man5/rlm_chap.5 @@ -0,0 +1,30 @@ +.TH rlm_chap 5 "3 February 2004" "" "FreeRADIUS Module" +.SH NAME +rlm_chap \- FreeRADIUS Module +.SH DESCRIPTION +The \fIrlm_chap\fP module provides CHAP functionality. +.PP +This module validates a user with CHAP authentication. +If called in Authorize, it will look for CHAP-Password +attribute in the Access-Request and adds an Auth-Type +attribute set to CHAP if the Config-Items list unless +Auth-Type has already set. +.PP +CHAP authentication requires access to the clear-text +password for the user. Standard Unix system authentication +or passwords encrypted via crypt() are not compatible +with CHAP. +.PP +.SH SECTIONS +.BR authorization, +.BR authentication +.PP +.SH FILES +.I /etc/raddb/radiusd.conf +.PP +.SH "SEE ALSO" +.BR radiusd (8), +.BR radiusd.conf (5) +.SH AUTHOR +Chris Parker, cparker@segv.org + diff --git a/man/man5/rlm_counter.5 b/man/man5/rlm_counter.5 new file mode 100644 index 0000000..a8eae18 --- /dev/null +++ b/man/man5/rlm_counter.5 @@ -0,0 +1,89 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH rlm_counter 5 "13 March 2004" "" "FreeRADIUS Module" +.SH NAME +rlm_counter \- FreeRADIUS Module +.SH DESCRIPTION +The \fIrlm_counter\fP module provides a general framework to +allow access based on accumulated usage of a resource, such as +total time online in a given period, total data transferred in +a given period, etc. This is very useful in a 'Prepaid Service' +situation, where a user has paid for a finite amount of usage +and should not be allowed to use more than that service. Collection, +monitoring, and replenishment of prepaid services are beyond the +scope of this module. +.PP +The main configuration items to be aware of are: +.IP filename +The filename where the usage data is stored. +.IP key +An attribute which will be present in the Access-Request to be used as +the 'index' value for the counter. A counter entry is tracked for +each unique key. The most likely key you will want to use is User-Name. +.IP count_attribute +An attribute which will be used to increment the counter value. If this +attribute is Acct-Session-Time or an integer value the counter data is +incremented by the Attribute value. For all other attribute types the +counter is incremented by one. +.IP reset +How frequently the counter data should be set back to 0. Valid values for +this variable are: +.BR hourly, +.BR daily, +.BR weekly, +.BR monthly, +.BR or never +Alternatively, it can be user defined, in the form: num[hdwm]. num is +a numeric value, followed by one or none of the following letters. h: hours, +d: days, w: weeks, m: months. +.IP check_name +This defines an attribute name which will be registered by the counter module +and can be used to set the maximum allowed value for the counter after which +the user is rejected. If Daily-Session-Time is set, you can use the following +syntax in the Users file to set a cap of 3600 seconds ( 8 hours ): +.PP +.DS +DEFAULT Max-Daily-Session := 3600 +.DE +.PP +.IP reply_name +This is the name of the attribute which will contain the remaining value for +the counter in the reply packet when the user is successfully authorized. The +default attribute name is "Session-Timeout". +.IP allowed_service_type +This can be used to only apply the limitations to specific service types of +sessions. For example, setting this to Framed-User will only apply the counter +module to Framed sessions, excluding other types such as Telnet or Rlogin. +.IP cache_size +The maximum size of the cache to be used by the module. The default is 1000. +.SH NOTES +This module registers an attribute, so it should be added to the +instantiate section, to be called on server startup. When used +in the authorize section, it must come after any modules which +set the 'check_name' attribute. +.PP +.SH SECTIONS +.BR instantiate, +.BR authorize, +.BR accounting +.PP +.SH FILES +.I /etc/raddb/radiusd.conf +.PP +.SH "SEE ALSO" +.BR radiusd (8), +.BR radiusd.conf (5) +.BR rlm_sqlcounter (5) +.SH AUTHOR +Chris Parker, cparker@segv.org + diff --git a/man/man5/rlm_detail.5 b/man/man5/rlm_detail.5 new file mode 100644 index 0000000..6609e16 --- /dev/null +++ b/man/man5/rlm_detail.5 @@ -0,0 +1,89 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH rlm_detail 5 "27 June 2013" "" "FreeRADIUS Module" +.SH NAME +rlm_detail \- FreeRADIUS Module +.SH DESCRIPTION +The \fIrlm_detail\fP module writes radius packets to 'detail' files. +It is primarily used for storing accounting information, but can be +used in other sections to write packet details as well. +.PP +The file format is similar to that of the old Livingston servers, and +many 'detail' file parsers should work with FreeRADIUS. +.PP +The main configuration items to be aware of are: +.IP file +The file name in which to store the radius packet records. NOTE: this +variable is run through dynamic string expansion, and can include +FreeRADIUS variables to create a dynamic filename. +.PP + %{radacctdir}/%{Client-IP-Address}/detail-%Y%m +.PP + This will create one file per month, for each client. + This accomplishes 'file rotation' automatically from + within the server. +.PP +.IP permissions +The file permissions of the file. +If omitted, the default is 0600. +.IP locking +This option is set to 'yes' or 'no'. By default it is 'no'. Set this +to yes to enable file locking, which is used with the 'radrelay' +program. +.SH CONFIGURATION +.PP +.DS +modules { + ... +.br + detail { +.br + filename = ${radacctdir}/%{Client-IP-Address}/detail-%Y%m +.br + permissions = 0600 +.br + dir_permissions = 0755 +.br + locking = no +.br + } +.br + ... +.br +} + ... +.br +accounting { + ... +.br + detail + ... +.br +} +.DE +.PP +.SH SECTIONS +.BR authorization, +.BR accounting, +.BR pre_proxy, +.BR post_proxy, +.BR post_authentication +.PP +.SH FILES +.I /etc/raddb/radiusd.conf +.PP +.SH "SEE ALSO" +.BR radiusd (8), +.BR radiusd.conf (5) +.SH AUTHORS +Chris Parker, cparker@segv.org diff --git a/man/man5/rlm_digest.5 b/man/man5/rlm_digest.5 new file mode 100644 index 0000000..fb99e0f --- /dev/null +++ b/man/man5/rlm_digest.5 @@ -0,0 +1,79 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH rlm_digest 5 "31 March 2005" "" "FreeRADIUS Module" +.SH NAME +rlm_digest \- FreeRADIUS Module +.SH DESCRIPTION +The \fIrlm_digest\fP module authenticates RADIUS Access-Request +packets that contain Cisco SIP digest authentication attributes. The +module should be listed in the \fIauthorize\fP and \fIauthenticate\fP +sections of \fIradiusd.conf\fP. +.SH CONFIGURATION +The digest module requires no additional configuration items. When it +is being used to authenticate requests, however, it does require +access to the clear-text password for the user. Hashed passwords are +not acceptable, and will not work. +.SH EXAMPLES +Add the following lines to the top of your 'raddb/users' file: +.PP +.DS +#--- +.br +test Auth-Type := Digest, User-Password = "test" +.br + Reply-Message = "Hello, test with digest" +.br +#--- +.DE + +Once the server has been started (debugging mode is recommended), +use '\fIradclient\fP to send the following packet to the server: +.PP +.DS +$ radclient \-f digest localhost auth testing123 +.DE + +Where 'digest' is a file containing: +.PP +.DS + User-Name = "test", +.br + Digest-Response = "631d6d73147add2f9e437f59bbc3aeb7", +.br + Digest-Realm = "testrealm", +.br + Digest-Nonce = "1234abcd", +.br + Digest-Method = "INVITE", +.br + Digest-URI = "sip:5555551212@example.com", +.br + Digest-Algorithm = "MD5", +.br + Digest-User-Name = "test", +.br + Message-Authenticator = "" +.DE + +You should see the authentication succeed. + +.SH SECTIONS +.BR authorize, +.BR authenticate +.PP +.SH FILES +.I /etc/raddb/radiusd.conf, +.I draft-sterman-aaa-sip-00.txt +.PP +.SH AUTHOR +Alan DeKok <aland@ox.org> diff --git a/man/man5/rlm_expr.5 b/man/man5/rlm_expr.5 new file mode 100644 index 0000000..313a16e --- /dev/null +++ b/man/man5/rlm_expr.5 @@ -0,0 +1,113 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH rlm_expr 5 "5 February 2004" "" "FreeRADIUS Module" +.SH NAME +rlm_expr \- FreeRADIUS Module +.SH DESCRIPTION +The \fIrlm_expr\fP module allows the server to perform +limited mathematical calculations. This module is not called +directly in any section, it is invoked through the dynamic expansion +of strings. +.PP +For example, some NAS boxes send a NAS-Port attribute +which is a 32-bit number composed of port, card, and interface, all in +different bytes. To see these attributes split into pieces, you can +have an entry in the 'users' file like: + +.DS +DEFAULT +.br + Vendor-Interface = `%{expr: %{NAS-Port} / (256 * 256)}`, +.br + Vendor-Card = `%{expr: (%{NAS-Port} / 256) %% 256}`, +.br + Vendor-Port = `%{expr: %{NAS-Port} %% 256}` +.br + +.DE +where the attributes Vendor-Interface, Vendor-Card, and Vendor-Port +are attributes created by either you or a vendor-supplied +dictionary. + +The mathematical operators supported by the expression module are: +.TP +.B + +addition +.TP +.B - +subtraction +.TP +.B / +division +.TP +.B %% +modulo remainder +.TP +.B * +multiplication +.TP +.B & +boolean AND +.TP +.B | +boolean OR +.TP +.B () +grouping of sub-expressions +.PP +NOTE: The modulo remainder operator is '%%', and not '%'. This +is due to the '%' character being used as a special character for +dynamic translation. +.PP +NOTE: These operators do NOT have precedence. The parsing +of the input string, and the calculation of the answer, is done +strictly left to right. If you wish to order the expressions, you +MUST group them into sub-expression, as shown in the previous +example. +.PP +All of the calculations are performed as unsigned 32-bit integers. +.DE +.SH CONFIGURATION +.DS +modules { + ... +.br + expr { +.br + } +.br + ... +.br +} +.br + ... +.br +instantiate { + ... +.br + expr + ... +.br +} +.SH SECTIONS +.BR instantiate +.PP +.SH FILES +.I /etc/raddb/radiusd.conf +.PP +.SH "SEE ALSO" +.BR radiusd (8), +.BR radiusd.conf (5) +.SH AUTHOR +Chris Parker, cparker@segv.org + diff --git a/man/man5/rlm_files.5 b/man/man5/rlm_files.5 new file mode 100644 index 0000000..52f4734 --- /dev/null +++ b/man/man5/rlm_files.5 @@ -0,0 +1,95 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH rlm_files 5 "5 February 2004" "" "FreeRADIUS Module" +.SH NAME +rlm_files \- FreeRADIUS Module +.SH DESCRIPTION +The \fIrlm_files\fP module uses the 'users' file for accessing +authorization information for users. Additionally, it supports +a 'users' file syntax to be applied to the accounting and pre-proxy +sections. +.PP +The main configuration items to be aware of are: +.IP usersfile +The filename of the 'users' file, which is parsed during the +authorization stage of this module. +.IP acctusersfile +The filename of the 'users' file, which is parsed during the +accounting stage of this module. +.IP preproxy_usersfile +The filename of the 'users' file, which is parsed during the +pre_proxy stage of this module. +.IP compat +This option allows FreeRADIUS to parse an old style Cistron syntax. +The default is 'no'. If you need to parse an old style Cistron +file, set this option to 'cistron'. +.IP key +This option lets you set the attribute to use as a key to find +entries. The default is "%{%{Stripped-User-Name}:-%{User-Name}}". Note +that the key MUST supply real data. Dynamic attributes like "Group" +will not work, because the "Group" attribute can only be used as a +comparison, to see if a user is in a Unix group. It will not return +the name of the Unix group that a user is in. +.PP +If you want to use groups as a key, see the \fIrlm_passwd\fP, which +will create a real attribute that contains the group name. +.PP +This configuration entry enables you to have configurations that +perform per-group checks, and return per-group attributes, where the +group membership is dynamically defined by a previous module. It also +lets you do things like key off of attributes in the reply, and +express policies like "when I send replies containing attribute +FOO with value BAR, do more checks, and maybe send additional +attributes". +.SH CONFIGURATION +.PP +.DS +modules { + ... stuff here ... +.br + files { +.br + usersfile = %{confdir}/users +.br + acctusersfile = %{confdir}/acct_users +.br + preproxy_usersfile = %{confdir}/preproxy_users +.br + compat = no +.br + key = %{%{Stripped-User-Name}:-%{User-Name}} +.br + } +.br + ... stuff here ... +.br +} +.DE +.PP +.SH SECTIONS +.BR authorization, +.BR accounting, +.BR pre_proxy +.PP +.SH FILES +.I /etc/raddb/radiusd.conf, +.I /etc/raddb/users, +.I /etc/raddb/acct_users, +.I /etc/raddb/preproxy_users +.PP +.SH "SEE ALSO" +.BR radiusd (8), +.BR radiusd.conf (5), +.BR users (5) +.SH AUTHORS +Chris Parker, cparker@segv.org diff --git a/man/man5/rlm_idn.5 b/man/man5/rlm_idn.5 new file mode 100644 index 0000000..391b7d9 --- /dev/null +++ b/man/man5/rlm_idn.5 @@ -0,0 +1,45 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH rlm_idn 5 "8 May 2013" "" "FreeRADIUS Module" +.SH NAME +rlm_idn \- FreeRADIUS Module +.SH DESCRIPTION +When instantiated, the \fIrlm_idn\fP module provides an xlat +for performing IDNA encoding of internationalized domain names. +Decoding and other similar encodings like plain punycode are not +currently supported. +.PP +For example, the following unlang expression would evaluate to TRUE: + +"%{idn:fūbar.site}" == "xn--fbar-v7a.site" + +.PP +Each instance of rlm_idn may take the following parameters: +.IP use_std3_ascii_rules +This boolean is set by default and prohibits e.g. underscores in domain names. +.IP allow_unassigned +This boolean is unset by default, which prohibits use of unassigned Unicode points. +.PP +.SH FILES +.I /etc/raddb/radiusd.conf +.PP +.SH REFERENCES +RFC 3490 +.PP +.SH "SEE ALSO" +.BR radiusd (8), +.BR radiusd.conf (5) +.BR idna_to_ascii_8z (3) +.SH AUTHOR +Brian S. Julin, bjulin@clarku.edu + diff --git a/man/man5/rlm_mschap.5 b/man/man5/rlm_mschap.5 new file mode 100644 index 0000000..cc3a72a --- /dev/null +++ b/man/man5/rlm_mschap.5 @@ -0,0 +1,110 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH rlm_mschap 5 "13 March 2004" "" "FreeRADIUS Module" +.SH NAME +rlm_mschap \- FreeRADIUS Module +.SH DESCRIPTION +The \fIrlm_mschap\fP module provides MS-CHAP and MS-CHAPv2 +authentication support. +.PP +This module validates a user with MS-CHAP or MS-CHAPv2 +authentication. +If called in Authorize, it will look for MS-CHAP Challenge/Response +attributes in the Acess-Request and adds an Auth-Type +attribute set to MS-CHAP in the Config-Items list unless +Auth-Type has already set. +.PP +The module can authenticate the MS-CHAP session via plain-text +passwords (User-Password attribute), or NT passwords (NT-Password +attribute). The module cannot perform authentication against an NT +domain. +.PP +The module also enforces the SMB-Account-Ctrl attribute. See the +Samba documentation for the meaning of SMB account control. The +module does not read Samba password files. Instead, the fIrlm_passwd\fP +module can be used to read a Samba password file, and supply an +NT-Password attribute which this module can use. +.PP +The main configuration items to be aware of are: +.IP authtype +This is the string used to set the authtype. Normally it should be +left to the default value of MS-CHAP. +.IP use_mppe +Unless this is set to 'no', FreeRADIUS will add MS-CHAP-MPPE-Keys for +MS-CHAPv1 and MS-MPPE-Recv-Key/MS-MPPE-Send-Key for MS-CHAPv2. The +default is 'yes'. +.IP require_encryption +If MPPE is enabled, setting this attribute to 'yes' will cause the +MS-MPPE-Encryption-Policy attribute to be set to require encryption. +The default is 'no'. +.IP require_strong +If MPPE is enabled, setting this attribute to 'yes' will cause the +MS-MPPE-Encryption-Types attribute to be set to require a 128 bit key. +The default is 'no'. +.IP with_ntdomain_hack +Windows clients send User-Name in the form of "DOMAIN\\User", but send the +challenge/response based only on the User portion. Setting this value +to yes, enables a work-around for this error. The default is 'no'. +.PP +.SH CONFIGURATION +.DS +modules { + ... +.br + mschap { +.br + authtype = MS-CHAP +.br + use_mppe = yes +.br + } +.br + ... +.br +} +.br + ... +.br +authorize { + ... +.br + mschap +.br + ... +.br +} + ... +.br +authenticate { + ... +.br + mschap +.br + ... +.br +} +.DE +.PP +.SH SECTIONS +.BR authorization, +.BR authentication +.PP +.SH FILES +.I /etc/raddb/radiusd.conf +.PP +.SH "SEE ALSO" +.BR radiusd (8), +.BR radiusd.conf (5) +.SH AUTHOR +Chris Parker, cparker@segv.org + diff --git a/man/man5/rlm_pap.5 b/man/man5/rlm_pap.5 new file mode 100644 index 0000000..e2ad426 --- /dev/null +++ b/man/man5/rlm_pap.5 @@ -0,0 +1,137 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH rlm_pap 5 "10 January 2015" "" "FreeRADIUS Module" +.SH NAME +rlm_pap \- FreeRADIUS Module +.SH DESCRIPTION +The \fIrlm_pap\fP module authenticates RADIUS Access-Request packets +that contain a User-Password attribute. The module should also be +listed last in the \fIauthorize\fP section, so that it can set the +Auth-Type attribute as appropriate. +.PP +When a RADIUS packet contains a clear-text password in the form of a +User-Password attribute, the \fIrlm_pap\fP module may be used for +authentication. The module requires a "known good" password, which it +uses to validate the password given in the RADIUS packet. That "known +good" password must be supplied by another module +(e.g. \fIrlm_files\fP, \fIrlm_ldap\fP, etc.), and is usually taken +from a database. +.SH CONFIGURATION +.PP +The only configuration item is: +.IP normalise +The default is "yes". This means that the module will try to +automatically detect passwords that are hex- or base64-encoded and +decode them back to their binary representation. However, some clear +text passwords may be erroneously converted. Setting this to "no" +prevents that conversion. +.SH USAGE +.PP +The module looks for the Password-With-Header control attribute to find +the "known good" password. The attribute value comprises the header +followed immediately by the password data. The header is given by the +following table. +.PP +.DS +.br +Header Attribute Description +.br +------ --------- ----------- +.br +{clear} Cleartext-Password Clear-text passwords +.br +{cleartext} Cleartext-Password Clear-text passwords +.br +{crypt} Crypt-Password Unix-style "crypt"ed passwords +.br +{md5} MD5-Password MD5 hashed passwords +.br +{base64_md5} MD5-Password MD5 hashed passwords +.br +{smd5} SMD5-Password MD5 hashed passwords, with a salt +.br +{sha} SHA-Password SHA1 hashed passwords +.br + SHA1-Password SHA1 hashed passwords +.br +{ssha} SSHA-Password SHA1 hashed passwords, with a salt +.br +{sha2} SHA2-Password SHA2 hashed passwords +.br +{sha224} SHA2-Password SHA2 hashed passwords +.br +{sha256} SHA2-Password SHA2 hashed passwords +.br +{sha384} SHA2-Password SHA2 hashed passwords +.br +{sha512} SHA2-Password SHA2 hashed passwords +.br +{ssha224} SSHA2-224-Password SHA2 hashed passwords, with a salt +.br +{ssha256} SSHA2-256-Password SHA2 hashed passwords, with a salt +.br +{ssha384} SSHA2-384-Password SHA2 hashed passwords, with a salt +.br +{ssha512} SSHA2-512-Password SHA2 hashed passwords, with a salt +.br +{nt} NT-Password Windows NT hashed passwords +.br +{nthash} NT-Password Windows NT hashed passwords +.br +{md4} NT-Password Windows NT hashed passwords +.br +{x-nthash} NT-Password Windows NT hashed passwords +.br +{ns-mta-md5} NS-MTA-MD5-Password Netscape MTA MD5 hashed passwords +.br +{x- orcllmv} LM-Password Windows LANMAN hashed passwords +.br +{X- orclntv} NT-Password Windows NT hashed passwords +.DE + +The module tries to be flexible when handling the various password +formats. It will automatically handle Base-64 encoded data, hex +strings, and binary data, and convert them to a format that the server +can use. +.PP +If there is no Password-With-Header attribute, the module looks for one +of the Cleartext-Password, NT-Password, Crypt-Password, etc. attributes +as listed in the above table. These attributes should contain the +relevant format password directly, without the header prefix. +.PP +Only one control attribute should be set, otherwise behaviour is +undefined as to which one is used for authentication. +.SH NOTES +.PP +It is important to understand the difference between the User-Password +and Cleartext-Password attributes. The Cleartext-Password attribute +is the "known good" password for the user. Simply supplying the +Cleartext-Password to the server will result in most authentication +methods working. The User-Password attribute is the password as typed +in by the user on their private machine. The two are not the same, +and should be treated very differently. That is, you should generally +not use the User-Password attribute anywhere in the RADIUS +configuration. +.SH SECTIONS +.BR authorize +.BR authenticate +.PP +.SH FILES +.I /etc/raddb/mods-available/pap +.PP +.SH "SEE ALSO" +.BR radiusd (8), +.BR radiusd.conf (5) +.SH AUTHOR +Alan DeKok <aland@freeradius.org> + diff --git a/man/man5/rlm_passwd.5 b/man/man5/rlm_passwd.5 new file mode 100644 index 0000000..5a9ac7b --- /dev/null +++ b/man/man5/rlm_passwd.5 @@ -0,0 +1,136 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH rlm_passwd 5 "20 January 2015" "" "FreeRADIUS Module" +.SH NAME +rlm_passwd \- FreeRADIUS Module +.SH DESCRIPTION +The \fIrlm_passwd\fP module provides authorization via files similar +in format to /etc/passwd. +.PP +This module allows you to retrieve any account information from any +files with passwd-like format (/etc/passwd, /etc/group, +smbpasswd, .htpasswd, etc). Every field of the file may be mapped to +a RADIUS attribute, with one of the fields used as a key. +.PP +The module reads the file when it initializes, and caches the data in +memory. This makes it very fast, even for files with thousands of +lines. To re-read the file the module will need to be reloaded with +\fIradmin(8)\fP, or the server will need to be sent a SIGHUP, as +dynamic updates are not supported. +.PP +.SH CONFIGURATION +The configuration item(s): +.IP allow_multiple_keys +If set to 'yes', and more than one record in file matches the request, +then the attributes from all records will be used. If set to 'no' (the +default) the module will warn about duplicated records. +.IP delimiter\ =\ ":" +The character to use as a delimiter between fields. The default is +":" +.IP filename +The path to the file. +.IP format +The format of the fields in the file, given as an example line from +the file, with the content of the fields as the RADIUS attributes +which the fields map to. The fields are separated by the ':' character +in the configuration (no matter what is configured for the 'delimiter' +option). +.IP hash_size +The size of the hash table. A larger value means less probability of a +collision so records will be found faster, at the expense of greater +memory usage. Having a hash_size in the range of 30-100% of the number +of passwd file records is reasonable. +.IP ignore_empty +When set to "yes", the default, empty fields in the input will be +skipped and the RADIUS attribute will not be added. By setting this +value to "no", all attributes in the format list will always be added, +even if they have no value. +.IP ignore_nislike +If set to 'yes', then all records from the file beginning with the '+' +sign will be ignored. The default is 'no'. +.PP +.SH FORMAT +The \fIformat\fP option controls how lines are read from the file, and +which fields are mapped to which RADIUS attributes. +.PP +The key field is the field being searched for within the file. It is +normally signified by being preceded with a '*' character, which +indicates that the field has only one key, like the /etc/passwd file. +The key field may instead be preceded with '*,', which indicates that +the field has multiple possible comma-separated keys, such as when +searching the /etc/group file. +.PP +The other fields signify RADIUS attributes. By default they will be +added as a control attribute list. +.PP +To add an attribute to the RADIUS request (as though it had been sent +by the NAS), prefix the attribute name in the "format" string with the +\(aq~' character. +.PP +To add an attribute to the RADIUS reply (to be sent back to the NAS), +prefix the attribute name in the "format" string with the '=' +character. +.PP +.SH EXAMPLES +.DS +format = "*User-Name:Crypt-Password:" +.DE +.IP +For a file the looks similar to /etc/passwd. The first field, +User-Name, is the key to look up in the file. When the record is +found, a control attribute, 'Crypt-Password', will be added with the +contents of the second field. (Note this will not work with shadow +passwords.) +.PP +.DS +format = "My-Group:::*,User-Name" +.DE +.IP +Parse a file similar to the /etc/group file. An entry matches a +request when the name in a User-Name attribute exists in the +comma-separated list of a line in the file. When an entry matches, +a "My-Group" attribute will be created and added to the control +items for the request. The value of that attribute will be taken from +the first field of the matching line in the file. +.IP +The ":::" in the format string means that there are extra two fields +in the line, in between the group name and list of user names. Those +fields do not map to any RADIUS attribute, and are therefore ignored. +.IP +For this example to work in practice, you will have to add the +My-Group attribute to the dictionary file. See \fIdictionary(5)\fP +for details on how this may be done. +.PP +.DS +format = "~My-Group:::*,User-Name" +.DE +.IP +Similar to the previous entry, except the My-Group attribute is added +to the request, as though it was sent by the NAS. +.PP +.SH SECTIONS +.BR authorize +.PP +.SH FILES +.I /etc/raddb/mods-available/passwd +.PP +.SH "SEE ALSO" +.BR radiusd (8), +.BR radiusd.conf (5), +.BR radmin (8), +.BR dictionary (5), +.BR rlm_unix (5) +.SH AUTHOR +Alan DeKok <aland@freeradius.org>, Matthew Newton +<matthew@newtoncomputing.co.uk>. + diff --git a/man/man5/rlm_realm.5 b/man/man5/rlm_realm.5 new file mode 100644 index 0000000..8b8237a --- /dev/null +++ b/man/man5/rlm_realm.5 @@ -0,0 +1,94 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH rlm_realm 5 "14 March 2004" "" "FreeRADIUS Module" +.SH NAME +rlm_realm \- FreeRADIUS Module +.SH DESCRIPTION +The \fIrlm_realm\fP module parses the User-Name attribute into a +User section and a Realm section. This is used primarily in a +proxy situation, however, Realms can also be used locally to provide +different service profiles based on the Realm being used. +.PP +The main configuration items to be aware of are: +.IP format +This can be either 'prefix' or 'suffix'. It specifies whether the +Realm is before or after the User portion in the User-Name string. +.IP delimiter +A single character in quotes, which is used as the delimiting +character that separates the Realm and User sections of the string. +.IP ignore_default +This is set to either 'yes' or 'no'. If set to 'yes', this will +prevent the module instance from matching a realm against the DEFAULT +entry. This may be useful if you have multiple realm module instances. +The default is 'no'. +.IP ignore_null +This is set to either 'yes' or 'no'. If set to 'yes', this will +prevent the module instance from matching a realm against the NULL +entry. This may be useful if you have multiple realm module instances. +The default is 'no'. +.PP +This module parses the realm from the User-Name attribute according +to the instance configuration, and then performs a lookup to find a +matching realm in the '/etc/raddb/proxy.conf' file. Depending on the +configuration of the Realm as matched in the file, the username may +be rewritten in a 'stripped' format, or with the Realm portion +removed. In either case, a Realm attribute is created and added to +the packet on a match, which can be used by other modules. +.SH CONFIGURATION +.PP +.DS +modules { + ... stuff here ... +.br +.br + # useranme@realm syntax +.br + realm suffix { +.br + format = suffix +.br + delimiter = "@" +.br + } +.br +.br + # realm/username syntax +.br + realm prefix { +.br + format = prefix +.br + delimiter = "/" +.br + } +.br +.br + ... stuff here ... +.br +} +.DE +.PP +.SH SECTIONS +.BR authorization, +.BR pre-accounting +.PP +.SH FILES +.I /etc/raddb/radiusd.conf, +.I /etc/raddb/proxy.conf +.PP +.SH "SEE ALSO" +.BR radiusd (8), +.BR radiusd.conf (5), +.BR proxy.conf (5) +.SH AUTHORS +Chris Parker, cparker@segv.org diff --git a/man/man5/rlm_sql.5 b/man/man5/rlm_sql.5 new file mode 100644 index 0000000..f0c42b5 --- /dev/null +++ b/man/man5/rlm_sql.5 @@ -0,0 +1,152 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH rlm_sql 5 "5 February 2004" "" "FreeRADIUS Module" +.SH NAME +rlm_sql \- FreeRADIUS Module +.SH DESCRIPTION +The \fIrlm_sql\fP module provides an SQL interface to retrieve +authorization information and store accounting information. It can be +used in conjunction with, or in lieu of the files and detail modules. +The SQL module has drivers to support the following SQL databases: +.PP +.DS +.br + db2 +.br + iodbc +.br + mysql +.br + oracle +.br + postgresql +.br + sybase +.br + unixodbc +.br +.DE +.PP +Due to the size of the configuration variables, the sql module is +usually configured in a separate file, which is included in the main +radiusd.conf via an include directive. +.PP +The main configuration items to be aware of are: +.IP driver +This variable specifies the driver to be loaded. +.IP server +.IP login +.IP password +These specify the servername, username, and password the module will +use to connect to the database. +.IP radius_db +The name of the database where the radius tables are stored. +.IP acct_table1 +.IP acct_table2 +These specify the tables names for accounting records. acct_table1 +specifies the table where Start records are stored. acct_table2 +specifies the table where Stop records are stored. In most cases, +this should be the same table. +.IP postauth_table +The name of the table to store post-authentication data. +.IP authcheck_table +.IP authreply_table +The tables where individual Check-Items and Reply-Items are stored. +.IP groupcheck_table +.IP groupreply_table +The tables where group Check-Items and Reply-Items are stored. +.IP usergroup_table +The table where username to group relationships are stored. +.IP deletestalesessions +This option is set to 'yes' or 'no'. If you are doing +Simultaneous-Use checking, and this is set to yes, stale sessions ( +defined as sessions for which a Stop record was not received ) will be +cleared. +.IP logfile +This option is useful for debugging sql problems. If logfile is set +then all sql queries for the containing section are written to the +file specified. This is useful for debugging and bulk inserts. +.IP num_sql_socks +The number of sql connections to make to the database. +.IP connect_failure_retry_delay +The number of seconds to wait before attempting to reconnect to a +failed database connection. +.IP sql_user_name +This is the definition of the SQL-User-Name attribute. This is set +once, so that you can use %{SQL-User-Name} in the SQL queries, rather +than the nested username substitution. This ensures that Username is +parsed consistently for all SQL queries executed. +.IP default_user_profile +This is the default profile name that will be applied to all users if +set. This is not set by default. +.IP query_on_not_found +This option is set to 'yes' or 'no'. If set to yes, then the default +user profile is returned if no specific match was found for the user. +.IP authorize_check_query +.IP authorize_reply_query +These queries are run during the authorization stage to extract the +user authorization information from the ${authcheck_table} and +${authreply_table}. +.IP authorize_group_check_query +.IP authorize_group_reply_query +These queries are run during the authorization stage to extract the +group authorization information from the ${groupcheck_table} and +${groupreply_table}. +.IP accounting_onoff_query +The query to be run when receiving an Accounting On or Accounting Off +packet. +.IP accounting_update_query +.IP accounting_update_query_alt +The query to be run when receiving an Accounting Update packet. If the +primary query fails, the alt query is run. +.IP accounting_start_query +.IP accounting_start_query_alt +The query to be run when receiving an Accounting Start packet. If the +primary query fails, the alt query is run. +.IP accounting_stop_query +.IP accounting_stop_query_alt +The query to be run when receiving an Accounting Stop packet. If the +primary query fails, the alt query is run. +.IP simul_count_query +The query to be run to return the number simultaneous sessions for the +purposes of limiting Simultaneous Use. +.IP simul_verify_query +The query to return the detail information needed to confirm that all +suspected connected sessions are valid, and are not stale sessions. +.IP group_membership_query +The query to run to check user group membership. +.IP postauth_query +The query to run during the post-authentication stage. +.SH CONFIGURATION +.PP +Due to the size of the configuration for this module, it is not +included in this manual page. Please review the supplied +configuration files for example queries and configuration details. +.SH SECTIONS +.BR authorization, +.BR accounting, +.BR checksimul, +.BR post-authentication +.PP +.SH FILES +.I /etc/raddb/radiusd.conf, +.I /etc/raddb/sql.conf, +.I /etc/raddb/sql/<DB>/dialup.conf, +.I /etc/raddb/sql/<DB>/schema.sql, +.BR +.PP +.SH "SEE ALSO" +.BR radiusd (8), +.BR radiusd.conf (5), +.SH AUTHORS +Chris Parker, cparker@segv.org diff --git a/man/man5/rlm_unbound.5 b/man/man5/rlm_unbound.5 new file mode 100644 index 0000000..34cff92 --- /dev/null +++ b/man/man5/rlm_unbound.5 @@ -0,0 +1,82 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH rlm_unbound 5 "8 July 2013" "" "FreeRADIUS Module" +.SH NAME +rlm_unbound \- FreeRADIUS Module +.SH DESCRIPTION +Each instance of \fIrlm_unbound\fP provides an embedded DNS client +for performing DNS lookups. Each instance may be configured separately +to query different DNS horizons, change DNSSEC options, etc. +.PP +The module is primarily intended for use by other modules through +internal APIs, and so, instances should be initialized earlier than +those modules which use them. Each instance does also provide some +xlat functionalities for general use and for troubleshooting. +.PP +Each instance of rlm_unbound may take the following parameters: +.IP filename +This file must exist and must point to a valid libunbound configuration file. +The default is ${raddbdir}/mods-config/unbound/default.conf. +.IP timeout +While libunbound provides an asyncronous API for internal use, using any xlat +is done syncronously from the perspective of unlang. This value limits the +amount of time a request will wait for DNS to respond, after which the xlat +will fail. The default is 3000 milliseconds. This setting is independent of +any libunbound configuration values. +.IP resolvconf +Full path of a resolv.conf file to load resolver details from. If this is +not set then libunbound will query root DNS servers. +.IP hosts +Full path of a hosts file to load. This provides a mechanism for local +overrides to names which would otherwise not resolve or need different +results to those which a DNS resolution would provide. +.PP +An instance named, for example, "dns" will provide the following xlat +functionalities: +.IP %{dns-a:<owner>} +Performs an A lookup for the owner name, returning a stringified IPv4 +address. Only the first A record in the RRSET will be returned. +.IP %{dns-aaaa:<owner>} +Performs an AAAA lookup for the owner name, returning a stringified IPv6 +address. Only the first AAAA record in the RRSET will be returned. +.IP %{dns-ptr:<owner>} +Performs a PTR lookup for the owner. +.PP +.SH CAVEATS +Logging from rlm_unbound can be problematic, especialy if more than one +instantiation of the module is used. This is due to the need for additional +features in the underlying libunbound which hopefully will be enhanced over +time. +.PP +There is a potential for a FreeRADIUS server using rlm_unbound to either +fail to terminate cleanly (leaving zombie processes, failing to clean up +other modules, and hanging after a SIGTERM until a SIGKILL is sent) or +to fail valgrind checks during termination when run with -m. Likewise this +problem will rely on upstream enhancements before it can be fixed, and the +exact behavior may change in interim releases until then. +.PP +The logging behavior of rlm_unbound may vary depending on whether +FreeRADIUS is compiled with support for threads. +.PP +.SH FILES +.I /etc/raddb/modules-available/rlm_unbound +.I /etc/raddb/modules-config/unbound/ +.PP +.SH "SEE ALSO" +.BR radiusd (8), +.BR radiusd.conf (5) +.BR libunbound (3) +.BR unbound.conf (5) +.SH AUTHOR +Brian S. Julin, bjulin@clarku.edu + diff --git a/man/man5/rlm_unix.5 b/man/man5/rlm_unix.5 new file mode 100644 index 0000000..38668e0 --- /dev/null +++ b/man/man5/rlm_unix.5 @@ -0,0 +1,66 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH rlm_unix 5 "17 February 2005" "" "FreeRADIUS Module" +.SH NAME +rlm_unix \- FreeRADIUS Module +.SH DESCRIPTION +The \fIrlm_unix\fP module reads crypt(3) passwords from the system +password file, and allows the server to use them for authentication. +The module also provides FreeRADIUS an interface into a radwtmp file +(used by "radlast") when added to the accounting section. +.PP +The \fIrlm_unix\fP module should be listed in the +"authenticate" section. Please see the default \fIradiusd.conf\fP +shipped with the server for an example of the correct usage of this +module. +.PP +As of FreeRADIUS 1.1.0, the module no longer reads, or caches +/etc/passwd, /etc/shadow, or /etc/group. If you wish to cache those +files, see \fIrlm_passwd\fP. Most, if not all, configurations should +not need those files to be cached. +.PP +The main configuration items to be aware of are: +.IP radwtmp +The path to the system wtmp file to be used for keeping the database +of online users as read by the 'radlast' program. +.SH CONFIGURATION +.PP +.DS +modules { + ... +.br + unix { +.br + radwtmp = ${logdir}/radwtmp +.br + } +.br + ... +.br +} +.DE +.PP +.SH SECTIONS +.BR authentication, +.BR accounting +.PP +.SH FILES +.I /etc/raddb/radiusd.conf, +.PP +.SH "SEE ALSO" +.BR radiusd (8), +.BR radiusd.conf (5), +.BR rlm_passwd (5), +.BR radlast (1) +.SH AUTHORS +Chris Parker, cparker@segv.org diff --git a/man/man5/unlang.5 b/man/man5/unlang.5 new file mode 100644 index 0000000..63f5570 --- /dev/null +++ b/man/man5/unlang.5 @@ -0,0 +1,900 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH unlang 5 "16 February 2021" "" "FreeRADIUS Processing un-language" +.SH NAME +unlang \- FreeRADIUS Processing un\-language +.SH DESCRIPTION +FreeRADIUS supports a simple processing language in its configuration +files. We call it an "un-language" because the intention is NOT to +create yet another programming language. If you need something more +complicated than what is described here, we suggest using the Perl or +Python modules rlm_perl, or rlm_python. + +The goal of the language is to allow simple policies to be written +with minimal effort. Those policies are then applied when a request +is being processed. Requests are processed through virtual servers +(including the default one), in the sections titled "authorize", +"authenticate", "post-auth", "preacct", "accounting", "pre-proxy", +"post-proxy", and "session". + +These policies cannot be used in any other part of the configuration +files, such as module or client configuration. +.SH KEYWORDS +The keywords for the language are a combination of pre-defined +keywords, and references to loadable module names. We document only +the pre-defined keywords here. + +Subject to a few limitations described below, any keyword can appear +in any context. The language consists of a series of entries, each +one line. Each entry begins with a keyword. Entries are +organized into lists. Processing of the language is line by line, +from the start of the list to the end. Actions are executed +per-keyword. +.IP module-name[.section-name] +A reference to the named module. When processing reaches this point, +the pre-compiled module is called. The module may succeed or fail, +and will return a status to "unlang" if so. This status can be tested +in a condition. See the "Simple Conditions" text in the CONDITIONS +section, and MODULE RETURN CODES, below. +If a section-name is provided, it will cause the module to execute +as if it were listed in the named section. + +.DS + chap # call the CHAP module +.br + sql # call the SQL module +.br + ... +.DE +.IP if +.br +Checks for a particular condition. If true, the block after the +condition is processed. Otherwise, the block is ignored. See +CONDITIONS, below, for documentation on the format of the conditions. + +.DS + if (condition) { +.br + ... +.br + } +.DE +.IP else +.br +Define a block to be executed only if the previous "if" condition +returned false. + +.DS + else { +.br + ... +.br + } +.DE +.IP elsif +.br +Define a block to be executed only if the previous "if" condition +returned false, and if the specified condition evaluates to true. + +.DS + elsif (condition) { +.br + ... +.br + } +.DE +.IP foreach +.br +Loops over values of an attribute, running the block for each value. +The return value of the block is the return value of the last +statement executed. The loop can be exited early by using the "break" +keyword. Unlike other languages, "break" here means "exit the loop at +the next iteration", not "exit the loop now". The result is that any +statements after the "break" keyword will still be executed. We +recommend using "break" only when it is the last statement in a +"foreach" block. + +Inside of the "foreach" block, the attribute which is being looped +over can be referenced as "Foreach-Variable-#". Where "#" is the +depth of the loop, starting at "0". e.g. "Foreach-Variable-0". The +loops can be nested up to eight (8) deep, though this is not +recommended. + +.DS + foreach &Attribute-Reference { +.br + ... +.br + } +.DE +.IP switch +.br +A "switch" statement takes one argument, and contains a series of +"case" statements. When a "switch" statement is encountered, the +argument from the "switch" is evaluated in turn against the argument +from each "case" statement. The first "case" statement which matches +is executed. All other "case" statements are ignored. A default +"case" statement can be defined, by omitting its argument. + +If the argument is a double quoted string (e.g. "%{exec:1 + 2}", it is +expanded as described in the DATA TYPES section, below. The match is +then performed on the string returned from the expansion. If the +argument is an attribute reference (e.g. &User-Name), then the match +is performed on the value of that attribute. Otherwise, the argument +is taken to be a literal string, and matching is done via simple +comparison. + +No statement other than "case" can appear in a "switch" block. + +.DS + switch <argument> { +.br + ... +.br + } +.DE +.IP case +.br +Provides a place-holder which matches the argument of a parent +"switch" statement. + +A "case" statement cannot appear outside of a "switch" block. + +If the argument is a double quoted string (e.g. "%{exec:1 + 2}", it is +expanded as described in the DATA TYPES section, below. The match is +then performed on the string returned from the expansion. If the +argument is an attribute reference (e.g. &User-Name), then the match +is performed on the value of that attribute. Otherwise, the argument +is taken to be a literal string, and matching is done via simple +comparison. + +.DS + case <argument> { +.br + ... +.br + } +.DE +A default entry can be defined by omitting the argument, as given +below. This entry will be used if no other "case" entry matches. +Only one default entry can exist in a "switch" section. + +.DS + case { +.br + ... +.br + } +.DE +.IP update +.br +Update a particular attribute list, based on the attributes given in +the current block. + +.DS + update <list> { +.br + &Attribute-Reference = value +.br + ... +.br + } +.DE +The <list> can be one of "request", "reply", "proxy-request", +"proxy-reply", "coa", "disconnect", "session-state", or "control". As +of Version 3, the <list> can be omitted, in which case "request" is +assumed. + +The "control" list is the list of attributes maintained internally by +the server that controls how the server processes the request. Any +attribute that does not go in a packet on the network will generally +be placed in the "control" list. + +For EAP methods with tunneled authentication sessions (i.e. PEAP and +EAP-TTLS), the inner tunnel session can also reference +"outer.request", "outer.reply", and "outer.control". Those references +allow you to address the relevant list in the outer tunnel session. + +The "coa" and "disconnect" sections can only be used when the server +receives an Access-Request or Accounting-Request. Use "request" and +"reply" instead of "coa" when the server receives a CoA-Request or +Disconnect-Request packet. + +Adding one or more attributes to either of the "coa" or "disconnect" +list causes server to originate a CoA-Request or Disconnect-Request +packet. That packet is sent when the current Access-Request or +Accounting-Request has been finished, and a reply sent to the NAS. +See raddb/sites-available/originate-coa for additional information. + +The "session-state" list is primarily used for EAP. Attributes put +into the "session-state" list are saved for the next packet in the +session. They are automatically retrieved when the next packet is +received. + +The only contents permitted in an "update" section are attributes and +values. The contents of the "update" section are described in the +ATTRIBUTE REFERENCE and ATTRIBUTE ASSIGNMENT sections below. +.IP redundant +This section contains a simple list of modules. The first module is +called when the section is being processed. If the first module +succeeds in its operation, then the server stops processing the +section, and returns to the parent section. + +If, however, the module fails, then the next module in the list is +tried, as described above. The processing continues until one module +succeeds, or until the list has been exhausted. + +Redundant sections can contain only a list of modules, and cannot +contain keywords that perform conditional operations (if, else, etc) +or update an attribute list. + +.DS + redundant { +.br + sql1 # try this +.br + sql2 # try this only if sql1 fails. +.br + ... +.br + } +.DE +.IP load-balance +This section contains a simple list of modules. When the section is +entered, one module is chosen at random to process the request. All +of the modules in the list should be the same type (e.g. ldap or sql). +All of the modules in the list should behave identically, otherwise +the load-balance section will return different results for the same +request. + +Load-balance sections can contain only a list of modules, and cannot +contain keywords that perform conditional operations (if, else, etc) +or update an attribute list. + +.DS + load-balance { +.br + ldap1 # 50% of requests go here +.br + ldap2 # 50% of requests go here +.br + } +.DE +In general, we recommend using "redundant-load-balance" instead of +"load-balance". +.IP redundant-load-balance +This section contains a simple list of modules. When the section is +entered, one module is chosen at random to process the request. If +that module succeeds, then the server stops processing the section. +If, however, the module fails, then one of the remaining modules is +chosen at random to process the request. This process repeats until +one module succeeds, or until the list has been exhausted. + +All of the modules in the list should be the same type (e.g. ldap or +sql). All of the modules in the list should behave identically, +otherwise the load-balance section will return different results for +the same request. + +Load-balance sections can contain only a list of modules, and cannot +contain keywords that perform conditional operations (if, else, etc) +or update an attribute list. Please see raddb/radiusd.conf +"instantiate" section for more configuration examples. + +.DS + redundant-load-balance { +.br + ldap1 # 50%, unless ldap2 is down, then 100% +.br + ldap2 # 50%, unless ldap1 is down, then 100% +.br + } +.DE +.IP return +.br +Returns from the current top-level section, e.g. "authorize" or +"authenticate". This keyword is mainly used to avoid layers of nested +"if" and "else" statements. + +.DS + authorize { +.br + if (...) { +.br + ... +.br + return +.br + } +.br + ... # this is never reached when the "if" +.br + ... # statement is executed +.br + } +.DE +.SH ATTRIBUTE REFERENCES + +Attributes may be referenced via the following syntax: +.DS + &Attribute-Name + &Attribute-Name:TAG + &Attribute-Name[NUM] + &<list>:Attribute-Name + &<list>:Attribute-Name:TAG[NUM] +.DE +Where <list> is one of "request", "reply", "control", "proxy-request", +"proxy-reply", or "outer.request", "outer.reply", "outer.control", +"outer.proxy-request", or "outer.proxy-reply". just as with the +"update" section, above. The "<list>:" prefix is optional, and if +omitted, is assumed to refer to the "request" list. + +The TAG portion is a decimal integer between 1 and 31. Please see RFC +2868 for more information about tags. Tags can only be used for +attributes which are marked in the dictionary as "has_tag". + +The NUM portion is used when there are multiple attributes of the same +name in a list. The "Attribute-Name" reference will return the first +attribute. Using an array offset allows the policy to refer to the +second and subsequent attributes. + +If '*' is used in the NUM portion, it evaluates to all instances of +the attribute in the request. + +If 'n' is used in the NUM portion, it evaluates to the last instance +of the attribute in the request. + +When an attribute name is encountered, the given list is examined for +an attribute of the given name. Some examples are: +.DS + User-Name +.br + request:User-Name # same as above +.br + reply:User-Name +.br + Tunnel-Password:1 +.br + Cisco-AVPAir[2] +.br + outer.request:User-Name # from inside of a TTLS/PEAP tunnel +.DE +Note that unlike C, there is no way to define new attributes at +run-time. They MUST be declared in a dictionary file, and loaded when +the server starts. + +All attributes are defined in the dictionaries that accompany the +server. These definitions define only the name and type, and do not +define the value of the attribute. When the server receives a packet, +it uses the packet contents to look up entries in the dictionary, and +instantiates attributes with a name taken from the dictionaries, and a +value taken from the packet contents. This process means that if an +attribute does not exist, it is usually because it was not contained +in a packet that the server received. + +Once the attribute is instantiated, it is added to a list. It can +then be referenced, updated, replaced, etc. + +.SH CONDITIONS +The conditions are similar to C conditions in syntax, though +quoted strings are supported, as with the Unix shell. +.IP Simple +conditions +.br +.DS + (foo) +.DE +Evaluates to true if 'foo' is a non-empty string (single quotes, double +quotes, or back-quoted). Also evaluates to true if 'foo' is a +non-zero number. Note that the language is poorly typed, so the +string "0000" can be interpreted as a numerical zero. This issue can +be avoided by comparing strings to an empty string, rather than by +evaluating the string by itself. + +If the word 'foo' is not a quoted string, then it can be taken as a +reference to a named attribute. See "Referencing attribute lists", +below, for examples of attribute references. The condition evaluates +to true if the named attribute exists. + +Otherwise, if the word 'foo' is not a quoted string, and is not an +attribute reference, then it is interpreted as a reference to a module +return code. The condition evaluates to true if the most recent +module return code matches the name given here. Valid module return +codes are given in MODULE RETURN CODES, below. +.IP Negation +.DS + (!foo) +.DE +Evaluates to true if 'foo' evaluates to false, and vice-versa. +.PP +Short-circuit operators +.RS +.br +.DS + (foo || bar) +.br + (foo && bar) +.DE +"&&" and "||" are short-circuit operators. "&&" evaluates the first +condition, and evaluates the second condition if and only if the +result of the first condition is true. "||" is similar, but executes +the second command if and only if the result of the first condition is +false. +.RE +.IP Comparisons +.DS + (foo == bar) +.DE +Compares 'foo' to 'bar', and evaluates to true if the comparison holds +true. Valid comparison operators are "==", "!=", "<", "<=", ">", +">=", "=~", and "!~", all with their usual meanings. The operators +":=", "^=" and "=" are assignment operators, and are not allowed for +comparisons. + +The operators "<", "<=", ">", and ">=" are also allowed for checking +that an IP address is contained within a network. For example: +.DS + if (<ipaddr>192.0.2.1 < 192.0.2.0/24) { +.DE +This comparison succeeds, because the address 192.0.2.1 is contained +within the network 192.0.2.0/24. +.RE +.IP "Attribute Comparisons" +When doing attribute comparisons, the data type of the attribute is +used to determine the data type of the right-hand side argument. +.DS + (&User-Name == "foo") +.DE +Compares the value of the User-Name attribute to the string 'foo', and +evaluates to true if the comparison holds true. + +Similarly, +.DS + (&Framed-IP-Address == 192.0.2.1) +.DE +Compares the value of the Framed-IP-Address attribute to the IP +address 192.0.2.1. This IP address does not need to be quoted. +.RE +.IP "Inter-Attribute Comparisons" +.DS + (&User-Name == &Filter-Id) +.DE +Compares the value of the User-Name attribute to the contents of the +Filter-Id attribute, and evaluates to true if the comparison holds +true. Unlike the previous example, this comparison is done in a +type-safe way. For example, comparing the IP addresses 1.2.3.4 and +127.0.0.1 as strings will return different results than comparing them +as IP addresses. + +The "&" character in the condition means that the comparison "refers" +to the Filter-Id attribute. If left off, it means that the User-Name +attribute is compared to the literal string "Filter-Id". + +Where the left-hand side is an attribute, the "&" can be omitted. +However, it is allowed for backwards compatibility. e.g. The comparison +"(&User-Name == &Filter-Id)" is equivalent to the example above. + +We recommend using attribute references instead of printing +attributes to a string, e.g. (User-Name == "%{Filter-Id}"). +Attribute references will be faster and more efficient. + +The conditions will check only the first occurrence of an attribute. +If there is more than one instance of an attribute, the following +syntax should be used: + +.DS + (&Attribute-Name[*] == "foo") +.DE +Using the "[*]" syntax means that it checks all of the instances of +the named attribute. If one attribute matches, the condition +succeeds. If none match, the condition fails. + +.RE +.IP Casts +.DS + (<type>foo == bar) +.DE +The left-hand-side of a condition can be "cast" to a specific data +type. The data type must be one which is valid for the dictionaries. +e.g. "integer", "ipaddr", etc. + +The comparison is performed in a type-safe way, as with +"Inter-Attribute Comparisons", above. Both sides of the condition are +parsed into temporary attributes, and the attributes compared via +type-specific methods. The temporary attributes have no other effect, +and are not saved anywhere. + +Casting allows conditions to perform type-specific comparisons. In +previous versions of the server, the data would have to be manually +placed into an intermediate attribute (or attributes), and then the +attribute (or attributes) compared. The use of a cast allows for +simpler policies. + +Casts are allowed only on the left-hand side argument of a condition. +.PP +Conditions may be nested to any depth, subject only to line length +limitations (8192 bytes). +.SH DATA TYPES +There are only a few data types supported in the language. Reference +to attributes, numbers, and strings. Any data type can appear in +stand-alone condition, in which case they are evaluated as described +in "Simple conditions", above. They can also appear (with some +exceptions noted below) on the left-hand or on the right-hand side of +a comparison. +.IP numbers +Numbers are composed of decimal digits. Floating point, hex, and +octal numbers are not supported. The maximum value for a number is +machine-dependent, but is usually 32-bits, including one bit for a +sign value. +.PP +word +.RS +Text that is not enclosed in quotes is interpreted differently +depending on where it occurs in a condition. On the left hand side of +a condition, it is interpreted as a reference to an attribute. On the +right hand side, it is interpreted as a simple string, in the same +manner as a single-quoted string. + +Using attribute references permits limited type-specific comparisons, +as seen in the examples below. + +.DS + if (&User-Name == "bob") { +.br + ... +.br + if (&Framed-IP-Address > 127.0.0.1) { +.br + ... +.br + if (&Service-Type == Login-User) { +.DE +.RE +.IP """strings""" +.RS +Double-quoted strings are expanded by inserting the value of any +attributes (see ATTRIBUTE REFERENCES, below) before being evaluated. If +the result is a number it is evaluated in a numerical context. + +String length is limited by line-length, usually about 8000 +characters. A double quote character can be used in a string via +the normal back-slash escaping method. ("like \\"this\\" !") +.RE +.IP 'strings' +Single-quoted strings are evaluated as-is. Their values are not +expanded as with double-quoted strings above, and they are not +interpreted as attribute references. +.IP `strings` +Back-quoted strings are evaluated by expanding the contents of the +string, as described above for double-quoted strings. The resulting +command given inside of the string in a sub-shell, and taking the +output as a string. This behavior is much the same as that of Unix +shells. + +Note that for security reasons, the input string is split into command +and arguments before string expansion is done. + +For performance reasons, we suggest that the use of back-quoted +strings be kept to a minimum. Executing external programs is +relatively expensive, and executing a large number of programs for +every request can quickly use all of the CPU time in a server. If you +believe that you need to execute many programs, we suggest finding +alternative ways to achieve the same result. In some cases, using a +real language may be sufficient. + +.IP /regex/im +These strings are valid only on the right-hand side of a comparison, +and then only when the comparison operator is "=~" or "!~". They are +regular expressions, as implemented by the local regular expression +library on the system. This is usually Posix regular expressions. + +The trailing 'i' is optional, and indicates that the regular +expression match should be done in a case-insensitive fashion. + +The trailing 'm' is also optional, and indicates that carrot '^' +and dollar '$' anchors should match on new lines as well as at the +start and end of the subject string. + +If the comparison operator is "=~", then parentheses in the regular +expression will define variables containing the matching text, as +described below in the ATTRIBUTE REFERENCES section. +.SH EXPANSIONS +Attributes are expanded using the ATTRIBUTE REFERENCE syntax +described above, and surrounding the reference with "%{...}" + +.DS + %{Attribute-Reference} +.DE + +The result will be a string which contains the value of the attribute +which was referenced, as a printable string. If the attribute does +not exist, the result will be an empty string. +.PP +Results of regular expression matches +.RS +If a regular expression match has previously been performed, then the +special variable %{0} will contain a copy of the matched portion of +the input string. The variables %{1} through %{32} will contain the +substring matches, starting from the left-most capture group, onwards. +If there are more than 32 capture groups, the additional results will +not be accessible. +If the server is built with libpcre, the results of named capture groups +are available using the "%{regex:capture group}" expansion. They will +also be accessible using the variables described above. +Every time a regular expression is evaluated, whether it matches or not, +the capture group values will be cleared. +.RE +.PP +Obtaining results from databases +.RS +It is useful to query a database for some information, and to use the +result in a condition. The following syntax will call a module, pass +it the given string, and replace the string expansion with the +resulting string returned from the module. + +.DS + %{module: string ...} +.DE + +The syntax of the string is module-specific. Please read the module +documentation for additional details. +.RE +.PP +Conditional Syntax +.RS +Conditional syntax similar to that used in Unix shells may also be +used. +.IP %{%{Foo}:-bar} +If %{Foo} has a value, returns that value. +.br +Otherwise, returns literal string "bar". +.IP %{%{Foo}:-%{Bar}} +If %{Foo} has a value, returns that value. +.br +Otherwise, returns the expansion of %{Bar}. + +These conditional expansions can be nested to almost any depth, such +as with %{%{One}:-%{%{Two}:-%{Three}}} +.RE +.PP +String lengths and arrays +.RS +Similar to a Unix shell, there are ways to reference string lengths, +and the second or more instance of an attribute in a list. If you +need more than this functionality, we suggest using a real language. +.IP %{strlen:string} +The number of characters in "string". If "string" does not exist, +then the length also does not exist, instead of being zero. + +The "string" is expanded before the length is taken. + +.IP %{integer:Attribute-Name} +The integer value of the Attribute-Name, instead of the enumerated +name. + +e.g. If a request contains "Service-Type = Login-User", the expansion +of %{integer:Service-Type} will yield "1". + +.IP %{hex:Attribute-Name} +The hex value of the Attribute-Name, as a series of hex digits. + +e.g. If a request contains "Framed-IP-Address = 127.0.0.1", the expansion +of %{hex:Framed-IP-Address} will yield "0x7f000001". + +.IP %{Attribute-Name[#]} +The number of instances of Attribute-Name. + +e.g. If a request contains "User-Name = bob", the expansion +of %{User-Name[#]} will yield "1". + +.IP %{Attribute-Name[*]} +All values of Attribute-Name, concatenated together with ',' as the +separator. + +.IP %{List-Name:[#]} +The number of attributes in the named list. + +.IP %{List-Name:[*]} +All values of attributes in the named-list, concatenated together with ',' +as the separator. Use the %{pairs:} xlat to get a list of attributes and +values. + +e.g. If a response contains "Reply-Message = 'Hello', Reply-Message = 'bob' +the expansion of "%{reply:Reply-Message[*]} will yield "Hello\\nbob" + +.SH ATTRIBUTE ASSIGNMENTS +The attribute lists described above may be edited by listing one or +more attributes in an "update" section. Once the attributes have been +defined, they may be referenced as described above in the ATTRIBUTE +REFERENCES section. + +The following syntax defines attributes in an "update" section. Each +attribute and value has to be all on one line in the configuration +file. There is no need for commas or semi-colons after the value. + +.DS + Attribute-Reference = value +.DE +.PP +Attribute Reference +.RS +The Attribute-Reference must be a reference (see above), using a name +previously defined in a dictionary. If an undefined name is used, the +server will return an error, and will not start. + +.RE +.IP Operators +The operator used to assign the value of the attribute may be one of +the following, with the given meaning. +.RS +.IP = +Add the attribute to the list, if and only if an attribute of the same +name is not already present in that list. +.IP := +Add the attribute to the list. If any attribute of the same name is +already present in that list, its value is replaced with the value of +the current attribute. +.IP += +Add the attribute to the tail of the list, even if attributes of the +same name are already present in the list. When the right hand side +of the expression resolves to multiple values, it means add all values +to the tail of the list. +.IP ^= +Add the attribute to the head of the list, even if attributes of the +same name are already present in the list. When the right hand side +of the expression resolves to multiple values, it means prepend all +values to the head of the list. +.RE +.PP +Enforcement and Filtering Operators +.RS +The following operators may also be used in addition to the ones +listed above. Their function is to perform enforcement or filtering +on attributes in a list. +.IP -= +Remove all matching attributes from the list. Both the attribute name +and value have to match in order for the attribute to be removed from +the list. +.IP == +Keep all matching attributes. Both the attribute name and value have +to match in order for the attribute to remain in the list. + +Note that this operator is very different than the '=' operator listed +above! +.IP != +Keep all attributes with matching name, and value not equal to the +given one. +.IP < +Keep all attributes having values less than the value +given here. Any larger value is replaced by the value given here. If +no attribute exists, it is added with the value given here, as with +"+=". +.IP <= +Keep all attributes having values less than, or equal to, the value +given here. Any larger value is replaced by the value given here. If +no attribute exists, it is added with the value given here, as with +"+=". +.IP > +Keep all attributes having values greater than the value +given here. Any smaller value is replaced by the value given here. If +no attribute exists, it is added with the value given here, as with +"+=". +.IP >= +Keep all attributes having values greater than, or equal to, the value +given here. Any smaller value is replaced by the value given here. If +no attribute exists, it is added with the value given here, as with +"+=". +.IP !* +Delete all occurrences of the named attribute, no matter what the +value. +.IP =~ +Keep all attributes having values which match the given regular +expression. If no attribute matches, nothing else is done. +.IP !~ +Keep all attributes having values which fail to match the given +regular expression. If no attribute matches, nothing else is done. +.RE +.IP Values +.br +The value can be an attribute reference, or an attribute-specific +string. + +When the value is an attribute reference, it must take the form of +"&Attribute-Name". The leading "&" signifies that the value is a +reference. The "Attribute-Name" is an attribute name, such as +"User-Name" or "request:User-Name". When an attribute reference is +used, both attributes must have the same data type. For example, +"User-Name := &NAS-Port" is invalid, because "User-Name" is a string, +and "NAS-Port" is an integer. + +We recommend using the form "Attribute-1 = &Attribute-2" for updates, +instead of "Attribute-1 = "%{Attribute-2}". The first version will +copy the attribute data, no matter what its form. The second +version will print the Attribute-2 to a string, and then parse it to +create the value for Attribute-1. This second version is slower +and more fragile than the first one. + +When the value is an attribute-specific string, it can be a string, +integer, IP address, etc. The value may be expanded as described +above in the DATA TYPES section, above. For example, specifying +"Framed-IP-Address = 127.0.0.1" will cause the "Framed-IP-Address" +attribute to be set to the IP address "127.0.0.1". However, using +"Framed-IP-Address := \"%{echo: 127.0.0.1}\"" will cause the "echo" +module to be run with a string "127.0.0.1". The output of the "echo" +module will then be parsed as an IP address, and placed into the +Framed-IP-Address attribute. + +This flexibility means that you can assign an IP address by specifying +it directly, or by having the address returned from a database query, +or by having the address returned as the output of a program that is +executed. + +When string values are finally assigned to an attribute, they can have a +maximum length of 253 characters. This limit is due in part to both +protocol and internal server requirements. That is, the strings in +the language can be nearly 8k in length, say for a long SQL query. +However, the output of that SQL query should be no more than 253 +characters in length. +.SH OTHER KEYWORDS +Other keywords in the language are taken from the names of modules +loaded by the server. These keywords are dependent on both the +modules, and the local configuration. + +Some use keywords that are defined in the default configuration file +are: +.IP fail +Cause the request to be treated as if a database failure had occurred. +.IP noop +Do nothing. This also serves as an instruction to the configurable +failover tracking that nothing was done in the current section. +.IP ok +Instructs the server that the request was processed properly. This +keyword can be used to over-ride earlier failures, if the local +administrator determines that the failures are not catastrophic. +.IP reject +Causes the request to be immediately rejected +.SH MODULE RETURN CODES +When a module is called, it returns one of the following codes to +"unlang", with the following meaning. + +.DS + notfound information was not found +.br + noop the module did nothing +.br + ok the module succeeded +.br + updated the module updated the request +.br + fail the module failed +.br + reject the module rejected the request +.br + userlock the user was locked out +.br + invalid the configuration was invalid +.br + handled the module has handled the request itself +.DE + +These return codes can be tested for in a condition, as described +above in the CONDITIONS section. + +See also the file doc/configurable_failover for additional methods of +trapping and modifying module return codes. +.SH FILES +/etc/raddb/radiusd.conf +.SH "SEE ALSO" +.BR radiusd.conf (5), +.BR dictionary (5) +.SH AUTHOR +Alan DeKok <aland@deployingradius.com> diff --git a/man/man5/users.5 b/man/man5/users.5 new file mode 100644 index 0000000..4586b96 --- /dev/null +++ b/man/man5/users.5 @@ -0,0 +1,228 @@ +.\" # DS - begin display +.de DS +.RS +.nf +.sp +.. +.\" # DE - end display +.de DE +.fi +.RE +.sp +.. +.TH USERS 5 "04 Jan 2004" "" "FreeRADIUS user authorization file" +.SH NAME +users \- user authorization file for the FreeRADIUS server +.SH DESCRIPTION +The \fBusers\fP files reside in the files module configuration directory, +by default \fB/etc/raddb/mods-config/files/\fP. It contains a series +of configuration directives which are used by the \fIfiles\fP +module to decide how to authorize and authenticate each user request. + +Every line starting with a hash sign +.RB (' # ') +is treated as comment and ignored. +.PP +Each entry of the file begins with a username, followed by a (possibly +empty) list of check items, all on one line. The next line begins +with a tab, and a (possibly empty) list of reply items. Each item in +the check or reply item list is an attribute of the form \fBname = +value\fP. Multiple items may be placed on one line, in which case +they must be separated by commas. The reply items may be specified +over multiple lines, in which case each line must end with a comma, +and the last line of the reply items must not end with a comma. + +The check items are a list of attributes used to match the incoming +request. If the username matches, AND all of the check items match +the incoming request, then the reply items are added to the list of +attributes which will be used in the reply to that request. This +process is repeated for all of the entries in the users file. + +If the incoming request matches NO entry, then the request is +rejected. + +.SH CAVEATS +The special keyword \fBDEFAULT\fP matches any usernames. + +The entries are processed in order, from the top of the \fBusers\fP file, +on down. If an entry contains the special item \fBFall-Through = +No\fP as a reply attribute, then the processing of the file stops, and +no more entries are matched. Any reply item list without any +\fBFall-Through\fP attribute is treated as though it included a +\fBFall-Through = No\fP attribute. + +If an entry contains the special item \fBFall-Through = Yes\fP as a +reply attribute, then the processing proceeds to the next entry in +order. + +Care should be taken when using \fBFall-Through\fP. The server should +be tested in debugging mode with a number of test requests, in order +to verify that the configured entries behave as expected. + +The special attribute \fBAuth-Type\fP is used to identify the +authentication type to be used for that user. See the +\fBdictionary\fP file for a list of permitted values for the +\fBAuth-Type\fP attribute. + +Once the \fBusers\fP file has been processed, the request is authenticated, +using the method given by \fBAuth-Type\fP. + +.SH OPERATORS +Additional operators other than \fB=\fP may be used for the attributes in +either the check item, or reply item list. The following is a list of +operators, and their meaning. + +.TP 0.5i +.B "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. +.br +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." + +.TP 0.5i +.B "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. +.br +As a reply item, it has an identical meaning, but for the reply items, +instead of the request items. + +.TP 0.5i +.B "Attribute == Value" +As a check item, it matches if the named attribute is present in the +request, AND has the given value. +.br +Not allowed as a reply item. + +.TP 0.5i +.B "Attribute += Value" +Always matches as a check item, and adds the current attribute with +value to the tail of the list of configuration items. +.br +As a reply item, it has an identical meaning, but the attribute is +added to the tail of the reply items list. + +.TP 0.5i +.B "Attribute ^= Value" +Always matches as a check item, and adds the current attribute with +value to the head of the list of configuration items. +.br +As a reply item, it has an identical meaning, but the attribute is +added to the head of the reply items list. + +.TP 0.5i +.B "Attribute != Value" +As a check item, matches if the given attribute is in the request, AND +does not have the given value. +.br +Not allowed as a reply item. + +.TP 0.5i +.B "Attribute > Value" +As a check item, it matches if the request contains an attribute with +a value greater than the one given. +.br +Not allowed as a reply item. + +.TP 0.5i +.B "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. +.br +Not allowed as a reply item. + +.TP 0.5i +.B "Attribute < Value" +As a check item, it matches if the request contains an attribute with +a value less than the one given. +.br +Not allowed as a reply item. + +.TP 0.5i +.B "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. +.br +Not allowed as a reply item. + +.TP 0.5i +.B "Attribute =* Value" +As a check item, it matches if the request contains the named +attribute, no matter what the value is. +.br +Not allowed as a reply item. + +.TP 0.5i +.B "Attribute !* Value" +As a check item, it matches if the request does not contain the named +attribute, no matter what the value is. +.br +Not allowed as a reply item. + +.SH EXAMPLES + +.DS +bob Cleartext-Password := "hello" + +.DE +.RS +Requests containing the User-Name attribute, with value "bob", will be +authenticated using the "known good" password "hello". There are no +reply items, so the reply will be empty. +.RE + +.DS +DEFAULT Service-Type == Framed-User, Framed-Protocol == PPP +.br + Service-Type = Framed-User, +.br + Framed-Protocol = PPP, +.br + Fall-Through = Yes + +.DE +.RS +If the request packet contains the attributes Service-Type and +Framed-Protocol, with the given values, then include those attributes +in the reply. + +That is, give the user what they ask for. This entry also shows how +to specify multiple reply items. +.RE + +See the \fBusers\fP file supplied with the server for more examples +and comments. + +.SH HINTS +Run the server in debugging mode (\fB-X\fP), and use the +\fBradclient\fP program to send it test packets which you think will +match specific entries. The server will print out which entries were +matched for that request, so you can verify your expectations. This +should be the FIRST thing you do if you suspect problems with the +file. + +Care should be taken when writing entries for the \fBusers\fP file. It is +easy to misconfigure the server so that requests are accepted when you +wish to reject them. The entries should be ordered, and the +Fall-Through item should be used ONLY where it is required. + +Entries rejecting certain requests should go at the top of the file, +and should not have a Fall-Through item in their reply items. Entries +for specific users, who do not have a Fall-Through item, should come +next. Any DEFAULT entries should usually come last, except as fall-through +entries that set reply attributes. + +.SH FILES +/etc/raddb/mods-config/files/ +.SH "SEE ALSO" +.BR radclient (1), +.BR radiusd (8), +.BR dictionary (5), + +.SH AUTHOR +The FreeRADIUS team. |