1radsecproxy.conf(5)                                        radsecproxy.conf(5)
2
3
4

NAME

6       radsecproxy.conf - Radsec proxy configuration file
7
8

DESCRIPTION

10       When  the proxy server starts, it will first check the command line ar‐
11       guments, and then read the  configuration  file.  Normally  radsecproxy
12       will  read  the  configuration  file /etc/radsecproxy.conf. The command
13       line -c option can be used to instead read an alternate file (see  rad‐
14       secproxy(8) for details).
15
16       If the configuration file can not be found, the proxy will exit with an
17       error message. Note that there is also an include facility so that  any
18       configuration  file  may  include  other configuration files. The proxy
19       will also exit on configuration errors.
20
21

CONFIGURATION SYNTAX

23       When the configuration file is processed, whitespace (spaces and  tabs)
24       are  generally  ignored. For each line, leading and trailing whitespace
25       are ignored.  A line is ignored if it is empty, only consists of white‐
26       space,  or if the first non-whitespace character is a #. The configura‐
27       tion is generally case insensitive, but in some cases the option values
28       (see below) are not.
29
30       There  are  two types of configuration structures than can be used. The
31       first and simplest are lines on the format option value.  That  is,  an
32       option  name, see below for a list of valid options, followed by white‐
33       space (at least one space or tab character), followed by a value.  Note
34       that  if the value contains whitespace, then it must be quoted using ""
35       or ''. Any whitespace in front of the option or after the value will be
36       ignored.
37
38       The  other  type  of  structure  is a block. A block spans at least two
39       lines, and has the format:
40
41              blocktype name {
42                   option value
43                   option value
44                   ...
45              }
46
47
48       That is, some blocktype, see below for a list of  the  different  block
49       types,  and  then  enclosed  in braces you have zero or more lines that
50       each have the previously described option value format. Different block
51       types have different rules for which options can be specified, they are
52       listed below. The rules regarding white space, comments and quotes  are
53       as above. Hence you may do things like:
54
55              blocktype name {
56              #    option value
57                  option "value with space"
58                  ...
59              }
60
61
62       Option  value characters can also be written in hex for options requir‐
63       ing a string type value. This is done by writing the character  %  fol‐
64       lowed  by  two hexadecimal digits. If a % is used without two following
65       hexadecimal digits, the % and the  following  characters  are  used  as
66       written. If you want to write a % and not use this decoding, you may of
67       course write % in hex; i.e., %25. As %00 would terminate a string, this
68       value  is  not  converted  in most cases, except when used with rewrite
69       statements or secrets.
70
71       Some options allow or require the use of regular  expressions,  denoted
72       as regex. The POSIX extended RE system is used, see re_format(7).
73
74       There is one special option that can be used both as a basic option and
75       inside all blocks. That is the option Include where the value specifies
76       files  to  be  included.  The value can be a single file, or it can use
77       normal shell globbing to specify multiple files, e.g.:
78
79              include /etc/radsecproxy.conf.d/*.conf
80
81       The files are sorted alphabetically. Included files are read in the or‐
82       der  they are specified, when reaching the end of a file, the next file
83       is read. When reaching the end of the last included file, the proxy re‐
84       turns  to  read  the  next  line following the Include option. Included
85       files may again include other files.
86
87

BASIC OPTIONS

89       The following basic options may be specified in the configuration file.
90       Note  that  blocktypes  and  options inside blocks are discussed later.
91       Note that none of these options are required, and indeed in many  cases
92       they  are  not  needed. Note that you should specify each at most once.
93       The behaviour with multiple occurrences is undefined.
94
95       PidFile file
96              The PidFile option specifies the name of a  file  to  which  the
97              process  id  (PID) will be written. This is overridden by the -i
98              command line option.  There is no default value for the  PidFile
99              option.
100
101       LogLevel 1-5
102              This  option  specifies the debug level. It must be set to 1, 2,
103              3, 4 or 5, where 1 logs only serious errors, and 5  logs  every‐
104              thing.  The  default  is 2 which logs errors, warnings and a few
105              informational messages. Note that the  command  line  option  -d
106              overrides this.
107
108       LogDestination (file|syslog)
109              This  specifies where the log messages should go. By default the
110              messages go to syslog with facility LOG_DAEMON. Using  this  op‐
111              tion you can specify another syslog facility, or you may specify
112              that logging should be to a particular file, not  using  syslog.
113              The    value    must    be    either    a    file    URL    like
114              file:///path/to/your/logfile.log or a syslog URL using the  syn‐
115              tax: x-syslog:///FACILITY where FACILITY must be one of LOG_DAE‐
116              MON, LOG_MAIL,  LOG_USER,  LOG_LOCAL0,  LOG_LOCAL1,  LOG_LOCAL2,
117              LOG_LOCAL3,  LOG_LOCAL4,  LOG_LOCAL5,  LOG_LOCAL6or  LOG_LOCAL7.
118              You may omit the facility from the URL to specify logging to the
119              default  facility, but this is not very useful since this is the
120              default log destination. Note that this option is ignored if  -f
121              is specified on the command line.
122
123       LogThreadId (on|off)
124              This  can  be set to on to include the thread-id in the log mes‐
125              sages (useful for debugging).
126
127
128       LogFullUsername (on|off)
129              This can be set to off to  only  log  the  realm  in  Access-Ac‐
130              cept/Reject log messages (for privacy).
131
132       LogMAC opt
133              The LogMAC option can be used to control if and how Calling-Sta‐
134              tion-Id (the users Ethernet MAC address) is being logged. It can
135              be  set  to  one  of  Static, Original, VendorHashed, VendorKey‐
136              Hashed, FullyHashed or FullyKeyHashed.  The  default  value  for
137              LogMAC is Original.
138
139              See radsecproxy.conf-example for details.
140
141       LogKey key
142              The LogKey option is used to specify the key to use when produc‐
143              ing HMAC's as an effect of specifying  VendorKeyHashed  or  Ful‐
144              lyKeyHashed for the LogMAC option.
145
146       FTicksReporting fticks
147              The FTicksReporting option is used to enable F-Ticks logging and
148              can be set to None, Basic or Full.  Its default value  is  None.
149              If FTicksReporting is set to anything other than None, note that
150              the default value for FTicksMAC needs FTicksKey to be set.
151
152              See radsecproxy.conf-example for details.
153
154       FTicksMAC opt
155              The FTicksMAC option has the same function as LogMAC for FTicks.
156              The   default  for  FTicksMAC  is  VendorKeyHashed  which  needs
157              FTicksKey to be set.
158
159              Before choosing any of Original,  FullyHashed  or  VendorHashed,
160              consider  the  implications  for user privacy when MAC addresses
161              are collected. How will the logs be stored, transferred and  ac‐
162              cessed?
163
164       FTicksKey key
165              The FTicksKey option has the same function as LogKey for Fticks.
166
167       FTicksSyslogFacility syslog
168              The  FTicksSyslogFacility  option is used to specify a dedicated
169              syslog facility for F-Ticks messages.  This  allows  for  easier
170              filtering of F-Ticks messages. If no FTicksSyslogFacility option
171              is given, F-Ticks messages are written to what  the  LogDestina‐
172              tion option specifies.
173
174              F-Ticks  messages  are always logged using the log level LOG_DE‐
175              BUG. Note that specifying a file in FTicksSyslogFacility  (using
176              the file:/// prefix) is not supported.
177
178       FTicksPrefix prefix
179              The  FTicksPrefix option is used to set the prefix printed in F-
180              Ticks messages. This allows for use of F-Ticks messages in  non-
181              eduroam  environments.   If  no FTicksPrefix option is given, it
182              defaults to the prefix used for eduroam (F-TICKS/eduroam/1.0).
183
184
185       ListenUDP (address|*)[:port]
186       ListenTCP (address|*)[:port]
187       ListenTLS (address|*)[:port]
188       ListenDTLS (address|*)[:port]
189              Listen for the address and port  for  the  respective  protocol.
190              Normally  the proxy will listen to the standard ports if config‐
191              ured to handle clients with the respective protocol. The default
192              ports  are  1812  for  UDP and TCP and 2083 for TLS and DTLS. On
193              most systems it will do this for all  of  the  system's  IP  ad‐
194              dresses  (both  IPv4  and IPv6). On some systems however, it may
195              respond to only IPv4 or only IPv6. To specify an alternate  port
196              you  may  use a value on the form *:port where port is any valid
197              port number. If you also want to specify a specific address  you
198              can  do  e.g.   192.168.1.1:1812 or [2001:db8::1]:1812. The port
199              may be omitted if you want the default one. Note that  you  must
200              use brackets around the IPv6 address. These options may be spec‐
201              ified multiple times to  listen  to  multiple  addresses  and/or
202              ports for each protocol.
203
204       SourceUDP (address|*)[:port]
205       SourceTCP (address|*)[:port]
206       SourceTLS (address|*)[:port]
207       SourceDTLS (address|*)[:port]
208              This  can  be  used to specify source address and/or source port
209              that the proxy will use for connecting to clients to  send  mes‐
210              sages  (e.g.  Access  Request). The same syntax as for Listen...
211              applies.
212
213       TTLAttribute (attr|vendor:attr)
214              This can be used to  change  the  default  TTL  attribute.  Only
215              change this if you know what you are doing. The syntax is either
216              a numerical value denoting the TTL attribute, or  two  numerical
217              values separated by column specifying a vendor attribute.
218
219       AddTTL 1-255
220              If  a  TTL  attribute  is  present, the proxy will decrement the
221              value and discard the message if zero. Normally the  proxy  does
222              nothing  if  no  TTL attribute is present. If you use the AddTTL
223              option with a value 1-255, the proxy  will,  when  forwarding  a
224              message with no TTL attribute, add one with the specified value.
225              Note that this option can also be specified for a  client/server
226              which  will  override  this setting when forwarding a message to
227              that client/server.
228
229       LoopPrevention (on|off)
230              When this is enabled (on), a request will never  be  sent  to  a
231              server  named the same as the client it was received from. I.e.,
232              the names of the client block and the server block are compared.
233              Note  that  this only gives limited protection against loops. It
234              can be used as a basic option and inside server blocks where  it
235              overrides the basic setting.
236
237       IPv4Only (on|off)
238       IPv6Only (on|off)
239              Enabling IPv4Only or IPv6Only (on) makes radsecproxy resolve DNS
240              names to the corresponding address  family  only,  and  not  the
241              other. This is done for both clients and servers. At most one of
242              IPv4Only and IPv6Only can be enabled.  Note  that  this  can  be
243              overridden in client and server blocks, see below.
244
245       Include file
246              This  is  not a normal configuration option; it can be specified
247              multiple times.  It can both be used as a basic option  and  in‐
248              side  blocks.  For  the  full description, see the configuration
249              syntax section above.
250
251

BLOCKS

253       There are five types of blocks, they are client, server, realm, tls and
254       rewrite.  At least one instance of each of client and realm is required
255       for the proxy to do anything useful, and it will exit if none are  con‐
256       figured.  The  tls block is required if at least one TLS/DTLS client or
257       server is configured. Note that there can be multiple blocks  for  each
258       type.  For  each  type, the block names should be unique. The behaviour
259       with multiple occurrences of the same name for the same block  type  is
260       undefined.  Also  note  that  some  block option values may reference a
261       block by name, in which case the block name must be previously defined.
262       Hence the order of the blocks may be significant.
263
264

CLIENT BLOCK

266       client (name|fqdn|(address[/length])) {
267            ...
268       }
269
270       The client block is used to configure a client. That is, tell the proxy
271       about a client, and what parameters should be used for that client. The
272       name of the client block must (with one exception, see below) be either
273       the IP address (IPv4 or IPv6) of the client,  an  IP  prefix  (IPv4  or
274       IPv6)  on the form IpAddress/PrefixLength, or a domain name (FQDN). The
275       way an FQDN is resolved into an IP address may be influenced by the use
276       of  the IPv4Only and IPv6Only options. Note that literal IPv6 addresses
277       must be enclosed in brackets.
278
279       If a domain name is specified, then this will be  resolved  immediately
280       to  all  the addresses associated with the name, and the proxy will not
281       care about any possible DNS changes that might occur later. Hence there
282       is  no dependency on DNS after startup. However, if the name can not be
283       resolved, startup will fail.
284
285       When some client later sends a request to the  proxy,  the  proxy  will
286       look  at the IP address the request comes from, and then go through all
287       the addresses of each of the configured clients (in the order they  are
288       defined),  to determine which (if any) of the clients this is. When us‐
289       ing the IpAddress/PrefixLength form, this might  mask  clients  defined
290       later, which then will never be matched.
291
292       In  the case of TLS/DTLS, the name of the client must match the FQDN or
293       IP address in the client certificate (CN or SubectAltName:DNS  or  Sub‐
294       jectAltName:IP  respectively)  and  any MatchCertificateAttribute to be
295       positively identified.  Note that no FQDN/IP is checked when  using  an
296       IP  prefix.   If  overlapping  clients are defined (see section above),
297       they will be searched  for  positive  identification,  but  only  among
298       clients  referencing the same tls block (selected by the first matching
299       IP address or prefix).
300
301       The allowed options in a client block are:
302
303       Host (fqdn|(address[/length]))
304              Alternatively of specifying the FQDN or  address  in  the  block
305              name,   the  host option may be used. In that case, the value of
306              the host option is used as described above, while  the  name  of
307              the block is only used as a descriptive name for the administra‐
308              tor. The host option may be used multiple times, and  can  be  a
309              mix of addresses, FQDNs and prefixes.
310
311       IPv4Only (on|off)
312       IPv6Only (on|off)
313              Enabling IPv4Only or IPv6Only (on) makes radsecproxy resolve DNS
314              names to the corresponding address  family  only,  and  not  the
315              other. At most one of IPv4Only and IPv6Only can be enabled. Note
316              that this will override the global option for this client.
317
318       Type type
319              Specify the type (protocol) of the client. Available options are
320              UDP, TCP, TLS and DTLS.
321
322       Secret secret
323              Use secret as the shared RADIUS key with this client. If the se‐
324              cret contains whitespace, the value must be quoted. This  option
325              is  optional  for  TLS/DTLS and if omitted will default to "rad‐
326              sec". (Note that using a secret other than "radsec" for TLS is a
327              violation of the standard (RFC 6614) and that the proposed stan‐
328              dard for DTLS stipulates that the secret must be "radius/dtls".)
329
330       TLS tls
331              For a TLS/DTLS client you may also specify the tls  option.  The
332              option value must be the name of a previously defined TLS block.
333              If this option is not specified, the TLS block with the name de‐
334              faultClient  or default will be used if defined (in that order).
335              If the specified TLS block name does not exist, or the option is
336              not  specified  and  none  of the defaults exist, the proxy will
337              exit with an error.
338
339       CertificateNameCheck (on|off)
340              For a TLS/DTLS client, disable the default behaviour of matching
341              CN  or  SubjectAltName  against the specified hostname or IP ad‐
342              dress.
343
344       MatchCertificateAttribute CN:/regexp/
345       MatchCertificateAttribute SubjectAltName:DNS:/regexp/
346       MatchCertificateAttribute SubjectAltName:URI:/regexp/
347       MatchCertificateAttribute SubjectAltName:IP:address
348       MatchCertificateAttribute SubjectAltName:rID:oid
349       MatchCertificateAttribute SubjectAltName:otherName:oid:/regexp/
350              Perform additional validation of  certificate  attributes.  Cur‐
351              rently  matching  of  CN  and SubjectAltName types URI, DNS, IP,
352              rID, and otherName is supported. If  specified  multiple  times,
353              all terms must match for the certificate to be considered valid.
354
355       DuplicateInterval seconds
356              Specify  for how many seconds duplicate checking should be done.
357              If a proxy receives a new request within a few seconds of a pre‐
358              vious  one,  it may be treated the same if from the same client,
359              with the same authenticator etc. The proxy will then ignore  the
360              new request (if it is still processing the previous one), or re‐
361              turned a copy of the previous reply.
362
363       AddTTL 1-255
364              The AddTTL option has the same meaning as the option used in the
365              basic  config.   See  the BASIC OPTIONS section for details. Any
366              value configured here overrides the basic one when sending  mes‐
367              sages to this client.
368
369       TCPKeepalive (on|off)
370              Enable TCP keepalive (default is off). If keepalives are not an‐
371              swered within 30s the connection is considered lost.
372
373       FticksVISCOUNTRY cc
374              Sets this client to be eligible to F-Ticks logging as defined by
375              the  FTicksReporting  basic option, and specifies the country to
376              be reported.  The country should be specified by the  two-letter
377              country code.
378
379       FticksVISINST institution
380              Set the institution to report in F-Ticks logging. If this option
381              is omitted, the name of the client block is used.
382
383       Rewrite rewrite
384              This option is deprecated. Use rewriteIn instead.
385
386       RewriteIn rewrite
387       RewriteOut rewrite
388              Apply the operations in the specified rewrite block on  incoming
389              (request)  or  outgoing  (response)  messages  from this client.
390              Rewriting incoming messages is done before, outgoing after other
391              processing.  If  the  RewriteIn  is  not configured, the rewrite
392              blocks defaultClient or default will be applied if  defined.  No
393              default blocks are applied for RewriteOut.
394
395       RewriteAttribute User-Name:/regex/replace/
396              Rewrite  the User-Name attribute in a client request for the re‐
397              quest forwarded by the proxy. The User-Name attribute is written
398              back  to the original value if a matching response is later sent
399              back to the client. Example usage:
400
401              RewriteAttribute User-Name:/^(.*)@local$/\1@example.com/
402
403
404

SERVER BLOCK

406       server (name|((fqdn|address)[:port])) {
407            ...
408       }
409
410       The server block is used to configure a server. That is, tell the proxy
411       about  a  server, and what parameters should be used when communicating
412       with that server.  The name of the server block must (with  one  excep‐
413       tion, see below) be either the IP address (IPv4 or IPv6) of the server,
414       or a domain name (FQDN). If a domain name is specified, then this  will
415       be  resolved immediately to all the addresses associated with the name,
416       and the proxy will not care about any possible DNS changes  that  might
417       occur  later. Hence there is no dependency on DNS after startup. If the
418       domain name resolves to multiple addresses, then for UDP/DTLS the first
419       address is used. For TCP/TLS, the proxy will loop through the addresses
420       until it can connect to one of them. The way an FQDN is  resolved  into
421       an IP address may be influenced by the use of the IPv4Only and IPv6Only
422       options.
423
424       In the case of TLS/DTLS, the name of the server must match the FQDN  or
425       IP address in the server certificate.
426
427       Note that the fqdn or address may include a port number (separated with
428       a column). This port number will then override the default  port  or  a
429       port  option in the server block. Also note that literal IPv6 addresses
430       must be enclosed in brackets.
431
432       The allowed options in a server block are:
433
434       Host (fqdn|address)[:port]
435              Alternatively of specifying the FQDN or  address  in  the  block
436              name the host option may be used. In that case, the value of the
437              host option is used as described above, while the  name  of  the
438              block  is only used as a descriptive name for the administrator.
439              Note that multiple host options may be used. This will  then  be
440              treated  as  multiple  names/addresses for the same server. When
441              initiating a TCP/TLS connection, all addresses of all names  may
442              be  attempted,  but  there  is no failover between the different
443              host values. For failover use separate server blocks.
444
445       Port port
446              Specify the port (UDP/TCP) to connect to. If  omitted,  UDP  and
447              TCP  will  default  to  1812  while TLS and DTLS will default to
448              2083.
449
450       Source (address|*)[:port]
451              Specify the source address and/or port to use for  this  server.
452              See Source...  options above.
453
454       DynamicLookupCommand command
455              Execute  the command to dynamically configure a server. The exe‐
456              cutable file should be given with full path and will be  invoked
457              with  the  name  of the realm as its first and only argument. It
458              should either print a valid server {...} option  on  stdout  and
459              exit  with a code of 0 or print nothing and exit with a non-zero
460              exit code.
461
462              If the command exited with 0 an provided a valid server  config,
463              it  will  be  combined with the statements in this server block,
464              with the values returned by the command taking preference.
465
466              An example of a shell script resolving the DNS NAPTR records for
467              the  realm  and then the SRV records for each NAPTR matching 'x-
468              eduroam:radius.tls' is provided in tools/naptr-eduroam.sh.
469
470       StatusServer (on|off|minimal|auto)
471              Enable the use of status-server messages for  this  server  (de‐
472              fault  off).   If  statusserver  is enabled (on), the proxy will
473              send regular status-server messages to the server to verify that
474              it is alive. Status tracking of the server will solely depend on
475              status-server message and ignore lost requests. This should only
476              be  enabled  if  the server supports it. With the option minimal
477              status-server messages are only sent when regular requests  have
478              been lost and no other replies have been received.
479
480              The  option  auto  tries to detect whether the other server sup‐
481              ports status-server. If so, status-server messages  are  enabled
482              in minimal mode.
483
484       RetryCount count
485              Set  how  many times the proxy should retry sending a request to
486              the server. Default is 2 retries.  Please note that  Radius  re‐
487              tries are normally done by the NAS.
488
489       RetryInterfval interval
490              Set the interval between each retry. Default is 5s.
491
492       Rewrite rewrite
493              This option is deprecated. Use rewriteIn instead.
494
495       RewriteOut rewrite
496       RewriteIn rewrite
497              Apply  the operations in the specified rewrite block on outgoing
498              (request) or incoming (response) messages to/from  this  server.
499              Rewriting outgoing messages is done after, incoming before other
500              processing. If the RewriteIn  is  not  configured,  the  rewrite
501              blocks  defaultServer  or default will be applied if defined. No
502              default blocks are applied for RewriteOut.
503
504       LoopPrevention (on|off)
505              This overrides the global LoopPrevention option for this server.
506              See section BASIC OPTIONS for details on this option.
507
508       BlockingStartup (on|off)
509              Start  the dynamic server in blocking mode (default off), treat‐
510              ing it as if it was already connected and  enqueue  requests  to
511              this  server.  Queued requests will be sent out when the connec‐
512              tion is established. If however the dynamic lookup or  the  con‐
513              nection  fails, the queued requests will be lost.  (This is only
514              considered for dynamic lookup servers. Ie when DynamicLookupCom‐
515              mand  is specified) Warning: when the dynamic lookup and connec‐
516              tion process is slow, this wil block the  respective  realm  for
517              that time.
518
519       The meaning and syntax of the following options are exactly the same as
520       for the client block. The details are not repeated here.  Please  refer
521       to the definitions in the CLIENT BLOCK section.
522
523       IPv4Only (on|off)
524       IPv6Only (on|off)
525       Type type
526       Secret secret
527       TLS tls
528       CertificateNameCheck (on|off)
529       MatchCertificateAttribute ...
530       AddTTL 1-255
531       TCPKeepalive (on|off)
532
533
534

REALM BLOCK

536       realm (*|realm|/regex/) {
537            ...
538       }
539
540       When  the  proxy  receives  an Access-Request it needs to figure out to
541       which server it should be forwarded. This is done  by  looking  at  the
542       Username  attribute in the request, and matching that against the names
543       of the defined realm blocks. The proxy will match against the blocks in
544       the order they are specified, using the first match if any. If no realm
545       matches, the proxy will simply ignore the  request.  Each  realm  block
546       specifies what the server should do when a match is found.
547
548       The allowed options in a realm block are:
549
550       Server server
551       AccountingServer server
552              Specify  the  server  to which requests for this realm should be
553              forwarded.  server references a previously defined server  block
554              (see the SERVER BLOCK section). Each server and accountingServer
555              can be specified multiple times, or omitted  completely.  If  no
556              server  is  configured,  the proxy will deny all Access-Requests
557              for this realm. If no accountingServer is configured, the  proxy
558              will silently ignore all Accounting-Requests for this realm. See
559              the SERVER SELECTION section below for details.
560
561       AccountingResponse (on|off)
562              Enable sending Accounting-Response instead of ignoring  Account‐
563              ing-Requests when no accoutingServer are configured.
564
565       ReplyMessage message
566              Specify  a message to be sent back to the client if a Access-Re‐
567              quest is denied because no server are configured.
568
569
570   REALM BLOCK NAMES AND MATCHING
571       In the general case the proxy will look for a @ in the username  attri‐
572       bute, and try to do an exact, case insensitive match between what comes
573       after the @ and the name of the realm block. So if you  get  a  request
574       with  the  attribute  value  anonymous@example.com,  the  proxy will go
575       through the realm names in the order they are specified, looking for  a
576       realm block named example.com.
577
578       There  are  two exceptions to this, one is the realm name * which means
579       match everything. Hence if you have a realm block named *, then it will
580       always  match.  This should then be the last realm block defined, since
581       any blocks after this would never be checked. This is useful for having
582       a default.
583
584       The  other  exception is regular expression matching. If the realm name
585       starts with a /, the name is treated as an regular expression.  A  case
586       insensitive  regexp  match  will  then be done using this regexp on the
587       value of the entire Username attribute. Optionally you may also have  a
588       trailing / after the regexp.  So as an example, if you want to use reg‐
589       exp matching the domain example.com you could have a realm block  named
590       /@example\.com$/.  If  you want to match all domains under the .com top
591       domain, you could do /@.*\.com$/. Note that since the matching is  done
592       on   the   entire   attribute  value,  you  can  also  use  rules  like
593       /^[a-k].*@example\.com$/ to get some of the users in this domain to use
594       one  server,  while other users could be matched by another realm block
595       and use another server.
596
597
598   SERVER SELECTION
599       Normally requests will be forwarded to the first server option defined.
600       If  there  are multiple server options, the proxy will do fail-over and
601       use the second server if the first is down. If the two first are  down,
602       it  will  try the third etc. If the first server comes back up, it will
603       go back to using that one.  Detection of servers being up  or  down  is
604       based  on  the  use of StatusServer (if enabled), and that TCP/TLS/DTLS
605       connections are up. Otherwise unanswered requests are  used  to  detect
606       unresponsive servers. AccountingServers are treated the same, but inde‐
607       pendently of the other servers.
608
609       If there is no Server option, the proxy will if ReplyMessage is  speci‐
610       fied,  reply back to the client with an Access Reject message. The mes‐
611       sage contains a replyMessage attribute with the value as  specified  by
612       the  ReplyMessage  option.  Note  that this is different from having no
613       match since then the request is simply ignored.  This can  be  used  to
614       catch all undefined sub-domains or even all undefined realms by config‐
615       uring either a regex match like /@.*\.example\.com/ or the realm * with
616       no  server  option.  Another use-case is to block a specific pattern in
617       the username or realm part using  a regex.
618
619       If there is no AccountingServer option,  the  proxy  will  normally  do
620       nothing, ignoring accounting requests. If instead AccountingResponse is
621       set to on, the proxy will log some of the  accounting  information  and
622       send  an  Accounting-Response back. This stops clients from retransmit‐
623       ting Accounting-Request messages when a realm has  no  accountingServer
624       configured.
625
626

TLS BLOCK

628       tls name {
629            ...
630       }
631
632       The TLS block specifies TLS configuration options and you need at least
633       one of these if you have clients or servers  using  TLS/DTLS.  As  dis‐
634       cussed  in the client and server block descriptions, a client or server
635       block may reference a particular TLS block by name. There are also how‐
636       ever  the  special  TLS block names default, defaultClient and default‐
637       Server which are used as defaults if the client or  server  block  does
638       not  reference  a TLS block. Also note that a TLS block must be defined
639       before the client or server block that would use it. If  you  want  the
640       same  TLS  configuration for all TLS/DTLS clients and servers, you need
641       just a single tls block named default, and the client and servers  need
642       not  refer  to  it. If you want all TLS/DTLS clients to use one config,
643       and all TLS/DTLS servers to use another, then you would  be  fine  only
644       defining  two  TLS blocks named defaultClient and defaultServer. If you
645       want different clients (or different servers) to have different TLS pa‐
646       rameters,  then  you  may  need  to  create other TLS blocks with other
647       names, and reference those from the client or server definitions.
648
649       As both clients and servers need to present and verify  a  certificate,
650       both  a  certificate  as  well  as a CA to verify the peers certificate
651       must be configured.
652
653       The allowed options in a tls block are:
654
655       CACertificateFile file
656              The CA certificate file used to verify the peers certificate.
657
658       CACertificatePath path
659              The path to search for CA or intermediate certificates.
660
661       CertificateFile file
662              The server certificate this proxy will use. The  file  may  also
663              contain a certificate chain.
664
665       CertificateKeyFile file
666              The  private-key  file  for  the server certificate specified in
667              CACertificateFile.
668
669       CertificateKeyPassword password
670              The password to decrypt the private-key.
671
672       PolicyOID oid
673              Require the peers certificate to adhere to the policy  specified
674              by  oid.  When specified multiple times at least one policy must
675              be valid in the peer certificate.
676
677       CRLCheck (on|off)
678              Enable checking peer certificate against the CRL (default off).
679              Note that radsecproxy does not fetch the CRLs itself.  This  has
680              to be done separately, e.g. with fetch-crl(8)
681
682       CacheExpiry seconds
683              Specify  how  many  seconds the CA and CRL information should be
684              cached. By default, the CA and CRL are  loaded  at  startup  and
685              cached  indefinetely.  After the configured time, the CA CRL are
686              re-read. Alternatively, reloading the CA and CRL  can  be  trig‐
687              gered  by  sending a SIGHUP to the radsecproxy process. This op‐
688              tion may be set to zero to disable caching.
689
690       CipherList ciphers
691              Specify the list of accepted ciphers. See openssl-ciphers(1).
692
693       CipherSuites ciphersuites
694              Specify the ciphersuites to be used for TLS1.3. See  openssl-ci‐
695              phers(1).
696              Note this requires OpenSSL 1.1.1
697
698       TlsVersion ( version | minversion:maxversion )
699       DtlsVersion ( version | minversion:maxversion )
700              Specify the TLS/DTLS protocol version to be used.
701              Specify  the  range of allowed protocol versions between minver‐
702              sion and maxversion (inclusive). If either is left out, any ver‐
703              sion  up  to,  or  starting  from  this version is allowed. E.g.
704              "TLS1_2:" will allow TLSv1.2 or later.  If omitted, use the sys‐
705              tem defaults set in openssl.conf
706              Currently  supported  values  are SSL3,TLS1,TLS1_1,TLS1_2,TLS1_3
707              for TLS and DTLS1,DTLS1_1 for DTLS.
708
709       DhFile file
710              DH parameter file to use. See openssl-dhparam(1)
711              Note: starting with OpenSSL 3.0, use of custom DH parameters  is
712              discouraged.
713
714

REWRITE BLOCK

716       rewrite name {
717            ...
718       }
719
720       The  rewrite block specifies rules that may rewrite RADIUS messages. It
721       can be used to add, remove and modify specific attributes from messages
722       received  from  and  sent  to  clients and servers. As discussed in the
723       client and server block descriptions, a client or server block may ref‐
724       erence  a  particular rewrite block by name. There are however also the
725       special rewrite block names default,  defaultClient  and  defaultServer
726       which  are used as defaults if the client or server block does not ref‐
727       erence a block. Also note that a rewrite block must be  defined  before
728       the  client or server block that would use it. If you want the same re‐
729       write rules for input from all clients and servers,  you  need  just  a
730       single rewrite block named default, and the client and servers need not
731       refer to it. If you want all clients to use one config, and all servers
732       to use another, then you would be fine only defining two rewrite blocks
733       named defaultClient and defaultServer. Note  that  these  defaults  are
734       only  used  for rewrite on input. No rewriting is done on output unless
735       explicitly specified using the RewriteOut option.
736
737       The rewrite actions are performed in this sequence:
738              1. RemoveAttribute (or WhitelistAttribute)
739              2. ModifyAttribute
740              3. SupplementAttribute
741              4. AddAttribute
742
743       All options can be specified multiple times. The allowed options  in  a
744       rewrite block are:
745
746       AddAttribute attribute:value
747              Add  an attribute to the radius message and set it to value. The
748              attribute must be specified using the  numerical  attribute  id.
749              The  value can either be numerical, a string, or a hex value. If
750              the value starts with a number, it is interpreted as a 32bit un‐
751              signed  integer.   Use the ' character at the start of the value
752              to force string interpretation. When using hex value, it is rec‐
753              ommended  to also lead with ' to avoid unintended numeric inter‐
754              pretation. See the CONFIGURATION SYNTAX section for further  de‐
755              tails.
756
757       AddVendorAttribute vendor:subattribute:value
758              Add  a vendor attribute to the radius message, specified by ven‐
759              dor and subattribute. Both vendor and subattribute must be spec‐
760              ified  as  numerical  values. The format of value is the same as
761              for addAttribute above.
762
763       SupplementAttribute attribute:value
764              Add an attribute to the radius message and set it to value, only
765              if the  attribute is not yet present on the message.  The format
766              of value is the same as for addAttribute above.
767
768       SupplementVendorAttribute vendor:subattribute:value
769              Add a vendor attribute to the radius message only if the  subat‐
770              tribute  of  this  vendor is not yet present on the message. The
771              format of is the same as for addVendorAttribute above.
772
773       ModifyAttribute attribute:/regex/replace/
774              Modify the given attribute using the regex replace  pattern.  As
775              above, attribute must be specified by a numerical value. Example
776              usage:
777
778              modifyAttribute 1:/^(.*)@local$/\1@example.com/
779
780       ModifyVendorAttribute vendor:subattribute:/regex/replace/
781              Modify the given subattribute of given vendor  using  the  regex
782              replace  pattern.   Other than the added vendor, the same syntax
783              as for ModifyAttribute applies.
784
785       RemoveAttribute attribute
786              Remove all attributes with the given id.
787
788       RemoveVendorAttribute vendor[:subattribute]
789              Remove all vendor attributes that match  the  given  vendor  and
790              subattribute.  If  the  subattribute  is omitted, all attributes
791              with the given vendor id are removed.
792
793       WhitelistMode (on|off)
794              Enable whitelist mode. All attributes  except  those  configured
795              with  WhitelistAttribute or WhitelistVendorAttribute will be re‐
796              moved.  While whitelist mode is active, RemoveAttribute and  Re‐
797              moveVendorAttribute statements are ignored.
798
799       WhitelistAttribute attribute
800              Do not remove attributes with the given id when WhitelistMode is
801              on.  Ignored otherwise.
802
803       WhitelistVendorAttribute vendor[:subattribute]
804              Do not remove vendor attributes that match the given vendor  and
805              subattribute when WhitelistMode is on. Ignored otherwise.
806
807              If the subattribute is omitted, the complete vendor attribute is
808              whitelisted. Otherwise only the specified subattribute  is  kept
809              but all other subattributes are removed.
810
811

SEE ALSO

813       radsecproxy(8)
814
815
816
817radsecproxy 1.9.1                 2021-10-25               radsecproxy.conf(5)
Impressum