1unlang(5)              FreeRADIUS Processing un-language             unlang(5)
2
3
4

NAME

6       unlang - FreeRADIUS Processing un-language
7

DESCRIPTION

9       FreeRADIUS  supports  a simple processing language in its configuration
10       files.  We call it an "un-language" because the  intention  is  NOT  to
11       create  yet  another  programming language.  If you need something more
12       complicated than what is described here, we suggest using the  Perl  or
13       Python modules rlm_perl, or rlm_python.
14
15       The goal of the language is to allow simple policies to be written with
16       minimal effort.  Those policies are then  applied  when  a  request  is
17       being  processed.   Requests  are  processed  through  virtual  servers
18       (including the  default  one),  in  the  sections  titled  "authorize",
19       "authenticate",   "post-auth",  "preacct",  "accounting",  "pre-proxy",
20       "post-proxy", and "session".
21
22       These policies cannot be used in any other part  of  the  configuration
23       files, such as module or client configuration.
24

KEYWORDS

26       The  keywords  for  the  language are a combination of pre-defined key‐
27       words, and references to loadable module names.  We document  only  the
28       pre-defined keywords here.
29
30       Subject to a few limitations described below, any keyword can appear in
31       any context.  The language consists of a series of  entries,  each  one
32       line.   Each  entry  begins with a keyword.  Entries are organized into
33       lists.  Processing of the language is line by line, from the  start  of
34       the list to the end.  Actions are executed per-keyword.
35
36       module-name[.section-name]
37              A  reference  to the named module.  When processing reaches this
38              point, the pre-compiled module is called.  The module  may  suc‐
39              ceed  or fail, and will return a status to "unlang" if so.  This
40              status can be tested in a condition.   See  the  "Simple  Condi‐
41              tions"  text in the CONDITIONS section, and MODULE RETURN CODES,
42              below.  If a section-name is provided, it will cause the  module
43              to execute as if it were listed in the named section.
44
45                   chap  # call the CHAP module
46                   sql   # call the SQL module
47                   ...
48
49       if
50              Checks for a particular condition.  If true, the block after the
51              condition is processed.  Otherwise, the block is  ignored.   See
52              CONDITIONS, below, for documentation on the format of the condi‐
53              tions.
54
55                   if (condition) {
56                        ...
57                   }
58
59       else
60              Define a block to be executed only if the previous  "if"  condi‐
61              tion returned false.
62
63                   else {
64                        ...
65                   }
66
67       elsif
68              Define  a  block to be executed only if the previous "if" condi‐
69              tion returned false, and if the specified condition evaluates to
70              true.
71
72                   elsif (condition) {
73                        ...
74                   }
75
76       foreach
77              Loops  over  values  of an attribute, running the block for each
78              value.  The return value of the block is the return value of the
79              last  statement executed.  The loop can be exited early by using
80              the "break" keyword.  Unlike other languages, "break" here means
81              "exit  the loop at the next iteration", not "exit the loop now".
82              The result is that any statements after the "break" keyword will
83              still  be  executed.  We recommend using "break" only when it is
84              the last statement in a "foreach" block.
85
86              Inside of the "foreach" block,  the  attribute  which  is  being
87              looped  over  can  be referenced as "Foreach-Variable-#".  Where
88              "#" is the depth of the loop, starting at "0".   e.g.  "Foreach-
89              Variable-0".   The  loops  can  be  nested up to eight (8) deep,
90              though this is not recommended.
91
92                   foreach &Attribute-Reference {
93                        ...
94                   }
95
96       switch
97              A "switch" statement takes one argument, and contains  a  series
98              of "case" statements.  When a "switch" statement is encountered,
99              the argument from the "switch" is evaluated in turn against  the
100              argument from each "case" statement.  The first "case" statement
101              which matches is executed.   All  other  "case"  statements  are
102              ignored.  A default "case" statement can be defined, by omitting
103              its argument.
104
105              If the argument is a double quoted string (e.g. "%{exec:1 + 2}",
106              it  is  expanded  as described in the DATA TYPES section, below.
107              The match is then performed on  the  string  returned  from  the
108              expansion.   If  the  argument  is  an attribute reference (e.g.
109              &User-Name), then the match is performed on the  value  of  that
110              attribute.   Otherwise,  the  argument  is taken to be a literal
111              string, and matching is done via simple comparison.
112
113              No statement other than "case" can appear in a "switch" block.
114
115                   switch <argument> {
116                        ...
117                   }
118
119       case
120              Provides a place-holder which matches the argument of  a  parent
121              "switch" statement.
122
123              A "case" statement cannot appear outside of a "switch" block.
124
125              If the argument is a double quoted string (e.g. "%{exec:1 + 2}",
126              it is expanded as described in the DATA  TYPES  section,  below.
127              The  match  is  then  performed  on the string returned from the
128              expansion.  If the argument  is  an  attribute  reference  (e.g.
129              &User-Name),  then  the  match is performed on the value of that
130              attribute.  Otherwise, the argument is taken  to  be  a  literal
131              string, and matching is done via simple comparison.
132
133                   case <argument> {
134                        ...
135                   }  A default entry can be defined by omitting the argument,
136              as given below.  This entry will be  used  if  no  other  "case"
137              entry  matches.   Only one default entry can exist in a "switch"
138              section.
139
140                   case {
141                        ...
142                   }
143
144       update
145              Update a particular attribute  list,  based  on  the  attributes
146              given in the current block.
147
148                   update <list> {
149                        &Attribute-Reference = value
150                        ...
151                   }  The  <list>  can  be  one of "request", "reply", "proxy-
152              request", "proxy-reply", "coa",  "disconnect",  "session-state",
153              or  "control".   As  of Version 3, the <list> can be omitted, in
154              which case "request" is assumed.
155
156              The "control" list is the list of attributes maintainted  inter‐
157              nally  by  the server that controls how the server processes the
158              request.  Any attribute that does not go in a packet on the net‐
159              work will generally be placed in the "control" list.
160
161              For EAP methods with tunneled authentication sessions (i.e. PEAP
162              and EAP-TTLS), the  inner  tunnel  session  can  also  reference
163              "outer.request", "outer.reply", and "outer.control".  Those ref‐
164              erences allow you to address the relevant list in the outer tun‐
165              nel session.
166
167              The  "coa"  and  "disconnect" sections can only be used when the
168              server receives an Access-Request  or  Accounting-Request.   Use
169              "request"  and "reply" instead of "coa" when the server receives
170              a CoA-Request or Disconnect-Request packet.
171
172              Adding one or more attributes to either of the "coa" or "discon‐
173              nect"  list  causes server to originate a CoA-Request or Discon‐
174              nect-Request packet.  That  packet  is  sent  when  the  current
175              Access-Request  or  Accounting-Request  has been finished, and a
176              reply sent to the NAS.  See  raddb/sites-available/originate-coa
177              for additional information.
178
179              The  "session-state" list is primarily used for EAP.  Attributes
180              put into the "session-state" list are saved for the next  packet
181              in  the session.  They are automatically retrieved when the next
182              packet is received.
183
184              The  only  contents  permitted  in  an  "update"   section   are
185              attributes and values.  The contents of the "update" section are
186              described in the ATTRIBUTE REFERENCE  and  ATTRIBUTE  ASSIGNMENT
187              sections below.
188
189       redundant
190              This  section contains a simple list of modules.  The first mod‐
191              ule is called when the section is being processed.  If the first
192              module succeeds in its operation, then the server stops process‐
193              ing the section, and returns to the parent section.
194
195              If, however, the module fails, then the next module in the  list
196              is  tried,  as  described above.  The processing continues until
197              one module succeeds, or until the list has been exhausted.
198
199              Redundant sections can contain only a list of modules, and  can‐
200              not  contain  keywords  that perform conditional operations (if,
201              else, etc) or update an attribute list.
202
203                   redundant {
204                        sql1 # try this
205                        sql2 # try this only if sql1 fails.
206                        ...
207                   }
208
209       load-balance
210              This section contains a simple list of modules.  When  the  sec‐
211              tion  is  entered, one module is chosen at random to process the
212              request.  All of the modules in the list should be the same type
213              (e.g.  ldap  or  sql).   All  of  the modules in the list should
214              behave identically,  otherwise  the  load-balance  section  will
215              return different results for the same request.
216
217              Load-balance  sections  can  contain only a list of modules, and
218              cannot contain keywords that perform conditional operations (if,
219              else, etc) or update an attribute list.
220
221                   load-balance {
222                        ldap1     # 50% of requests go here
223                        ldap2     # 50% of requests go here
224                   }  In  general, we recommend using "redundant-load-balance"
225              instead of "load-balance".
226
227       redundant-load-balance
228              This section contains a simple list of modules.  When  the  sec‐
229              tion  is  entered, one module is chosen at random to process the
230              request.  If that module succeeds, then the  server  stops  pro‐
231              cessing the section.  If, however, the module fails, then one of
232              the remaining  modules  is  chosen  at  random  to  process  the
233              request.   This  process  repeats  until one module succeeds, or
234              until the list has been exhausted.
235
236              All of the modules in the list should be  the  same  type  (e.g.
237              ldap  or  sql).   All  of  the modules in the list should behave
238              identically, otherwise the load-balance section will return dif‐
239              ferent results for the same request.
240
241              Load-balance  sections  can  contain only a list of modules, and
242              cannot contain keywords that perform conditional operations (if,
243              else,   etc)   or   update   an   attribute   list.  Please  see
244              raddb/radiusd.conf "instantiate" section for more  configuration
245              examples.
246
247                   redundant-load-balance {
248                        ldap1     # 50%, unless ldap2 is down, then 100%
249                        ldap2     # 50%, unless ldap1 is down, then 100%
250                   }
251
252       return
253              Returns  from the current top-level section, e.g. "authorize" or
254              "authenticate".  This keyword is mainly used to avoid layers  of
255              nested "if" and "else" statements.
256
257                   authorize {
258                        if (...) {
259                             ...
260                             return
261                        }
262                        ...  # this is never reached when the "if"
263                        ...  # statement is executed
264                   }
265

ATTRIBUTE REFERENCES

267       Attributes may be referenced via the following syntax:      &Attribute-
268       Name              &Attribute-Name:TAG              &Attribute-Name[NUM]
269            &<list>:Attribute-Name       &<list>:Attribute-Name:TAG[NUM] Where
270       <list>  is  one  of  "request",  "reply",  "control",  "proxy-request",
271       "proxy-reply",   or  "outer.request",  "outer.reply",  "outer.control",
272       "outer.proxy-request",  or  "outer.proxy-reply".  just  as   with   the
273       "update"  section,  above.   The  "<list>:"  prefix is optional, and if
274       omitted, is assumed to refer to the "request" list.
275
276       The TAG portion is a decimal integer between 1 and 31.  Please see  RFC
277       2868  for  more  information  about  tags.   Tags  can only be used for
278       attributes which are marked in the dictionary as "has_tag".
279
280       The NUM portion is used when there are multiple attributes of the  same
281       name  in  a list.  The "Attribute-Name" reference will return the first
282       attribute.  Using an array offset allows the policy  to  refer  to  the
283       second and subsequent attributes.
284
285       If '*' is used in the NUM portion, it evaluates to all instances of the
286       attribute in the request.
287
288       If 'n' is used in the NUM portion, it evaluates to the last instance of
289       the attribute in the request.
290
291       When  an  attribute name is encountered, the given list is examined for
292       an attribute of the given name.  Some examples are:      User-Name
293            request:User-Name # same as above
294            reply:User-Name
295            Tunnel-Password:1
296            Cisco-AVPAir[2]
297            outer.request:User-Name # from inside of a TTLS/PEAP  tunnel  Note
298       that  unlike  C,  there is no way to define new attributes at run-time.
299       They MUST be declared in a dictionary file, and loaded when the  server
300       starts.
301
302       All  attributes  are  defined  in  the  dictionaries that accompany the
303       server.  These definitions define only the name and type,  and  do  not
304       define  the value of the attribute.  When the server receives a packet,
305       it uses the packet contents to look up entries in the  dictionary,  and
306       instantiates  attributes with a name taken from the dictionaries, and a
307       value taken from the packet contents.  This process means  that  if  an
308       attribute does not exist, it is usually because it was not contained in
309       a packet that the server received.
310
311       Once the attribute is instantiated, it is added to a list.  It can then
312       be referenced, updated, replaced, etc.
313
314

CONDITIONS

316       The  conditions  are  similar  to C conditions in syntax, though quoted
317       strings are supported, as with the Unix shell.
318
319       Simple conditions
320                   (foo) Evaluates to true if  'foo'  is  a  non-empty  string
321              (single  quotes, double quotes, or back-quoted).  Also evaluates
322              to true if 'foo' is a non-zero number.  Note that  the  language
323              is  poorly  typed,  so the string "0000" can be interpreted as a
324              numerical zero.  This issue can be avoided by comparings strings
325              to  an  empty  string,  rather  than by evaluating the string by
326              itself.
327
328              If the word 'foo' is not a quoted string, then it can  be  taken
329              as a reference to a named attribute.  See "Referencing attribute
330              lists", below, for examples of attribute references.  The condi‐
331              tion evaluates to true if the named attribute exists.
332
333              Otherwise,  if the word 'foo' is not a quoted string, and is not
334              an attribute reference, then it is interpreted as a reference to
335              a  module  return  code.  The condition evaluates to true if the
336              most recent module return code  matches  the  name  given  here.
337              Valid  module  return  codes  are  given in MODULE RETURN CODES,
338              below.
339
340       Negation
341                   (!foo) Evaluates to true if 'foo' evaluates to  false,  and
342              vice-versa.
343
344       Short-circuit operators
345                   (foo || bar)
346                   (foo  &&  bar)  "&&"  and "||" are short-circuit operators.
347              "&&" evaluates the first condition,  and  evaluates  the  second
348              condition  if  and  only if the result of the first condition is
349              true.  "||" is similar, but executes the second command  if  and
350              only if the result of the first condition is false.
351
352       Comparisons
353                   (foo == bar) Compares 'foo' to 'bar', and evaluates to true
354              if the comparison holds true.  Valid  comparison  operators  are
355              "==", "!=", "<", "<=", ">", ">=", "=~", and "!~", all with their
356              usual meanings.  The operators ":=" and "=" are assignment oper‐
357              ators, and are not allowed for comparisons.
358
359              The  operators  "<",  "<=",  ">",  and ">=" are also allowed for
360              checking that an IP address is contained within a network.   For
361              example:       if (<ipaddr>192.0.2.1 < 192.0.2.0/24) { This com‐
362              parison succeeds, because the  address  192.0.2.1  is  contained
363              within the network 192.0.2.0/24.
364
365       Attribute Comparisons
366              When doing attribute comparisons, the data type of the attribute
367              is used to determine the data type of the right-hand side  argu‐
368              ment.        (&User-Name  ==  "foo")  Compares  the value of the
369              User-Name attribute to the string 'foo', and evaluates  to  true
370              if the comparison holds true.
371
372              Similarly,       (&Framed-IP-Address  == 192.0.2.1) Compares the
373              value of the  Framed-IP-Address  attribute  to  the  IP  address
374              192.0.2.1.  This IP address does not need to be quoted.
375
376       Inter-Attribute Comparisons
377                   (&User-Name  == &Filter-Id) Compares the value of the User-
378              Name attribute to the contents of the Filter-Id  attribute,  and
379              evaluates to true if the comparison holds true.  Unlike the pre‐
380              vious example, this comparison is done in a type-safe way.   For
381              example,  comparing  the  IP  addresses 1.2.3.4 and 127.0.0.1 as
382              strings will return different results than comparing them as  IP
383              addresses.
384
385              The  "&"  character  in  the condition means that the comparison
386              "refers" to the Filter-Id attribute.  If left off, it means that
387              the  User-Name attribute is compared to the literal string "Fil‐
388              ter-Id".
389
390              Where the left-hand side is an attribute, the "&" can  be  omit‐
391              ted.   However, it is allowed for backwards compatibility.  e.g.
392              The comparison "(&User-Name == &Filter-Id)" is equivalent to the
393              example above.
394
395              We  recommend  using  attribute  references  instead of printing
396              attributes to a  string,  e.g.  (User-Name  ==  "%{Filter-Id}").
397              Attribute references will be faster and more efficient.
398
399              The  conditions  will  check  only  the  first  occurrence of an
400              attribute.  If there is more than one instance of an  attribute,
401              the following syntax should be used:
402
403                   (&Attribute-Name[*]  == "foo") Using the "[*]" syntax means
404              that it checks all of the instances of the named attribute.   If
405              one  attribute  matches, the condition succeeds.  If none match,
406              the condition fails.
407
408
409       Casts       (<type>foo == bar) The left-hand-side of a condition can be
410              "cast" to a specific data type.  The data type must be one which
411              is valid for the dictionaries.  e.g. "integer", "ipaddr", etc.
412
413              The comparison is performed in a type-safe way, as with  "Inter-
414              Attribute  Comparisons", above.  Both sides of the condition are
415              parsed into temporary attributes, and  the  attributes  compared
416              via  type-specific  methods.   The  temporary attributes have no
417              other effect, and are not saved anywhere.
418
419              Casting allows conditions to perform type-specific  comparisons.
420              In  previous  versions  of the server, the data would have to be
421              manually placed into an intermediate attribute (or  attributes),
422              and  then  the attribute (or attributes) compared.  The use of a
423              cast allows for simpler policies.
424
425              Casts are allowed only on the left-hand side argument of a  con‐
426              dition.
427
428       Conditions may be nested to any depth, subject only to line length lim‐
429       itations (8192 bytes).
430

DATA TYPES

432       There are only a few data types supported in the  language.   Reference
433       to  attributes,  numbers,  and  strings.   Any  data type can appear in
434       stand-alone condition, in which case they are evaluated as described in
435       "Simple conditions", above.  They can also appear (with some exceptions
436       noted below) on the left-hand or on the right-hand side of  a  compari‐
437       son.
438
439       numbers
440              Numbers  are  composed  of decimal digits.  Floating point, hex,
441              and octal numbers are not supported.  The maximum  value  for  a
442              number  is  machine-dependent, but is usually 32-bits, including
443              one bit for a sign value.
444
445       word
446              Text that is not enclosed in quotes is  interpreted  differently
447              depending  on  where it occurs in a condition.  On the left hand
448              side of a condition, it is interpreted  as  a  reference  to  an
449              attribute.   On the right hand side, it is interpreted as a sim‐
450              ple string, in the same manner as a single-quoted string.
451
452              Using attribute references permits limited type-specific compar‐
453              isons, as seen in the examples below.
454
455                   if (&User-Name == "bob") {
456                        ...
457                   if (&Framed-IP-Address > 127.0.0.1) {
458                        ...
459                   if (&Service-Type == Login-User) {
460
461       "strings"
462              Double-quoted strings are expanded by inserting the value of any
463              attributes (see VARIABLES, below) before  being  evaluated.   If
464              the result is a number it is evaluated in a numerical context.
465
466              String  length  is  limited  by  line-length, usually about 8000
467              characters.  A double quote character can be used  in  a  string
468              via the normal back-slash escaping method.  ("like \"this\" !")
469
470       'strings'
471              Single-quoted strings are evaluated as-is.  Their values are not
472              expanded as with double-quoted strings above, and they  are  not
473              interpreted as attribute references.
474
475       `strings`
476              Back-quoted  strings  are evaluated by expanding the contents of
477              the string, as described above for double-quoted  strings.   The
478              resulting command given inside of the string in a sub-shell, and
479              taking the output as a string.  This behavior is much  the  same
480              as that of Unix shells.
481
482              Note  that  for security reasons, the input string is split into
483              command and arguments before string expansion is done.
484
485              For performance reasons, we suggest that the use of  back-quoted
486              strings  be  kept  to a minimum.  Executing external programs is
487              relatively expensive, and executing a large number  of  programs
488              for  every  request  can  quickly  use  all of the CPU time in a
489              server.  If you believe that you need to execute many  programs,
490              we  suggest finding alternative ways to achieve the same result.
491              In some cases, using a real language may be sufficient.
492
493
494       /regex/im
495              These strings are valid only on the right-hand side of a compar‐
496              ison,  and  then  only  when  the comparison operator is "=~" or
497              "!~".  They are regular expressions, as implemented by the local
498              regular expression library on the system.  This is usually Posix
499              regular expressions.
500
501              The trailing 'i' is optional, and  indicates  that  the  regular
502              expression match should be done in a case-insensitive fashion.
503
504              The trailing 'm' is also optional, and indicates that carrot '^'
505              and dollar '$' anchors should match on new lines as well  as  at
506              the start and end of the subject string.
507
508              If the comparison operator is "=~", then parentheses in the reg‐
509              ular expression will define variables  containing  the  matching
510              text, as described below in the VARIABLES section.
511

EXPANSIONS

513       Attributes  are expanded using the ATTRIBUTE REFERENCE syntax described
514       above, and surrounding the reference with "%{...}"
515
516            %{Attribute-Reference}
517
518       The result will be a string which contains the value of  the  attribute
519       which was referenced, as a printable string.  If the attribute does not
520       exist, the result will be an empty string.
521
522       Results of regular expression matches
523              If a regular expression match  has  previously  been  performed,
524              then  the  special  variable  %{0}  will  contain  a copy of the
525              matched portion of the input string.  The variables %{1} through
526              %{32}  will  contain  the  substring  matches, starting from the
527              left-most capture group, onwards.  If there  are  more  than  32
528              capture  groups,  the additional results will not be accessible.
529              If the server is built with libpcre, the results of  named  cap‐
530              ture  groups  are  available  using the "%{regex:capture group}"
531              expansion.  They will also be  accessible  using  the  variables
532              described  above.  Every time a regular expression is evaluated,
533              whether it matches or not, the  capture  group  values  will  be
534              cleared.
535
536       Obtaining results from databases
537              It  is  useful  to query a database for some information, and to
538              use the result in a condition.  The following syntax will call a
539              module,  pass it the given string, and replace the string expan‐
540              sion with the resulting string returned from the module.
541
542                   %{module: string ...}
543
544              The syntax of the string is module-specific.   Please  read  the
545              module documentation for additional details.
546
547       Conditional Syntax
548              Conditional  syntax similar to that used in Unix shells may also
549              be used.
550
551              %{%{Foo}:-bar}
552                     If %{Foo} has a value, returns that value.
553                     Otherwise, returns literal string "bar".
554
555              %{%{Foo}:-%{Bar}}
556                     If %{Foo} has a value, returns that value.
557                     Otherwise, returns the expansion of %{Bar}.
558
559                     These conditional expansions can be nested to almost  any
560                     depth, such as with %{%{One}:-%{%{Two}:-%{Three}}}
561
562       String lengths and arrays
563              Similar  to  a  Unix  shell,  there are ways to reference string
564              lengths, and the second or more instance of an  attribute  in  a
565              list.   If  you  need  more  than this functionality, we suggest
566              using a real language.
567
568              %{strlen:string}
569                     The number of characters in "string".  If  "string"  does
570                     not  exist,  then the length also does not exist, instead
571                     of being zero.
572
573                     The "string" is expanded before the length is taken.
574
575
576              %{integer:Attribute-Name}
577                     The integer value of the Attribute-Name, instead  of  the
578                     enumerated name.
579
580                     e.g.  If  a request contains "Service-Type = Login-User",
581                     the expansion of %{integer:Service-Type} will yield "1".
582
583
584              %{hex:Attribute-Name}
585                     The hex value of the Attribute-Name, as a series  of  hex
586                     digits.
587
588                     e.g.   If   a   request   contains  "Framed-IP-Address  =
589                     127.0.0.1",  the  expansion  of  %{hex:Framed-IP-Address}
590                     will yield "0x7f000001".
591
592
593              %{Attribute-Name[#]}
594                     The number of instances of Attribute-Name.
595
596                     e.g.  If a request contains "User-Name = bob", the expan‐
597                     sion of %{User-Name[#]} will yield "1".
598
599
600              %{Attribute-Name[*]}
601                     All values of Attribute-Name, concatenated together  with
602                     ',' as the separator.
603
604
605              %{List-Name:[#]}
606                     The number of attributes in the named list.
607
608
609              %{List-Name:[*]}
610                     All  values of attributes in the named-list, concatenated
611                     together with ',' as the  separator.  Use  the  %{pairs:}
612                     xlat to get a list of attributes and values.
613
614                     e.g.  If  a  response  contains "Reply-Message = 'Hello',
615                     Reply-Message = 'bob' the  expansion  of  "%{reply:Reply-
616                     Message[*]} will yield "Hello\nbob"
617
618

ATTRIBUTE ASSIGNMENTS

620       The  attribute  lists  described  above may be edited by listing one or
621       more attributes in an "update" section.  Once the attributes have  been
622       defined,  they  may  be  referenced as described above in the VARIABLES
623       section.
624
625       The following syntax defines attributes in an "update"  section.   Each
626       attribute  and  value  has  to  be all on one line in the configuration
627       file.  There is no need for commas or semi-colons after the value.
628
629            Attribute-Reference = value
630
631       Attribute Reference
632              The Attribute-Reference must be a reference (see above), using a
633              name  previously  defined in a dictionary.  If an undefined name
634              is used, the server will return an error, and will not start.
635
636
637       Operators
638              The operator used to assign the value of the  attribute  may  be
639              one of the following, with the given meaning.
640
641              =      Add  the  attribute  to  the  list,  if  and  only  if an
642                     attribute of the same name is not already present in that
643                     list.
644
645              :=     Add  the  attribute to the list.  If any attribute of the
646                     same name is already present in that list, its  value  is
647                     replaced with the value of the current attribute.
648
649              +=     Add  the  attribute  to  the  tail  of  the list, even if
650                     attributes of the same name are already  present  in  the
651                     list. When the right hand side of the expression resolves
652                     to multiple values, it means add all values to  the  tail
653                     of the list.
654
655       Enforcement and Filtering Operators
656              The following operators may also be used in addition to the ones
657              listed above.  Their function is to perform enforcement or  fil‐
658              tering on attributes in a list.
659
660              -=     Remove  all  matching attributes from the list.  Both the
661                     attribute name and value have to match in order  for  the
662                     attribute to be removed from the list.
663
664              ==     Keep  all  matching  attributes.  Both the attribute name
665                     and value have to match in order  for  the  attribute  to
666                     remain in the list.
667
668                     Note  that  this  operator is very different than the '='
669                     operator listed above!
670
671              !=     Keep all attributes with matching  name,  and  value  not
672                     equal to the given one.
673
674              <      Keep  all  attributes  having  values less than the value
675                     given here.  Any larger value is replaced  by  the  value
676                     given here.  If no attribute exists, it is added with the
677                     value given here, as with "+=".
678
679              <=     Keep all attributes having values less than, or equal to,
680                     the  value  given  here.  Any larger value is replaced by
681                     the value given here.  If  no  attribute  exists,  it  is
682                     added with the value given here, as with "+=".
683
684              >      Keep  all attributes having values greater than the value
685                     given here.  Any smaller value is replaced by  the  value
686                     given here.  If no attribute exists, it is added with the
687                     value given here, as with "+=".
688
689              >=     Keep all attributes having values greater than, or  equal
690                     to,  the value given here.  Any smaller value is replaced
691                     by the value given here.  If no attribute exists,  it  is
692                     added with the value given here, as with "+=".
693
694              !*     Delete  all occurrences of the named attribute, no matter
695                     what the value.
696
697              =~     Keep all attributes having values which match  the  given
698                     regular  expression.   If  no  attribute matches, nothing
699                     else is done.
700
701              !~     Keep all attributes having values which fail to match the
702                     given regular expression.  If no attribute matches, noth‐
703                     ing else is done.
704
705       Values
706              The value can be an attribute reference,  or  an  attribute-spe‐
707              cific string.
708
709              When  the value is an attribute reference, it must take the form
710              of "&Attribute-Name".  The leading "&" signifies that the  value
711              is a reference.  The "Attribute-Name" is an attribute name, such
712              as "User-Name" or "request:User-Name".  When an attribute refer‐
713              ence is used, both attributes must have the same data type.  For
714              example, "User-Name := &NAS-Port"  is  invalid,  because  "User-
715              Name" is a string, and "NAS-Port" is an integer.
716
717              We  recommend  using  the  form "Attribute-1 = &Attribute-2" for
718              updates, instead of "Attribute-1 = "%{Attribute-2}".  The  first
719              version  will  copy the attribute data, no matter what its form.
720              The second version will print the Attribute-2 to a  string,  and
721              then  parse it to create the value for Attribute-1.  This second
722              version is slower and more fragile than the first one.
723
724              When the value is an attribute-specific  string,  it  can  be  a
725              string,  integer, IP address, etc.  The value may be expanded as
726              described above in the DATA TYPES section, above.  For  example,
727              specifying   "Framed-IP-Address  =  127.0.0.1"  will  cause  the
728              "Framed-IP-Address" attribute  to  be  set  to  the  IP  address
729              "127.0.0.1".   However, using "Framed-IP-Address := module to be
730              run with a string "127.0.0.1".  The output of the "echo"  module
731              will  then  be  parsed  as  an  IP  address, and placed into the
732              Framed-IP-Address attribute.
733
734              This flexibility means that you can  assign  an  IP  address  by
735              specifying it directly, or by having the address returned from a
736              database query, or by having the address returned as the  output
737              of a program that is executed.
738
739              When  string  values  are finally assigned to an attribute, they
740              can have a maximum length of 253 characters.  This limit is  due
741              in part to both protocol and internal server requirements.  That
742              is, the strings in the language can be nearly 8k in length,  say
743              for  a  long  SQL  query.  However, the output of that SQL query
744              should be no more than 253 characters in length.
745

OTHER KEYWORDS

747       Other keywords in the language are taken  from  the  names  of  modules
748       loaded  by  the  server.  These keywords are dependent on both the mod‐
749       ules, and the local configuration.
750
751       Some use keywords that are defined in the  default  configuration  file
752       are:
753
754       fail   Cause  the  request  to  be treated as if a database failure had
755              occurred.
756
757       noop   Do nothing.  This also serves as an instruction to  the  config‐
758              urable  failover  tracking  that nothing was done in the current
759              section.
760
761       ok     Instructs the server that the request  was  processed  properly.
762              This  keyword  can be used to over-ride earlier failures, if the
763              local administrator determines that the faiures  are  not  cata‐
764              strophic.
765
766       reject Causes the request to be immediately rejected
767

MODULE RETURN CODES

769       When  a  module  is  called,  it  returns one of the following codes to
770       "unlang", with the following meaning.
771
772            notfound        information was not found
773            noop            the module did nothing
774            ok              the module succeeded
775            updated         the module updated the request
776            fail            the module failed
777            reject          the module rejected the request
778            userlock        the user was locked out
779            invalid         the configuration was invalid
780            handled         the module has handled the request itself
781
782       These return codes can be tested for in a condition, as described above
783       in the CONDITIONS section.
784
785       See  also  the file doc/configurable_failover for additional methods of
786       trapping and modifying module return codes.
787

FILES

789       /etc/raddb/radiusd.conf
790

SEE ALSO

792       radiusd.conf(5), dictionary(5)
793

AUTHOR

795       Alan DeKok <aland@deployingradius.com>
796
797
798
799                               06 December 2017                      unlang(5)
Impressum