Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
radsecproxy.conf(5)					   radsecproxy.conf(5)

NAME
       radsecproxy.conf	- Radsec proxy configuration file

DESCRIPTION
       When  the proxy server starts, it will first check the command line ar-
       guments,	and then read the  configuration  file.	 Normally  radsecproxy
       will  read  the configuration file /usr/local/etc/radsecproxy.conf. The
       command line -c option can be used to instead read  an  alternate  file
       (see radsecproxy(1) for details).

       If the configuration file can not be found, the proxy will exit with an
       error message. Note that	there is also an include facility so that  any
       configuration  file  may	 include  other	configuration files. The proxy
       will also exit on configuration errors.

CONFIGURATION SYNTAX
       When the	configuration file is processed, whitespace (spaces and	 tabs)
       are  generally  ignored.	For each line, leading and trailing whitespace
       are ignored.  A line is ignored if it is	empty, only consists of	white-
       space,  or if the first non-whitespace character	is a #.	The configura-
       tion is generally case insensitive, but in some cases the option	values
       (see below) are not.

       There  are  two types of	configuration structures than can be used. The
       first and simplest are lines on the format option value.	 That  is,  an
       option  name, see below for a list of valid options, followed by	white-
       space (at least one space or tab	character), followed by	a value.  Note
       that  if	the value contains whitespace, then it must be quoted using ""
       or ''. Any whitespace in	front of the option or after the value will be
       ignored.

       The  other  type	 of  structure	is a block. A block spans at least two
       lines, and has the format:

	      blocktype	name {
		   option value
		   option value
		   ...
	      }

       That is,	some blocktype,	see below for a	list of	 the  different	 block
       types,  and  then  enclosed  in braces you have zero or more lines that
       each have the previously	described option value format. Different block
       types have different rules for which options can	be specified, they are
       listed below. The rules regarding white space, comments and quotes  are
       as above. Hence you may do things like:

	      blocktype	name {
	      #	   option value
		  option "value	with space"
		  ...
	      }

       Option  value characters	can also be written in hex for options requir-
       ing a string type value.	This is	done by	writing	the character  %  fol-
       lowed  by  two hexadecimal digits. If a % is used without two following
       hexadecimal digits, the % and the  following  characters	 are  used  as
       written.	If you want to write a % and not use this decoding, you	may of
       course write % in hex; i.e., %25. As %00	would terminate	a string, this
       value  is  not  converted  in most cases, except	when used with rewrite
       statements or secrets.

       Some options allow or require the use of	regular	 expressions,  denoted
       as regex. The POSIX extended RE system is used, see re_format(7).

       There is	one special option that	can be used both as a basic option and
       inside all blocks. That is the option Include where the value specifies
       files  to  be  included.	 The value can be a single file, or it can use
       normal shell globbing to	specify	multiple files,	e.g.:

	      include /usr/local/etc/radsecproxy.conf.d/*.conf

       The files are sorted alphabetically. Included files are read in the or-
       der  they are specified,	when reaching the end of a file, the next file
       is read.	When reaching the end of the last included file, the proxy re-
       turns  to  read	the  next  line	following the Include option. Included
       files may again include other files.

BASIC OPTIONS
       The following basic options may be specified in the configuration file.
       Note  that  blocktypes  and  options inside blocks are discussed	later.
       Note that none of these options are required, and indeed	in many	 cases
       they  are  not  needed. Note that you should specify each at most once.
       The behaviour with multiple occurrences is undefined.

       PidFile file
	      The PidFile option specifies the name of a  file	to  which  the
	      process  id  (PID) will be written. This is overridden by	the -i
	      command line option.  There is no	default	value for the  PidFile
	      option.

       LogLevel	1-5
	      This  option  specifies the debug	level. It must be set to 1, 2,
	      3, 4 or 5, where 1 logs only serious errors, and 5  logs	every-
	      thing.  The  default  is 2 which logs errors, warnings and a few
	      informational messages. Note that	the  command  line  option  -d
	      overrides	this.

       LogDestination (file|syslog)
	      This  specifies where the	log messages should go.	By default the
	      messages go to syslog with facility LOG_DAEMON. Using  this  op-
	      tion you can specify another syslog facility, or you may specify
	      that logging should be to	a particular file, not	using  syslog.
	      The  value  must be either a file	or syslog URL. The file	URL is
	      the standard one file:///var/log/radius.log, specifying a	 local
	      file  that  should be used. For syslog, you must use the syntax:
	      x-syslog:///FACILITY where FACILITY must be one  of  LOG_DAEMON,
	      LOG_MAIL,	 LOG_USER, LOG_LOCAL0, LOG_LOCAL1, LOG_LOCAL2, LOG_LO-
	      CAL3, LOG_LOCAL4,	LOG_LOCAL5, LOG_LOCAL6or LOG_LOCAL7.  You  may
	      omit the facility	from the URL to	specify	logging	to the default
	      facility,	but this is not	very useful since this is the  default
	      log destination. Note that this option is	ignored	if -f is spec-
	      ified on the command line.

       LogThreadId (on|off)
	      This can be set to on to include the thread-id in	the  log  mes-
	      sages (useful for	debugging).

       LogFullUsername (on|off)
	      This  can	 be  set  to  off  to only log the realm in Access-Ac-
	      cept/Reject log messages (for privacy).

       LogMAC opt
	      The LogMAC option	can be used to control if and how Calling-Sta-
	      tion-Id (the users Ethernet MAC address) is being	logged.	It can
	      be set to	one  of	 Static,  Original,  VendorHashed,  VendorKey-
	      Hashed,  FullyHashed  or	FullyKeyHashed.	 The default value for
	      LogMAC is	Original.

	      See radsecproxy.conf-example for details.

       LogKey key
	      The LogKey option	is used	to specify the key to use when produc-
	      ing  HMAC's  as  an effect of specifying VendorKeyHashed or Ful-
	      lyKeyHashed for the LogMAC option.

       FTicksReporting fticks
	      The FTicksReporting option is used to enable F-Ticks logging and
	      can  be  set to None, Basic or Full.  Its	default	value is None.
	      If FTicksReporting is set	to anything other than None, note that
	      the default value	for FTicksMAC needs FTicksKey to be set.

	      See radsecproxy.conf-example for details.

       FTicksMAC opt
	      The FTicksMAC option has the same	function as LogMAC for FTicks.
	      The  default  for	 FTicksMAC  is	VendorKeyHashed	 which	 needs
	      FTicksKey	to be set.

	      Before  choosing	any  of	Original, FullyHashed or VendorHashed,
	      consider the implications	for user privacy  when	MAC  addresses
	      are  collected. How will the logs	be stored, transferred and ac-
	      cessed?

       FTicksKey key
	      The FTicksKey option has the same	function as LogKey for Fticks.

       FTicksSyslogFacility syslog
	      The FTicksSyslogFacility option is used to specify  a  dedicated
	      syslog  facility	for  F-Ticks  messages.	This allows for	easier
	      filtering	of F-Ticks messages. If	no FTicksSyslogFacility	option
	      is  given,  F-Ticks messages are written to what the LogDestina-
	      tion option specifies.

	      F-Ticks messages are always logged using the log	level  LOG_DE-
	      BUG.  Note that specifying a file	in FTicksSyslogFacility	(using
	      the file:/// prefix) is not supported.

       FTicksPrefix prefix
	      The FTicksPrefix option is used to set the prefix	printed	in  F-
	      Ticks  messages. This allows for use of F-Ticks messages in non-
	      eduroam environments.  If	no FTicksPrefix	option	is  given,  it
	      defaults to the prefix used for eduroam (F-TICKS/eduroam/1.0).

       ListenUDP (address|*)[:port]
       ListenTCP (address|*)[:port]
       ListenTLS (address|*)[:port]
       ListenDTLS (address|*)[:port]
	      Listen  for  the	address	 and port for the respective protocol.
	      Normally the proxy will listen to	the standard ports if  config-
	      ured to handle clients with the respective protocol. The default
	      ports are	1812 for UDP and TCP and 2083 for  TLS	and  DTLS.  On
	      most  systems  it	 will  do  this	for all	of the system's	IP ad-
	      dresses (both IPv4 and IPv6). On some systems  however,  it  may
	      respond  to only IPv4 or only IPv6. To specify an	alternate port
	      you may use a value on the form *:port where port	is  any	 valid
	      port  number. If you also	want to	specify	a specific address you
	      can do e.g.  192.168.1.1:1812 or	[2001:db8::1]:1812.  The  port
	      may  be  omitted if you want the default one. Note that you must
	      use brackets around the IPv6 address. These options may be spec-
	      ified  multiple  times  to  listen  to multiple addresses	and/or
	      ports for	each protocol.

       SourceUDP (address|*)[:port]
       SourceTCP (address|*)[:port]
       SourceTLS (address|*)[:port]
       SourceDTLS (address|*)[:port]
	      This can be used to specify source address  and/or  source  port
	      that  the	 proxy will use	for connecting to clients to send mes-
	      sages (e.g. Access Request). The same syntax  as	for  Listen...
	      applies.

       TTLAttribute (attr|vendor:attr)
	      This  can	 be  used  to  change  the default TTL attribute. Only
	      change this if you know what you are doing. The syntax is	either
	      a	 numerical  value denoting the TTL attribute, or two numerical
	      values separated by column specifying a vendor attribute.

       AddTTL 1-255
	      If a TTL attribute is present,  the  proxy  will	decrement  the
	      value  and  discard the message if zero. Normally	the proxy does
	      nothing if no TTL	attribute is present. If you  use  the	AddTTL
	      option  with  a  value  1-255, the proxy will, when forwarding a
	      message with no TTL attribute, add one with the specified	value.
	      Note  that this option can also be specified for a client/server
	      which will override this setting when forwarding	a  message  to
	      that client/server.

       LoopPrevention (on|off)
	      When  this  is  enabled  (on), a request will never be sent to a
	      server named the same as the client it was received from.	 I.e.,
	      the names	of the client block and	the server block are compared.
	      Note that	this only gives	limited	protection against  loops.  It
	      can  be used as a	basic option and inside	server blocks where it
	      overrides	the basic setting.

       IPv4Only	(on|off)
       IPv6Only	(on|off)
	      Enabling IPv4Only	or IPv6Only (on) makes radsecproxy resolve DNS
	      names  to	 the  corresponding  address  family only, and not the
	      other. This is done for both clients and servers.	At most	one of
	      IPv4Only	and  IPv6Only  can  be enabled.	 Note that this	can be
	      overridden in client and server blocks, see below.

       Include file
	      This is not a normal configuration option; it can	 be  specified
	      multiple	times.	 It can	both be	used as	a basic	option and in-
	      side blocks. For the full	 description,  see  the	 configuration
	      syntax section above.

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

CLIENT BLOCK
       client (name|fqdn|(address[/length])) {
	    ...
       }

       The client block	is used	to configure a client. That is,	tell the proxy
       about a client, and what	parameters should be used for that client. The
       name of the client block	must (with one exception, see below) be	either
       the  IP	address	 (IPv4	or  IPv6) of the client, an IP prefix (IPv4 or
       IPv6) on	the form IpAddress/PrefixLength, or a domain name (FQDN).  The
       way an FQDN is resolved into an IP address may be influenced by the use
       of the IPv4Only and IPv6Only options. Note that literal IPv6  addresses
       must be enclosed	in brackets.

       If  a  domain name is specified,	then this will be resolved immediately
       to all the addresses associated with the	name, and the proxy  will  not
       care about any possible DNS changes that	might occur later. Hence there
       is no dependency	on DNS after startup. However, if the name can not  be
       resolved, startup will fail.

       When  some  client  later  sends	a request to the proxy,	the proxy will
       look at the IP address the request comes	from, and then go through  all
       the  addresses of each of the configured	clients	(in the	order they are
       defined), to determine which (if	any) of	the clients this is. When  us-
       ing  the	 IpAddress/PrefixLength	 form, this might mask clients defined
       later, which then will never be matched.

       In the case of TLS/DTLS,	the name of the	client must match the FQDN  or
       IP  address  in the client certificate (CN or SubectAltName:DNS or Sub-
       jectAltName:IP respectively). Note that this is not required  when  the
       client  name  is	 an IP prefix. If overlapping clients are defined (see
       section above), they will be searched for matching  MatchCertificateAt-
       tribute,	but they must reference	the same tls block.

       The allowed options in a	client block are:

       Host (fqdn|(address[/length]))
	      Alternatively  of	 specifying  the  FQDN or address in the block
	      name,  the host option may be used. In that case,	the  value  of
	      the  host	 option	 is used as described above, while the name of
	      the block	is only	used as	a descriptive name for the administra-
	      tor.  The	 host  option may be used multiple times, and can be a
	      mix of addresses,	FQDNs and prefixes.

       IPv4Only	(on|off)
       IPv6Only	(on|off)
	      Enabling IPv4Only	or IPv6Only (on) makes radsecproxy resolve DNS
	      names  to	 the  corresponding  address  family only, and not the
	      other. At	most one of IPv4Only and IPv6Only can be enabled. Note
	      that this	will override the global option	for this client.

       Type type
	      Specify the type (protocol) of the client. Available options are
	      UDP, TCP,	TLS and	DTLS.

       Secret secret
	      Use secret as the	shared RADIUS key with this client. If the se-
	      cret  contains whitespace, the value must	be quoted. This	option
	      is optional for TLS/DTLS and if omitted will  default  to	 "rad-
	      sec". (Note that using a secret other than "radsec" for TLS is a
	      violation	of the standard	(RFC 6614) and that the	proposed stan-
	      dard for DTLS stipulates that the	secret must be "radius/dtls".)

       TLS tls
	      For  a  TLS/DTLS client you may also specify the tls option. The
	      option value must	be the name of a previously defined TLS	block.
	      If this option is	not specified, the TLS block with the name de-
	      faultClient or default will be used if defined (in that  order).
	      If the specified TLS block name does not exist, or the option is
	      not specified and	none of	the defaults  exist,  the  proxy  will
	      exit with	an error.

       CertificateNameCheck (on|off)
	      For a TLS/DTLS client, disable the default behaviour of matching
	      CN or SubjectAltName against the specified hostname  or  IP  ad-
	      dress.

       matchCertificateAttribute  (  CN	 |  SubjectAltName:URI	|  SubjectAlt-
       Name:DNS	) :/regexp/
       MatchCertificateAttribute SubjectAltName:IP:address
	      Perform additional validation of	certificate  attributes.  Cur-
	      rently matching of CN and	SubjectAltName types URI DNS and IP is
	      supported. Note that currently this option can only be specified
	      once in a	client block.

       DuplicateInterval seconds
	      Specify  for how many seconds duplicate checking should be done.
	      If a proxy receives a new	request	within a few seconds of	a pre-
	      vious  one,  it may be treated the same if from the same client,
	      with the same authenticator etc. The proxy will then ignore  the
	      new request (if it is still processing the previous one),	or re-
	      turned a copy of the previous reply.

       AddTTL 1-255
	      The AddTTL option	has the	same meaning as	the option used	in the
	      basic  config.   See  the	BASIC OPTIONS section for details. Any
	      value configured here overrides the basic	one when sending  mes-
	      sages to this client.

       TCPKeepalive (on|off)
	      Enable TCP keepalive (default is off). If	keepalives are not an-
	      swered within 30s	the connection is considered lost.

       FticksVISCOUNTRY	cc
	      Sets this	client to be eligible to F-Ticks logging as defined by
	      the  FTicksReporting  basic option, and specifies	the country to
	      be reported.  The	country	should be specified by the  two-letter
	      country code.

       FticksVISINST institution
	      Set the institution to report in F-Ticks logging.	If this	option
	      is omitted, the name of the client block is used.

       Rewrite rewrite
	      This option is deprecated. Use rewriteIn instead.

       RewriteIn rewrite
       RewriteOut rewrite
	      Apply the	operations in the specified rewrite block on  incoming
	      (request)	 or  outgoing  (response)  messages  from this client.
	      Rewriting	incoming messages is done before, outgoing after other
	      processing.  If  the  RewriteIn  is  not configured, the rewrite
	      blocks defaultClient or default will be applied if  defined.  No
	      default blocks are applied for RewriteOut.

       RewriteAttribute	User-Name:/regex/replace/
	      Rewrite  the User-Name attribute in a client request for the re-
	      quest forwarded by the proxy. The	User-Name attribute is written
	      back  to the original value if a matching	response is later sent
	      back to the client. Example usage:

	      RewriteAttribute User-Name:/^(.*)@local$/\1@example.com/

SERVER BLOCK
       server (name|((fqdn|address)[:port])) {
	    ...
       }

       The server block	is used	to configure a server. That is,	tell the proxy
       about  a	 server, and what parameters should be used when communicating
       with that server.  The name of the server block must (with  one	excep-
       tion, see below)	be either the IP address (IPv4 or IPv6)	of the server,
       or a domain name	(FQDN).	If a domain name is specified, then this  will
       be  resolved immediately	to all the addresses associated	with the name,
       and the proxy will not care about any possible DNS changes  that	 might
       occur  later. Hence there is no dependency on DNS after startup.	If the
       domain name resolves to multiple	addresses, then	for UDP/DTLS the first
       address is used.	For TCP/TLS, the proxy will loop through the addresses
       until it	can connect to one of them. The	way an FQDN is	resolved  into
       an IP address may be influenced by the use of the IPv4Only and IPv6Only
       options.

       In the case of TLS/DTLS,	the name of the	server must match the FQDN  or
       IP address in the server	certificate.

       Note that the fqdn or address may include a port	number (separated with
       a column). This port number will	then override the default  port	 or  a
       port  option in the server block. Also note that	literal	IPv6 addresses
       must be enclosed	in brackets.

       The allowed options in a	server block are:

       Host (fqdn|address)[:port]
	      Alternatively of specifying the FQDN or  address	in  the	 block
	      name the host option may be used.	In that	case, the value	of the
	      host option is used as described above, while the	 name  of  the
	      block  is	only used as a descriptive name	for the	administrator.
	      Note that	multiple host options may be used. This	will  then  be
	      treated  as  multiple  names/addresses for the same server. When
	      initiating a TCP/TLS connection, all addresses of	all names  may
	      be  attempted,  but  there  is no	failover between the different
	      host values. For failover	use separate server blocks.

       Port port
	      Specify the port (UDP/TCP) to connect to.	If  omitted,  UDP  and
	      TCP  will	 default  to  1812  while TLS and DTLS will default to
	      2083.

       DynamicLookupCommand command
	      Execude the command to dynamically configure a server. The  exe-
	      cutable  file should be given with full path and will be invoked
	      with the name of the realm as its	first and  only	 argument.  It
	      should  either  print  a valid server {...} option on stdout and
	      exit with	a code of 0 or print nothing and exit with a  non-zero
	      exit code.

	      If  the command exited with 0 an provided	a valid	server config,
	      it will be combined with the statements in  this	server	block,
	      with the values returned by the command taking preference.

	      An example of a shell script resolving the DNS NAPTR records for
	      the realm	and then the SRV records for each NAPTR	 matching  'x-
	      eduroam:radius.tls' is provided in tools/naptr-eduroam.sh.

       StatusServer (on|off|minimal|auto)
	      Enable  the  use	of status-server messages for this server (de-
	      fault off).  If statusserver is enabled  (on),  the  proxy  will
	      send regular status-server messages to the server	to verify that
	      it is alive. Status tracking of the server will solely depend on
	      status-server message and	ignore lost requests. This should only
	      be enabled if the	server supports	it. With  the  option  minimal
	      status-server  messages are only sent when regular requests have
	      been lost	and no other replies have been received.

	      The option auto tries to detect whether the  other  server  sup-
	      ports  status-server.  If	so, status-server messages are enabled
	      in minimal mode.

       RetryCount count
	      Set how many times the proxy should retry	sending	a  request  to
	      the  server.  Default is 2 retries.  Please note that Radius re-
	      tries are	normally done by the NAS.

       RetryInterfval interval
	      Set the interval between each retry. Default is 5s.

       Rewrite rewrite
	      This option is deprecated. Use rewriteIn instead.

       RewriteOut rewrite
       RewriteIn rewrite
	      Apply the	operations in the specified rewrite block on  outgoing
	      (request)	 or  incoming (response) messages to/from this server.
	      Rewriting	outgoing messages is done after, incoming before other
	      processing.  If  the  RewriteIn  is  not configured, the rewrite
	      blocks defaultServer or default will be applied if  defined.  No
	      default blocks are applied for RewriteOut.

       LoopPrevention (on|off)
	      This overrides the global	LoopPrevention option for this server.
	      See section BASIC	OPTIONS	for details on this option.

       The meaning and syntax of the following options are exactly the same as
       for  the	 client	block. The details are not repeated here. Please refer
       to the definitions in the CLIENT	BLOCK section.

       IPv4Only	(on|off)
       IPv6Only	(on|off)
       Type type
       Secret secret
       TLS tls
       CertificateNameCheck (on|off)
       matchCertificateAttribute  (  CN	 |  SubjectAltName:URI	|  SubjectAlt-
       Name:DNS	) :/regexp/
       MatchCertificateAttribute SubjectAltName:IP:address
       AddTTL 1-255
       TCPKeepalive (on|off)

REALM BLOCK
       realm (*|realm|/regex/) {
	    ...
       }

       When  the  proxy	 receives  an Access-Request it	needs to figure	out to
       which server it should be forwarded. This is done  by  looking  at  the
       Username	 attribute in the request, and matching	that against the names
       of the defined realm blocks. The	proxy will match against the blocks in
       the order they are specified, using the first match if any. If no realm
       matches,	the proxy will simply ignore the  request.  Each  realm	 block
       specifies what the server should	do when	a match	is found.

       The allowed options in a	realm block are:

       Server server
       AccountingServer	server
	      Specify  the  server  to which requests for this realm should be
	      forwarded.  server references a previously defined server	 block
	      (see the SERVER BLOCK section). Each server and accountingServer
	      can be specified multiple	times, or omitted  completely.	If  no
	      server  is  configured,  the proxy will deny all Access-Requests
	      for this realm. If no accountingServer is	configured, the	 proxy
	      will silently ignore all Accounting-Requests for this realm. See
	      the SERVER SELECTION section below for details.

       AccountingResponse (on|off)
	      Enable sending Accounting-Response instead of ignoring  Account-
	      ing-Requests when	no accoutingServer are configured.

       ReplyMessage message
	      Specify  a message to be sent back to the	client if a Access-Re-
	      quest is denied because no server	are configured.

   REALM BLOCK NAMES AND MATCHING
       In the general case the proxy will look for a @ in the username	attri-
       bute, and try to	do an exact, case insensitive match between what comes
       after the @ and the name	of the realm block. So if you  get  a  request
       with  the  attribute  value  anonymous@example.com,  the	 proxy will go
       through the realm names in the order they are specified,	looking	for  a
       realm block named example.com.

       There  are  two exceptions to this, one is the realm name * which means
       match everything. Hence if you have a realm block named *, then it will
       always  match.  This should then	be the last realm block	defined, since
       any blocks after	this would never be checked. This is useful for	having
       a default.

       The  other  exception is	regular	expression matching. If	the realm name
       starts with a /,	the name is treated as an regular expression.  A  case
       insensitive  regexp  match  will	 then be done using this regexp	on the
       value of	the entire Username attribute. Optionally you may also have  a
       trailing	/ after	the regexp.  So	as an example, if you want to use reg-
       exp matching the	domain example.com you could have a realm block	 named
       /@example\.com$/.  If  you want to match	all domains under the .com top
       domain, you could do /@.*\.com$/. Note that since the matching is  done
       on   the	  entire   attribute  value,  you  can	also  use  rules  like
       /^[a-k].*@example\.com$/	to get some of the users in this domain	to use
       one  server,  while other users could be	matched	by another realm block
       and use another server.

   SERVER SELECTION
       Normally	requests will be forwarded to the first	server option defined.
       If  there  are multiple server options, the proxy will do fail-over and
       use the second server if	the first is down. If the two first are	 down,
       it  will	 try the third etc. If the first server	comes back up, it will
       go back to using	that one.  Detection of	servers	being up  or  down  is
       based  on  the  use of StatusServer (if enabled), and that TCP/TLS/DTLS
       connections are up. Otherwise unanswered	requests are  used  to	detect
       unresponsive servers. AccountingServers are treated the same, but inde-
       pendently of the	other servers.

       If there	is no Server option, the proxy will if ReplyMessage is	speci-
       fied,  reply back to the	client with an Access Reject message. The mes-
       sage contains a replyMessage attribute with the value as	 specified  by
       the  ReplyMessage  option.  Note	 that this is different	from having no
       match since then	the request is simply ignored.	This can  be  used  to
       catch all undefined sub-domains or even all undefined realms by config-
       uring either a regex match like /@.*\.example\.com/ or the realm	* with
       no  server  option.  Another use-case is	to block a specific pattern in
       the username or realm part using	 a regex.

       If there	is no AccountingServer option,	the  proxy  will  normally  do
       nothing,	ignoring accounting requests. If instead AccountingResponse is
       set to on, the proxy will log some of the  accounting  information  and
       send  an	 Accounting-Response back. This	stops clients from retransmit-
       ting Accounting-Request messages	when a realm has  no  accountingServer
       configured.

TLS BLOCK
       tls name	{
	    ...
       }

       The TLS block specifies TLS configuration options and you need at least
       one of these if you have	clients	or servers  using  TLS/DTLS.  As  dis-
       cussed  in the client and server	block descriptions, a client or	server
       block may reference a particular	TLS block by name. There are also how-
       ever  the  special  TLS block names default, defaultClient and default-
       Server which are	used as	defaults if the	client or  server  block  does
       not  reference  a TLS block. Also note that a TLS block must be defined
       before the client or server block that would use	it. If	you  want  the
       same  TLS  configuration	for all	TLS/DTLS clients and servers, you need
       just a single tls block named default, and the client and servers  need
       not  refer  to  it. If you want all TLS/DTLS clients to use one config,
       and all TLS/DTLS	servers	to use another,	then you would	be  fine  only
       defining	 two  TLS blocks named defaultClient and defaultServer.	If you
       want different clients (or different servers) to	have different TLS pa-
       rameters,  then	you  may  need	to  create other TLS blocks with other
       names, and reference those from the client or server definitions.

       As both clients and servers need	to present and verify  a  certificate,
       both  a	certificate  as	 well  as a CA to verify the peers certificate
       must be configured.

       The allowed options in a	tls block are:

       CACertificateFile file
	      The CA certificate file used to verify the peers certificate.

       CACertificatePath path
	      The path to search for CA	or intermediate	certificates.

       CertificateFile file
	      The server certificate this proxy	will use. The  file  may  also
	      contain a	certificate chain.

       CertificateKeyFile file
	      The  private-key	file  for  the server certificate specified in
	      CACertificateFile.

       CertificateKeyPassword password
	      The password to decrypt the private-key.

       PolicyOID oid
	      Require the peers	certificate to adhere to the policy  specified
	      by oid.  This can	be specified multiple times.

       CRLCheck	(on|off)
	      Enable checking peer certificate against the CRL (default	off).
	      Note  that  radsecproxy does not fetch the CRLs itslef. This has
	      to be done separately, e.g. with fetch-crl(8)

       CacheExpiry seconds
	      Specify how many seconds the CA and CRL  information  should  be
	      cached.  By  default,  the  CA and CRL are loaded	at startup and
	      cached indefinetely. After the configured	time, the CA  CRL  are
	      re-read.	Alternatively,	reloading  the CA and CRL can be trig-
	      gered by sending a SIGHUP	to the radsecproxy process.  This  op-
	      tion may be set to zero to disable caching.

REWRITE	BLOCK
       rewrite name {
	    ...
       }

       The  rewrite block specifies rules that may rewrite RADIUS messages. It
       can be used to add, remove and modify specific attributes from messages
       received	 from  and  sent  to  clients and servers. As discussed	in the
       client and server block descriptions, a client or server	block may ref-
       erence  a  particular rewrite block by name. There are however also the
       special rewrite block names default,  defaultClient  and	 defaultServer
       which  are used as defaults if the client or server block does not ref-
       erence a	block. Also note that a	rewrite	block must be  defined	before
       the  client or server block that	would use it. If you want the same re-
       write rules for input from all clients and servers,  you	 need  just  a
       single rewrite block named default, and the client and servers need not
       refer to	it. If you want	all clients to use one config, and all servers
       to use another, then you	would be fine only defining two	rewrite	blocks
       named defaultClient and defaultServer. Note  that  these	 defaults  are
       only  used  for rewrite on input. No rewriting is done on output	unless
       explicitly specified using the RewriteOut option.

       The rewrite actions are performed in this sequence:
	      1. RemoveAttribute (or WhitelistAttribute)
	      2. ModifyAttribute
	      3. SupplementAttribute
	      4. AddAttribute

       All options can be specified multiple times. The	allowed	options	 in  a
       rewrite block are:

       AddAttribute attribute:value
	      Add  an attribute	to the radius message and set it to value. The
	      attribute	must be	specified using	the  numerical	attribute  id.
	      The  value can either be numerical, a string, or a hex value. If
	      the value	starts with a number, it is interpreted	as a 32bit un-
	      signed  integer.	 Use the ' character at	the start of the value
	      to force string interpretation. When using hex value, it is rec-
	      ommended	to also	lead with ' to avoid unintended	numeric	inter-
	      pretation. See the CONFIGURATION SYNTAX section for further  de-
	      tails.

       AddVendorAttribute vendor:subattribute:value
	      Add  a vendor attribute to the radius message, specified by ven-
	      dor and subattribute. Both vendor	and subattribute must be spec-
	      ified  as	 numerical  values. The	format of value	is the same as
	      for addAttribute above.

       SupplementAttribute attribute:value
	      Add an attribute to the radius message and set it	to value, only
	      if the  attribute	is not yet present on the message.  The	format
	      of value is the same as for addAttribute above.

       SupplementVendorAttribute vendor:subattribute:value
	      Add a vendor attribute to	the radius message only	if the	subat-
	      tribute  of  this	 vendor	is not yet present on the message. The
	      format of	is the same as for addVendorAttribute above.

       ModifyAttribute attribute:/regex/replace/
	      Modify the given attribute using the regex replace  pattern.  As
	      above, attribute must be specified by a numerical	value. Example
	      usage:

	      modifyAttribute 1:/^(.*)@local$/\1@example.com/

       ModifyVendorAttribute vendor:subattribute:/regex/replace/
	      Modify the given subattribute of given vendor  using  the	 regex
	      replace  pattern.	  Other	than the added vendor, the same	syntax
	      as for ModifyAttribute applies.

       RemoveAttribute attribute
	      Remove all attributes with the given id.

       RemoveVendorAttribute vendor[:subattribute]
	      Remove all vendor	attributes that	match  the  given  vendor  and
	      subattribute.  If	 the  subattribute  is omitted,	all attributes
	      with the given vendor id are removed.

       WhitelistMode (on|off)
	      Enable whitelist mode. All attributes  except  those  configured
	      with  WhitelistAttrbiute or WhitelistVendorAttribute will	be re-
	      moved.  While whitelist mode is active, RemoveAttribute and  Re-
	      moveVendorAttribute statements are ignored.

       WhitelistAttribute attribute
	      Do not remove attributes with the	given id when WhitelistMode is
	      on.  Ignored otherwise.

       WhitelistVendorAttribute	vendor[:subattribute]
	      Do not remove vendor attributes that match the given vendor  and
	      subattribute when	WhitelistMode is on. Ignored otherwise.

	      If the subattribute is omitted, the complete vendor attribute is
	      whitelisted. Otherwise only the specified	subattribute  is  kept
	      but all other subattributes are removed.

SEE ALSO
       radsecproxy(1)

radsecproxy 1.8.1		  2019-10-01		   radsecproxy.conf(5)

NAME | DESCRIPTION | CONFIGURATION SYNTAX | BASIC OPTIONS | BLOCKS | CLIENT BLOCK | SERVER BLOCK | REALM BLOCK | TLS BLOCK | REWRITE BLOCK | SEE ALSO

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=radsecproxy.conf&sektion=5&manpath=FreeBSD+12.2-RELEASE+and+Ports>

home | help