#
# e.g:
#
-# ```
-#
%base64.encode(%cipher_encrypt(<plaintext>))
-# %cipher_decrypt(%base64.decode(<ciphertext>))
-# ```
+# ```
+# %base64.encode(%cipher_encrypt(<plaintext>))
+# %cipher_decrypt(%base64.decode(<ciphertext>))
+# ```
#
# NOTE: The supported versions are determined _entirely_ by the
# version of OpenSSL used, FreeRADIUS simply passes the name of the
# current request.
#
# [source,unlang]
-# --- map client [<ipaddr>] { // <1>
+# ----
+# map client [<ipaddr>] { // <1>
# Foo = 'nas_type' // <2>
# Bar := 'shortname' // <3>
# Baz += 'groups' // <4>
-# } ---
+# }
+# ----
#
# <1> By default `map client { ... }` will operate on the current
# client, but alternative
# The CSV map can be used in a `map` section, as in the following
# example.
#
-# ```
-# map csv User-Name {
-# Attribute-Name := field1
-# Attribute-Name := field2
-# ...
-# }
-# ```
+# ```
+# map csv User-Name {
+# Attribute-Name := field1
+# Attribute-Name := field2
+# ...
+# }
+# ```
#
# The argument to "map" is dynamically expanded. The result is taken
# as a string, and is used as the value of the "key". The key is then
# `key`".
#
# [NOTE]
- # =====
- # * the header MUST have the same number of fields as are in the CSV file.
- # * the field names MUST NOT include whitespace.
- # * Fields which are not used should have no name
+ # ====
+ # * The header MUST have the same number of fields as are in the CSV file.
+ # * The field names MUST NOT include whitespace.
+ # * Fields which are not used should have no name.
+ #
+ # e.g. `foo,,bar` defines 3 fields, where the second is unused.
+ # ====
#
- # e.g. *"foo,,bar"* defines 3 fields, where the second is unused.
- # =====
fields = "name,size,color,count"
#
#
# Configuration items are in the format:
#
- # ```
- # <fr attr> <op> <csv field>
- # ```
+ # ```
+ # <fr attr> <op> <csv field>
+ # ```
#
# Where:
#
#
# The module also exports a `map` expansion, via the syntax:
#
- # map cvs <key> { ... }
+ # ```
+ # map cvs <key> { ... }
+ # ```
#
# Where `csv` is the name of the module, and `key` is an expansion
# as given the key` field above. For example, the map could look
# like this:
#
- # ```
- # map csv User-Name {
- # reply.Reply-Message := 'color'
- # my-integer := 'count'
- # }
- # ```
+ # ```
+ # map csv User-Name {
+ # reply.Reply-Message := 'color'
+ # my-integer := 'count'
+ # }
+ # ```
#
# This map does the same operations as the key / update fields given
# above. The benefit here is that the key can be dynamically
# section and the topic is inferred from the section's packet type.
# For example:
#
-# ```
-# recv Accounting-Request {
-# kafka # publishes to topic "Accounting-Request"
-# }
-# ```
+# ```
+# recv Accounting-Request {
+# kafka # publishes to topic "Accounting-Request"
+# }
+# ```
#
# This is tidy when you name topics after packet types; if you don't,
# stick with the explicit `kafka.produce.<topic>` form. Either way,
# different topics can publish different shapes from one module
# instance:
#
-# ```
-# kafka {
-# server = "localhost:9092"
-# topic {
-# radius-accounting {
-# request_required_acks = -1
-# value = %json.encode(&request.[*])
-# key = &User-Name
-# }
-# radius-auth {
-# value = %{User-Name}
-# }
+# ```
+# kafka {
+# server = "localhost:9092"
+# topic {
+# radius-accounting {
+# request_required_acks = -1
+# value = %json.encode(&request.[*])
+# key = &User-Name
+# }
+# radius-auth {
+# value = %{User-Name}
# }
# }
-# ```
+# }
+# ```
#
# In a virtual server:
#
-# ```
-# recv Accounting-Request {
-# kafka.produce.radius-accounting
-# }
+# ```
+# recv Accounting-Request {
+# kafka.produce.radius-accounting
+# }
#
-# recv Access-Request {
-# kafka.produce.radius-auth
-# }
-# ```
+# recv Access-Request {
+# kafka.produce.radius-auth
+# }
+# ```
#
# `value` is required per topic. `key` is optional; when omitted,
# librdkafka picks a partition according to the configured
# key and payload). It returns `true` on successful delivery and
# `false` on failure:
#
-# ```
-# send Accounting-Response {
-# if (!%kafka.produce('radius-accounting', %json.encode(&request.[*]))) {
-# reject
-# }
+# ```
+# send Accounting-Response {
+# if (!%kafka.produce('radius-accounting', %json.encode(&request.[*]))) {
+# reject
# }
-# ```
+# }
+# ```
#
# As with the method, the topic argument must name a declared topic.
#
# string, and adding "memberof" qualifiers. For ActiveDirectory,
# use:
#
- # ```
- # ldapsearch ... '(&(objectClass=user)(sAMAccountName=user)(memberof=CN=group,${base_dn}))'
- # ```
+ # ```
+ # ldapsearch ... '(&(objectClass=user)(sAMAccountName=user)(memberof=CN=group,${base_dn}))'
+ # ```
#
# Where 'user' is the user as above, and 'group' is the group you
# are querying for.
#
# Values should be in the format:
#
- # ```
- # <fr attr> <op> <value>
- # ```
+ # ```
+ # <fr attr> <op> <value>
+ # ```
#
# Where:
#
#
# Configuration items are in the format:
#
- # ```
- # <fr attr> <op> <ldap attr>
- # ```
+ # ```
+ # <fr attr> <op> <ldap attr>
+ # ```
#
# Where:
#
# allows the module to change the `Calling-Station-Id` attribute to
# the normal format as specified in RFC 3580 Section 3.21.
#
-# ```
-# recv Access-Request {
-# ...
-# wimax
-# ...
-# }
-# ```
+# ```
+# recv Access-Request {
+# ...
+# wimax
+# ...
+# }
+# ```
#
# == send Access-Accept
#
# has been used, AND the EAP method derives MSK and EMSK, then the
# various WiMAX keys can be calculated.
#
-# ```
-# send Access-Accept {
+# ```
+# send Access-Accept {
# ...
#
# # define the WiMAX NAI
# wimax
#
# ...
-# }
-# ```
+# }
+# ```
#
# == Miscellaneous
#
# You have to create it, and put it into the request or reply as
# something like:
#
-# ```
-# WiMAX-MN-NAI = User-Name
-# ```
+# ```
+# WiMAX-MN-NAI = User-Name
+# ```
#
# You will also have to have the appropriate IP address (`v4` or
# `v6`) in order to calculate the keys below.
#
# For example, to disconnect a specific session:
#
-# ```
-# $ echo 'Acct-Session-Id = "769df3 312343"' | \
-# radclient -t 15 127.0.0.1 disconnect testing123
-# ```
+# ```
+# $ echo 'Acct-Session-Id = "769df3 312343"' | \
+# radclient -t 15 127.0.0.1 disconnect testing123
+# ```
#
# To perform a CoA update of all active sessions belonging to a user:
#
-# ```
-# $ cat <<EOF | radclient -t 15 127.0.0.1 coa testing123
-# User-Name = bob
-# Vendor-Specific.Cisco.AVPair = "subscriber:sub-qos-policy-out=q_out_uncapped"
-# EOF
-# ```
+# ```
+# $ cat <<EOF | radclient -t 15 127.0.0.1 coa testing123
+# User-Name = bob
+# Vendor-Specific.Cisco.AVPair = "subscriber:sub-qos-policy-out=q_out_uncapped"
+# EOF
+# ```
#
# In addition to configuring and activating this site, instances of
# the radius client module must be created for each NAS, for example:
#
-# ```
-# radius radius-originate-coa-192.0.2.1 {
-# type = CoA-Request
-# type = Disconnect-Request
-# transport = udp
-# udp {
-# ipaddr = 192.0.2.1
-# port = 1700
-# secret = "testing123"
-# }
+# ```
+# radius radius-originate-coa-192.0.2.1 {
+# type = CoA-Request
+# type = Disconnect-Request
+# transport = udp
+# udp {
+# ipaddr = 192.0.2.1
+# port = 1700
+# secret = "testing123"
+# }
#
-# # We are "originating" these packets since including Proxy-State
-# # may confuse the NAS
-# originate = yes
+# # We are "originating" these packets since including Proxy-State
+# # may confuse the NAS
+# originate = yes
#
-# # Uncomment this to fire and forget, rather than wait and retry
-# # replicate = yes
-# }
-# ```
+# # Uncomment this to fire and forget, rather than wait and retry
+# # replicate = yes
+# }
+# ```
#
# Refer to `mods-enabled/radius` as a detailed reference for
# configuring client access to each NAS.
# It can be called from another virtual server via the `call`
# keyword:
#
-# subrequest {
-# request := parent.request
-# call proxy {
-# }
-# }
+# ----
+# subrequest {
+# request := parent.request
+# call proxy {
+# }
+# }
+# ----
#
# For server pools with load-balancing, fail-over, etc., you can just
# use the `load-balance` and `redundant` keywords. Those sections
# to. See `mods-available/home_server_pool` for an example of the
# `pool1` module configuration.
#
- # pool1
+# pool1
}
# As a result, the `pool1` virtual module has to be listed in this
# section.
#
- # pool1
+# pool1
}
#
# control module must be configured as an instance of rlm_always in
# mods-enabled, for example:
#
-# ```
-# always db_online {
-# = Default to online
-# rcode = ok
-# }
-# ```
+# ```
+# always db_online {
+# = Default to online
+# rcode = ok
+# }
+# ```
#
# Now trigger the resource checks by sending a server-status request
# to this virtual server, as follows:
#
-# ```
-# echo "Message-Authenticator = 0x00" | \
-# radclient -r 1 -t 3 -q 127.0.0.1:18122 status testing123
-# ```
+# ```
+# $ echo "Message-Authenticator = 0x00" | \
+# radclient -r 1 -t 3 -q 127.0.0.1:18122 status testing123
+# ```
#
# The trigger could be invoked by a cron job or if more frequent
# checks than once per minute are required a systemd timer might be
# The current status of the control module can be examined at any
# time using radmin:
#
-# ```
-# radmin -e 'show module status db_online'
-# ```
+# ```
+# $ radmin -e 'show module status db_online'
+# ```
#
# For radmin to work requires that the control-socket virtual server
# is configured and enabled.
# The controlled virtual server will contain some control flow
# decision that uses the control module, for example:
#
-# ```
-# server default {
+# ```
+# server default {
#
-# ...
+# ...
#
-# recv Access-Request {
+# recv Access-Request {
#
-# = If the database is not healthy then remain silent to trigger
-# = NAS failover
-# #
-# db_online {
-# fail = 1
-# }
-# if (fail) {
-# do_not_respond
-# }
+# = If the database is not healthy then remain silent to trigger
+# = NAS failover
+# #
+# db_online {
+# fail = 1
+# }
+# if (fail) {
+# do_not_respond
+# }
#
-# sql
+# sql
#
-# pap
-# }
-# ...
-# }
-# ```
+# pap
+# }
+# ...
+# }
+# ```
#
#
# The configuration for this virtual server follows and should be
authenticate pap {
pap
}
-
-# etc.
}
projects / thirdparty / freeradius-server.git / commitdiff
