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
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 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
102 ignored. 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
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 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
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 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 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-
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 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 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
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 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
185 attributes 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
214 behave identically, otherwise the load-balance section will
215 return 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
233 request. This process repeats until one module succeeds, or
234 until 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
244 raddb/radiusd.conf "instantiate" section for more configuration
245 examples.
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
273 "update" section, above. The "<list>:" prefix is optional, and if
274 omitted, 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
278 attributes 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 comparings strings
325 to an empty string, rather than by evaluating the string by
326 itself.
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,
338 below.
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 oper‐
357 ators, 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
396 attributes to a string, e.g. (User-Name == "%{Filter-Id}").
397 Attribute references will be faster and more efficient.
398 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 (&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
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 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 VARIABLES, below) before being evaluated. If
464 the result is a number it is evaluated in a numerical context.
465 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 '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 `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 Note that for security reasons, the input string is split into
483 command and arguments before string expansion is done.
484 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 /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 The trailing 'i' is optional, and indicates that the regular
502 expression match should be done in a case-insensitive fashion.
503 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 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
513 Attributes are expanded using the ATTRIBUTE REFERENCE syntax described
514 above, and surrounding the reference with "%{...}"
515 %{Attribute-Reference}
517 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 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 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 %{module: string ...}
543 The syntax of the string is module-specific. Please read the
545 module documentation for additional details.
546 Conditional Syntax
548 Conditional syntax similar to that used in Unix shells may also
549 be used.
550 %{%{Foo}:-bar}
552 If %{Foo} has a value, returns that value.
553 Otherwise, returns literal string "bar".
554 %{%{Foo}:-%{Bar}}
556 If %{Foo} has a value, returns that value.
557 Otherwise, returns the expansion of %{Bar}.
558 These conditional expansions can be nested to almost any
560 depth, such as with %{%{One}:-%{%{Two}:-%{Three}}}
561 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 %{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 The "string" is expanded before the length is taken.
574 %{integer:Attribute-Name}
577 The integer value of the Attribute-Name, instead of the
578 enumerated name.
579 e.g. If a request contains "Service-Type = Login-User",
581 the expansion of %{integer:Service-Type} will yield "1".
582 %{hex:Attribute-Name}
585 The hex value of the Attribute-Name, as a series of hex
586 digits.
587 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 %{Attribute-Name[#]}
594 The number of instances of Attribute-Name.
595 e.g. If a request contains "User-Name = bob", the expan‐
597 sion of %{User-Name[#]} will yield "1".
598 %{Attribute-Name[*]}
601 All values of Attribute-Name, concatenated together with
602 ',' as the separator.
603 %{List-Name:[#]}
606 The number of attributes in the named list.
607 %{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 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
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 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 Attribute-Reference = value
630 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 Operators
638 The operator used to assign the value of the attribute may be
639 one of the following, with the given meaning.
640 = 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 := 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 += 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 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 -= 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 == 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 Note that this operator is very different than the '='
669 operator listed above!
670 != Keep all attributes with matching name, and value not
672 equal to the given one.
673 < 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 <= 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 > 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 >= 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 !* Delete all occurrences of the named attribute, no matter
695 what the value.
696 =~ Keep all attributes having values which match the given
698 regular expression. If no attribute matches, nothing
699 else is done.
700 !~ 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 Values
706 The value can be an attribute reference, or an attribute-spe‐
707 cific string.
708 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 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 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 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 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
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 Some use keywords that are defined in the default configuration file
752 are:
753 fail Cause the request to be treated as if a database failure had
755 occurred.
756 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 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 reject Causes the request to be immediately rejected
767
769 When a module is called, it returns one of the following codes to
770 "unlang", with the following meaning.
771 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 These return codes can be tested for in a condition, as described above
783 in the CONDITIONS section.
784 See also the file doc/configurable_failover for additional methods of
786 trapping and modifying module return codes.
787
789 /etc/raddb/radiusd.conf
790
792 radiusd.conf(5), dictionary(5)
793
795 Alan DeKok <aland@deployingradius.com>
796 06 December 2017 unlang(5)