1unlang(5) FreeRADIUS Processing un-language unlang(5)
2
6 unlang - FreeRADIUS Processing un-language
7
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 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 be‐
17 ing processed. Requests are processed through virtual servers (includ‐
18 ing the default one), in the sections titled "authorize", "authenti‐
19 cate", "post-auth", "preacct", "accounting", "pre-proxy", "post-proxy",
20 and "session".
21 These policies cannot be used in any other part of the configuration
23 files, such as module or client configuration.
24
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 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 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 chap # call the CHAP module
46 sql # call the SQL module
47 ...
48 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 if (condition) {
56 ...
57 }
58 else
60 Define a block to be executed only if the previous "if" condi‐
61 tion returned false.
62 else {
64 ...
65 }
66 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 elsif (condition) {
73 ...
74 }
75 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 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 foreach &Attribute-Reference {
93 ...
94 }
95 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 ig‐
102 nored. A default "case" statement can be defined, by omitting
103 its argument.
104 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 ex‐
108 pansion. If the argument is an attribute reference (e.g. &User-
109 Name), then the match is performed on the value of that attri‐
110 bute. Otherwise, the argument is taken to be a literal string,
111 and matching is done via simple comparison.
112 No statement other than "case" can appear in a "switch" block.
114 switch <argument> {
116 ...
117 }
118 case
120 Provides a place-holder which matches the argument of a parent
121 "switch" statement.
122 A "case" statement cannot appear outside of a "switch" block.
124 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 ex‐
128 pansion. If the argument is an attribute reference (e.g. &User-
129 Name), then the match is performed on the value of that attri‐
130 bute. Otherwise, the argument is taken to be a literal string,
131 and matching is done via simple comparison.
132 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" en‐
137 try matches. Only one default entry can exist in a "switch"
138 section.
139 case {
141 ...
142 }
143 update
145 Update a particular attribute list, based on the attributes
146 given in the current block.
147 update <list> {
149 &Attribute-Reference = value
150 ...
151 } The <list> can be one of "request", "reply", "proxy-re‐
152 quest", "proxy-reply", "coa", "disconnect", "session-state", or
153 "control". As of Version 3, the <list> can be omitted, in which
154 case "request" is assumed.
155 The "control" list is the list of attributes maintained 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 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 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 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 Ac‐
175 cess-Request or Accounting-Request has been finished, and a re‐
176 ply sent to the NAS. See raddb/sites-available/originate-coa
177 for additional information.
178 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 The only contents permitted in an "update" section are at‐
185 tributes and values. The contents of the "update" section are
186 described in the ATTRIBUTE REFERENCE and ATTRIBUTE ASSIGNMENT
187 sections below.
188 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 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 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 redundant {
204 sql1 # try this
205 sql2 # try this only if sql1 fails.
206 ...
207 }
208 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 be‐
214 have identically, otherwise the load-balance section will return
215 different results for the same request.
216 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 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 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 re‐
233 quest. This process repeats until one module succeeds, or until
234 the list has been exhausted.
235 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 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 raddb/ra‐
244 diusd.conf "instantiate" section for more configuration exam‐
245 ples.
246 redundant-load-balance {
248 ldap1 # 50%, unless ldap2 is down, then 100%
249 ldap2 # 50%, unless ldap1 is down, then 100%
250 }
251 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 authorize {
258 if (...) {
259 ...
260 return
261 }
262 ... # this is never reached when the "if"
263 ... # statement is executed
264 }
265
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 "up‐
273 date" section, above. The "<list>:" prefix is optional, and if omit‐
274 ted, is assumed to refer to the "request" list.
275 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 at‐
278 tributes which are marked in the dictionary as "has_tag".
279 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 If '*' is used in the NUM portion, it evaluates to all instances of the
286 attribute in the request.
287 If 'n' is used in the NUM portion, it evaluates to the last instance of
289 the attribute in the request.
290 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 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 Once the attribute is instantiated, it is added to a list. It can then
312 be referenced, updated, replaced, etc.
313
316 The conditions are similar to C conditions in syntax, though quoted
317 strings are supported, as with the Unix shell.
318 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 comparing strings
325 to an empty string, rather than by evaluating the string by it‐
326 self.
327 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 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, be‐
338 low.
339 Negation
341 (!foo) Evaluates to true if 'foo' evaluates to false, and
342 vice-versa.
343 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 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
357 operators, and are not allowed for comparisons.
358 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 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 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 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 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 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 We recommend using attribute references instead of printing at‐
396 tributes to a string, e.g. (User-Name == "%{Filter-Id}"). At‐
397 tribute references will be faster and more efficient.
398 The conditions will check only the first occurrence of an attri‐
400 bute. If there is more than one instance of an attribute, the
401 following syntax should be used:
402 (&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 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 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 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 Casts are allowed only on the left-hand side argument of a con‐
426 dition.
427 Conditions may be nested to any depth, subject only to line length lim‐
429 itations (8192 bytes).
430
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 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 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 at‐
449 tribute. On the right hand side, it is interpreted as a simple
450 string, in the same manner as a single-quoted string.
451 Using attribute references permits limited type-specific compar‐
453 isons, as seen in the examples below.
454 if (&User-Name == "bob") {
456 ...
457 if (&Framed-IP-Address > 127.0.0.1) {
458 ...
459 if (&Service-Type == Login-User) {
460 "strings"
462 Double-quoted strings are expanded by inserting the value of any
463 attributes (see ATTRIBUTE REFERENCES, below) before being evalu‐
464 ated. If the result is a number it is evaluated in a numerical
465 context.
466 String length is limited by line-length, usually about 8000
468 characters. A double quote character can be used in a string
469 via the normal back-slash escaping method. ("like \"this\" !")
470 'strings'
472 Single-quoted strings are evaluated as-is. Their values are not
473 expanded as with double-quoted strings above, and they are not
474 interpreted as attribute references.
475 `strings`
477 Back-quoted strings are evaluated by expanding the contents of
478 the string, as described above for double-quoted strings. The
479 resulting command given inside of the string in a sub-shell, and
480 taking the output as a string. This behavior is much the same
481 as that of Unix shells.
482 Note that for security reasons, the input string is split into
484 command and arguments before string expansion is done.
485 For performance reasons, we suggest that the use of back-quoted
487 strings be kept to a minimum. Executing external programs is
488 relatively expensive, and executing a large number of programs
489 for every request can quickly use all of the CPU time in a
490 server. If you believe that you need to execute many programs,
491 we suggest finding alternative ways to achieve the same result.
492 In some cases, using a real language may be sufficient.
493 /regex/im
496 These strings are valid only on the right-hand side of a compar‐
497 ison, and then only when the comparison operator is "=~" or
498 "!~". They are regular expressions, as implemented by the local
499 regular expression library on the system. This is usually Posix
500 regular expressions.
501 The trailing 'i' is optional, and indicates that the regular ex‐
503 pression match should be done in a case-insensitive fashion.
504 The trailing 'm' is also optional, and indicates that carrot '^'
506 and dollar '$' anchors should match on new lines as well as at
507 the start and end of the subject string.
508 If the comparison operator is "=~", then parentheses in the reg‐
510 ular expression will define variables containing the matching
511 text, as described below in the ATTRIBUTE REFERENCES section.
512
514 Attributes are expanded using the ATTRIBUTE REFERENCE syntax described
515 above, and surrounding the reference with "%{...}"
516 %{Attribute-Reference}
518 The result will be a string which contains the value of the attribute
520 which was referenced, as a printable string. If the attribute does not
521 exist, the result will be an empty string.
522 Results of regular expression matches
524 If a regular expression match has previously been performed,
525 then the special variable %{0} will contain a copy of the
526 matched portion of the input string. The variables %{1} through
527 %{32} will contain the substring matches, starting from the
528 left-most capture group, onwards. If there are more than 32
529 capture groups, the additional results will not be accessible.
530 If the server is built with libpcre, the results of named cap‐
531 ture groups are available using the "%{regex:capture group}" ex‐
532 pansion. They will also be accessible using the variables de‐
533 scribed above. Every time a regular expression is evaluated,
534 whether it matches or not, the capture group values will be
535 cleared.
536 Obtaining results from databases
538 It is useful to query a database for some information, and to
539 use the result in a condition. The following syntax will call a
540 module, pass it the given string, and replace the string expan‐
541 sion with the resulting string returned from the module.
542 %{module: string ...}
544 The syntax of the string is module-specific. Please read the
546 module documentation for additional details.
547 Conditional Syntax
549 Conditional syntax similar to that used in Unix shells may also
550 be used.
551 %{%{Foo}:-bar}
553 If %{Foo} has a value, returns that value.
554 Otherwise, returns literal string "bar".
555 %{%{Foo}:-%{Bar}}
557 If %{Foo} has a value, returns that value.
558 Otherwise, returns the expansion of %{Bar}.
559 These conditional expansions can be nested to almost any
561 depth, such as with %{%{One}:-%{%{Two}:-%{Three}}}
562 String lengths and arrays
564 Similar to a Unix shell, there are ways to reference string
565 lengths, and the second or more instance of an attribute in a
566 list. If you need more than this functionality, we suggest us‐
567 ing a real language.
568 %{strlen:string}
570 The number of characters in "string". If "string" does
571 not exist, then the length also does not exist, instead
572 of being zero.
573 The "string" is expanded before the length is taken.
575 %{integer:Attribute-Name}
578 The integer value of the Attribute-Name, instead of the
579 enumerated name.
580 e.g. If a request contains "Service-Type = Login-User",
582 the expansion of %{integer:Service-Type} will yield "1".
583 %{hex:Attribute-Name}
586 The hex value of the Attribute-Name, as a series of hex
587 digits.
588 e.g. If a request contains "Framed-IP-Address =
590 127.0.0.1", the expansion of %{hex:Framed-IP-Address}
591 will yield "0x7f000001".
592 %{Attribute-Name[#]}
595 The number of instances of Attribute-Name.
596 e.g. If a request contains "User-Name = bob", the expan‐
598 sion of %{User-Name[#]} will yield "1".
599 %{Attribute-Name[*]}
602 All values of Attribute-Name, concatenated together with
603 ',' as the separator.
604 %{List-Name:[#]}
607 The number of attributes in the named list.
608 %{List-Name:[*]}
611 All values of attributes in the named-list, concatenated
612 together with ',' as the separator. Use the %{pairs:}
613 xlat to get a list of attributes and values.
614 e.g. If a response contains "Reply-Message = 'Hello', Re‐
616 ply-Message = 'bob' the expansion of "%{reply:Reply-Mes‐
617 sage[*]} will yield "Hello\nbob"
618
621 The attribute lists described above may be edited by listing one or
622 more attributes in an "update" section. Once the attributes have been
623 defined, they may be referenced as described above in the ATTRIBUTE
624 REFERENCES section.
625 The following syntax defines attributes in an "update" section. Each
627 attribute and value has to be all on one line in the configuration
628 file. There is no need for commas or semi-colons after the value.
629 Attribute-Reference = value
631 Attribute Reference
633 The Attribute-Reference must be a reference (see above), using a
634 name previously defined in a dictionary. If an undefined name
635 is used, the server will return an error, and will not start.
636 Operators
639 The operator used to assign the value of the attribute may be
640 one of the following, with the given meaning.
641 = Add the attribute to the list, if and only if an attri‐
643 bute of the same name is not already present in that
644 list.
645 := Add the attribute to the list. If any attribute of the
647 same name is already present in that list, its value is
648 replaced with the value of the current attribute.
649 += Add the attribute to the tail of the list, even if at‐
651 tributes of the same name are already present in the
652 list. When the right hand side of the expression resolves
653 to multiple values, it means add all values to the tail
654 of the list.
655 ^= Add the attribute to the head of the list, even if at‐
657 tributes of the same name are already present in the
658 list. When the right hand side of the expression re‐
659 solves to multiple values, it means prepend all values to
660 the head of the list.
661 Enforcement and Filtering Operators
663 The following operators may also be used in addition to the ones
664 listed above. Their function is to perform enforcement or fil‐
665 tering on attributes in a list.
666 -= Remove all matching attributes from the list. Both the
668 attribute name and value have to match in order for the
669 attribute to be removed from the list.
670 == Keep all matching attributes. Both the attribute name
672 and value have to match in order for the attribute to re‐
673 main in the list.
674 Note that this operator is very different than the '='
676 operator listed above!
677 != Keep all attributes with matching name, and value not
679 equal to the given one.
680 < Keep all attributes having values less than the value
682 given here. Any larger value is replaced by the value
683 given here. If no attribute exists, it is added with the
684 value given here, as with "+=".
685 <= Keep all attributes having values less than, or equal to,
687 the value given here. Any larger value is replaced by
688 the value given here. If no attribute exists, it is
689 added with the value given here, as with "+=".
690 > Keep all attributes having values greater than the value
692 given here. Any smaller value is replaced by the value
693 given here. If no attribute exists, it is added with the
694 value given here, as with "+=".
695 >= Keep all attributes having values greater than, or equal
697 to, the value given here. Any smaller value is replaced
698 by the value given here. If no attribute exists, it is
699 added with the value given here, as with "+=".
700 !* Delete all occurrences of the named attribute, no matter
702 what the value.
703 =~ Keep all attributes having values which match the given
705 regular expression. If no attribute matches, nothing
706 else is done.
707 !~ Keep all attributes having values which fail to match the
709 given regular expression. If no attribute matches, noth‐
710 ing else is done.
711 Values
713 The value can be an attribute reference, or an attribute-spe‐
714 cific string.
715 When the value is an attribute reference, it must take the form
717 of "&Attribute-Name". The leading "&" signifies that the value
718 is a reference. The "Attribute-Name" is an attribute name, such
719 as "User-Name" or "request:User-Name". When an attribute refer‐
720 ence is used, both attributes must have the same data type. For
721 example, "User-Name := &NAS-Port" is invalid, because "User-
722 Name" is a string, and "NAS-Port" is an integer.
723 We recommend using the form "Attribute-1 = &Attribute-2" for up‐
725 dates, instead of "Attribute-1 = "%{Attribute-2}". The first
726 version will copy the attribute data, no matter what its form.
727 The second version will print the Attribute-2 to a string, and
728 then parse it to create the value for Attribute-1. This second
729 version is slower and more fragile than the first one.
730 When the value is an attribute-specific string, it can be a
732 string, integer, IP address, etc. The value may be expanded as
733 described above in the DATA TYPES section, above. For example,
734 specifying "Framed-IP-Address = 127.0.0.1" will cause the
735 "Framed-IP-Address" attribute to be set to the IP address
736 "127.0.0.1". However, using "Framed-IP-Address := module to be
737 run with a string "127.0.0.1". The output of the "echo" module
738 will then be parsed as an IP address, and placed into the
739 Framed-IP-Address attribute.
740 This flexibility means that you can assign an IP address by
742 specifying it directly, or by having the address returned from a
743 database query, or by having the address returned as the output
744 of a program that is executed.
745 When string values are finally assigned to an attribute, they
747 can have a maximum length of 253 characters. This limit is due
748 in part to both protocol and internal server requirements. That
749 is, the strings in the language can be nearly 8k in length, say
750 for a long SQL query. However, the output of that SQL query
751 should be no more than 253 characters in length.
752
754 Other keywords in the language are taken from the names of modules
755 loaded by the server. These keywords are dependent on both the mod‐
756 ules, and the local configuration.
757 Some use keywords that are defined in the default configuration file
759 are:
760 fail Cause the request to be treated as if a database failure had oc‐
762 curred.
763 noop Do nothing. This also serves as an instruction to the config‐
765 urable failover tracking that nothing was done in the current
766 section.
767 ok Instructs the server that the request was processed properly.
769 This keyword can be used to over-ride earlier failures, if the
770 local administrator determines that the failures are not cata‐
771 strophic.
772 reject Causes the request to be immediately rejected
774
776 When a module is called, it returns one of the following codes to "un‐
777 lang", with the following meaning.
778 notfound information was not found
780 noop the module did nothing
781 ok the module succeeded
782 updated the module updated the request
783 fail the module failed
784 reject the module rejected the request
785 userlock the user was locked out
786 invalid the configuration was invalid
787 handled the module has handled the request itself
788 These return codes can be tested for in a condition, as described above
790 in the CONDITIONS section.
791 See also the file doc/configurable_failover for additional methods of
793 trapping and modifying module return codes.
794
796 /etc/raddb/radiusd.conf
797
799 radiusd.conf(5), dictionary(5)
800
802 Alan DeKok <aland@deployingradius.com>
803 16 February 2021 unlang(5)