Back To MAN Pages From BackTrack 5 R1 Master List
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.
Subject to a few limitations described below, any keyword can appear in any context. The language consists of a series of entries, each one 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.
chap # call the CHAP module
sql # call the SQL module
...
if (condition) {
...
}
else {
...
}
elsif (condition) {
...
}
No statement other than "case" can appear in a "switch" block.
switch "string" {
...
}
A "case" statement cannot appear outside of a "switch" block.
case string {
...
}
A default entry can be defined by omitting the static string. This entry will be used if no other "case" entry matches. Only one default entry can exist in a "switch" section.
case {
...
}
update <list> {
attribute = value
...
}
The <list> can be one of "request", "reply", "proxy-request", "proxy-reply", "coa", "disconnect", or "control". The "control" list is the list of attributes maintainted 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 backwards compatibility with older versions, "check" is accepted as a synonym for "control". The use of "check" is deprecated, and will be removed in a future release.
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 only contents permitted in an "update" section are attributes and values. The contents of the "update" section are described in the ATTRIBUTES section below.
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.
redundant {
sql1 # try this
sql2 # try this only if sql1 fails.
...
}
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.
load-balance {
ldap1 # 50% of requests go here
ldap2 # 50% of requests go here
}
In general, we recommend using "redundant-load-balance" instead of "load-balance".
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.
redundant-load-balance {
ldap1 # 50%, unless ldap2 is down, then 100%
ldap2 # 50%, unless ldap1 is down, then 100%
}
(foo)
Evalutes 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 comparings 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.
(!foo)
Evalutes to true if 'foo' evaluates to false, and vice-versa.
Short-circuit operators
(foo || bar)
(foo && bar)
"&&" 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.
(foo == bar)
Compares 'foo' to 'bar', and evaluates to true if the comparison holds true. Valid comparison operators are "==", "!=", "<", "<=", ">", ">=", "=~", and "!~", all with their usual meanings. Invalid comparison operators are ":=" and "=".
Conditions may be nested to any depth, subject only to line length limitations (8192 bytes).
word
Using attribute references permits limited type-specific comparisons, as seen in the examples below.
if (User-Name == "bob") {
...
if (Framed-IP-Address > 127.0.0.1) {
...
if (Service-Type == Login-User) {
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\" !")
Note that for security reasons, the input string is split into command and arguments before variable 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.
The trailing 'i' is optional, and indicates that the regular expression match should be done in a case-insensitive fashion.
If the comparison operator is "=~", then parantheses in the regular expression will define variables containing the matching text, as described below in the VARIABLES section.
%{Variable-Name}
Note that unlike C, there is no way to declare variables, or to refer to them outside of a string context. All references to variables MUST be contained inside of a double-quoted or back-quoted string.
Many potential variables 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 variable. When the server receives a packet, it uses the packet contents to look up entries in the dictionary, and instantiates variables with a name taken from the dictionaries, and a value taken from the packet contents. This process means that if a variable does not exist, it is usually because it was not mentioned in a packet that the server received.
Once the variable is instantiated, it is added to an appropriate attribute list, as described below. In many cases, attributes and variables are inter-changeble, and are often talked about that way. However, variables can also refer to run-time calls to modules, which may perform operations like SQL SELECTs, and which may return the result as the value of the variable.
Referencing attribute lists
%{<list>:Attribute-Name}
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.
When a variable is encountered, the given list is examined for an attribute of the given name. If found, the variable reference in the string is replaced with the value of that attribute. Some examples are:
%{User-Name}
%{request:User-Name} # same as above
%{reply:User-Name}
%{outer.reqest:User-Name} # from inside of a TTLS/PEAP tunnel
Results of regular expression matches
Obtaining results from databases
%{module: string ...}
The syntax of the string is module-specific. Please read the module documentation for additional details.
Conditional Syntax
These conditional expansions can be nested to almost any depth, such as with %{%{One}:-%{%{Two}:-%{Three}}}
String lengths and arrays
e.g. %{#Junk-junk:-foo} will yeild the string "foo".
For example, %{User-Name[0]} is the same as %{User-Name}
The variable %{Cisco-AVPair[2]} will reference the value of the THIRD Cisco-AVPair attribute (if it exists) in the request packet,
For most requests, %{request:User-Name[#]} == 1
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.
Attribute-Name = value
Attribute names
Enforcement and Filtering Operators
Note that this operator is very different than the '=' operator listed above!
This operator is valid only for attributes of integer type.
This operator is valid only for attributes of integer type.
When string values are finally assigned to a variable, 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.
Some use keywords that are defined in the default configuration file are:
notfound information was not found
noop the module did nothing
ok the module succeeded
updated the module updated the request
fail the module failed
reject the module rejected the request
userlock the user was locked out
invalid the configuration was invalid
handled the module has handled the request itself
These return codes can be tested for in a condition, as described above in the CONDITIONS section.
If you would like to republish one of the articles from this site on your webpage or print journal please contact IronGeek.
Copyright 2020, IronGeek