Ubuntu Manpage: radsecproxy.conf - Radsec proxy configuration file

NAME

       radsecproxy.conf - Radsec proxy configuration file

DESCRIPTION

       When  the  proxy  server  starts, it will first check the command line arguments, and then
       read the configuration  file.  Normally  radsecproxy  will  read  the  configuration  file
       /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 whitespace, or if the first non-whitespace character is a #.
The configuration 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 whitespace (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 requiring a string type
value. This is done by writing the character % followed 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 /etc/radsecproxy.conf.d/*.conf

The files are sorted alphabetically. Included files are read in the order 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 returns 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 everything. 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 option 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_LOCAL3,
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 specified on the command line.

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

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

LogMAC opt
The LogMAC option can be used to control if and how Calling-Station-Id (the users
Ethernet MAC address) is being logged. It can be set to one of Static, Original,
VendorHashed, VendorKeyHashed, 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 producing HMAC's as an
effect of specifying VendorKeyHashed or FullyKeyHashed 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 accessed?

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
LogDestination option specifies.

F-Ticks messages are always logged using the log level LOG_DEBUG. 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 configured 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 addresses
(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 specified 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 messages (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 inside 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 configured. 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 using 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 SubjectAltName: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 MatchCertificateAttribute,
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
administrator. 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 secret contains
whitespace, the value must be quoted. This option is optional for TLS/DTLS and if
omitted will default to "radsec". (Note that using a secret other than "radsec" for
TLS is a violation of the standard (RFC 6614) and that the proposed standard 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 defaultClient 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 address.

matchCertificateAttribute ( CN | SubjectAltName:URI | SubjectAltName:DNS ) :/regexp/
MatchCertificateAttribute SubjectAltName:IP:address
Perform additional validation of certificate attributes. Currently 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 previous 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 returned 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 messages to this client.

TCPKeepalive (on|off)
Enable TCP keepalive (default is off). If keepalives are not answered 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 request 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 exception, 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 executable 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 (default 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 supports 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 retries 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.

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 Accounting-Requests when no
accoutingServer are configured.

ReplyMessage message
Specify a message to be sent back to the client if a Access-Request 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 attribute, 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 regexp
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 independently of the other servers.

If there is no Server option, the proxy will if ReplyMessage is specified, reply back to
the client with an Access Reject message. The message 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 configuring 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 retransmitting 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 discussed in the client and server block
descriptions, a client or server block may reference a particular TLS block by name. There
are also however the special TLS block names default, defaultClient and defaultServer
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
parameters, 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 itself. 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
triggered by sending a SIGHUP to the radsecproxy process. This option 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 reference 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 reference 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
rewrite 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 unsigned integer. Use the ' character at the start of the value to force
string interpretation. When using hex value, it is recommended to also lead with '
to avoid unintended numeric interpretation. See the CONFIGURATION SYNTAX section
for further details.

AddVendorAttribute vendor:subattribute:value
Add a vendor attribute to the radius message, specified by vendor and subattribute.
Both vendor and subattribute must be specified 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 subattribute 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 removed. While whitelist
mode is active, RemoveAttribute and RemoveVendorAttribute 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.