** xref:sbuff.adoc[String buffers] (`sbuff` s)
** xref:sbuff-parsing.adoc[Parsing with string buffers]
** xref:sbuff-ng.adoc[Sbuff issues]
-* xref:todo.adoc[TODO]
Also see the xref:installation:dependencies.adoc[build
dependencies] page.
-We recommend using local variables inside of "unlang" sections
-instead of defining attributes in this fine. See the reference documentation
-for more information on local variables.
+# Local dictionary definitions
+
+This is the local dictionary file which can be
+edited by local administrators. It will be loaded
+ *after* the main dictionary files are loaded.
-This file exists for two purposes:
-1) defining local attributes in order to simplify the process of migrating
- from version 3 to version 4. We recommend removing these attributes,
- and using local variables instead.
+NOTE: We recommend using local variables inside of "unlang"
+ sections instead of defining attributes in this file. See
+ the xref:reference:index.adoc[reference documentation]
+ for more information on
+ xref:reference:unlang/local.adoc[local variables].
-2) Including alias dictionaries in order to simplify the process of migrating
- from version 3 to version 4. We recommend using the new names where possible.
+This file exists for two purposes:
-= Local dictionary definitions
+1) defining local attributes in order to simplify the process
+ of migrating from version 3 to version 4. We recommend
+ removing these attributes, and using local variables instead.
-This is the local dictionary file which can be
-edited by local administrators. It will be loaded
- *after* the main dictionary files are loaded.
+2) Including alias dictionaries in order to simplify the
+ process of migrating from version 3 to version 4. We
+ recommend using the new names where possible.
+
+## Dictionary loading order
FreeRADIUS will automatically load the main dictionary files from:
If you do want attributes to go into a RADIUS packet, you
will need to use VSAs. This means requesting allocation
-of a Private Enterprise Code from http://iana.org/. We
+of a Private Enterprise Code from https://www.iana.org/. We
strongly suggest doing that *only* if you are a vendor of
RADIUS equipment.
-= FreeRADIUS server configuration file - @RADIUSD_VERSION_STRING@
+= FreeRADIUS server configuration file - 4.0
Read `man radiusd` before editing this file. See the section
titled DEBUGGING. It outlines a method where you can quickly
Setting this to "yes" means that the server prints a series
of dots:
-.......
+ .......
instead of the value, for attributes which contain secret
information. e.g. User-Name, Tunnel-Password, etc.
Note: Each of the three implementations of LDAP synchronisation behave
differently:
-https://tools.ietf.org/html/rfc4533[RFC 4533]
---------
+
+== https://tools.ietf.org/html/rfc4533[RFC 4533]
+
This provides a robust mechanism to allow clients to maintain a
cached copy of a fragment of a directory by the use of cookies which
can be returned to the server indicating the last successfully processed
received only contains the DN, or, if the deletion is reported as part of
the initial refresh phase it may only be the UUID.
-Active Directory
----------------
+
+== Active Directory
+
Active Directory will only provide updates from the time the query started;
there is no mechanism to catch up on changes which occurred while the
client was not connected. In addition it is not possible to apply a
includes the Deleted Objects container.
Active Directory will only perform persistent searches if the filter is
-(objectClass=*). To overcome this limitation, FreeRADIUS allows other
+`(objectClass=*)`. To overcome this limitation, FreeRADIUS allows other
LDAP filters to be specified which are applied in FreeRADIUS before passing
packets to the relevant processing sections.
covers the most likely to be required.
One key limitation, due to not having the LDAP schema to interpret attribute
-types, is that >=, <= and bitwise filters are assumed to be on integer values.
+types, is that `>=`, `<=` and bitwise filters are assumed to be on integer values.
If your Active Directory tree contains multiple domains, you will need a
query for each domain that is of interest; running a query at the base
changes received can be reduced by running the LDAP query against the
Global Catalog rather than the normal AD LDAP server.
-Persistent Search
------------------
+
+== Persistent Search
+
Servers implementing Persistent Search have the option to return the full
directory contents, or simply start reporting changes from the point when
the query was run.
changes to keep track of progress - however this has not been observed in
any testing. If this is implemented, then it can behave in a similar
manner to the cookie defined in https://tools.ietf.org/html/rfc4533[RFC 4533]; a search against the change log
-with a filter of (changeNumber>=n) could be used to read changes since
+with a filter of `(changeNumber>=n)` could be used to read changes since
change number 'n'.
-Note on user group membership
------------------------------
-Many directories provide a virtual memberOf attribute which lists
+== Note on user group membership
+
+Many directories provide a virtual `memberOf` attribute which lists
which groups a user is a member of.
With the directories which have been tested, including OpenLDAP and
-Active Directory it has been observed that modifying group member lists
+Active Directory, it has been observed that modifying group member lists
does not result in notification of changes to the users, even though
other modifications to the user will result in a notification which
-can include the memberOf attribute.
+can include the `memberOf` attribute.
Instead group membership changes are reported as changes to the group object.
+
Local attributes which are used to cache results from LDAP
#######################################################################
#
-# We recommend using local variables inside of "unlang" sections
-# instead of defining attributes in this fine. See the reference documentation
-# for more information on local variables.
+# # Local dictionary definitions
#
-# This file exists for two purposes:
+# This is the local dictionary file which can be
+# edited by local administrators. It will be loaded
+# *after* the main dictionary files are loaded.
#
-# 1) defining local attributes in order to simplify the process of migrating
-# from version 3 to version 4. We recommend removing these attributes,
-# and using local variables instead.
#
-# 2) Including alias dictionaries in order to simplify the process of migrating
-# from version 3 to version 4. We recommend using the new names where possible.
+# NOTE: We recommend using local variables inside of "unlang"
+# sections instead of defining attributes in this file. See
+# the xref:reference:index.adoc[reference documentation]
+# for more information on
+# xref:reference:unlang/local.adoc[local variables].
#
-#######################################################################
#
-# = Local dictionary definitions
+# This file exists for two purposes:
#
-# This is the local dictionary file which can be
-# edited by local administrators. It will be loaded
-# *after* the main dictionary files are loaded.
+# 1) defining local attributes in order to simplify the process
+# of migrating from version 3 to version 4. We recommend
+# removing these attributes, and using local variables instead.
+#
+# 2) Including alias dictionaries in order to simplify the
+# process of migrating from version 3 to version 4. We
+# recommend using the new names where possible.
+#
+# ## Dictionary loading order
#
# FreeRADIUS will automatically load the main dictionary files from:
#
#
# If you do want attributes to go into a RADIUS packet, you
# will need to use VSAs. This means requesting allocation
-# of a Private Enterprise Code from http://iana.org/. We
+# of a Private Enterprise Code from https://www.iana.org/. We
# strongly suggest doing that *only* if you are a vendor of
# RADIUS equipment.
#
#######################################################################
#
-# = FreeRADIUS server configuration file - @RADIUSD_VERSION_STRING@
+# = FreeRADIUS server configuration file - @RADIUSD_VERSION_MAJOR@.@RADIUSD_VERSION_MINOR@
#
# Read `man radiusd` before editing this file. See the section
# titled DEBUGGING. It outlines a method where you can quickly
# Setting this to "yes" means that the server prints a series
# of dots:
#
- # .......
+ # .......
#
# instead of the value, for attributes which contain secret
# information. e.g. User-Name, Tunnel-Password, etc.
# that it should be impossible to break out of the chroot.
#
# If you are worried about security issues related to this
- # use of chdir, then simply ensure that the "raddb" directory
- # is inside of the chroot, and be sure to do "cd raddb"
+ # use of chdir, then simply ensure that the `raddb` directory
+ # is inside of the chroot, and be sure to do `cd raddb`
# BEFORE starting the server.
#
# If the server is statically linked, then the only files
# Note: Each of the three implementations of LDAP synchronisation behave
# differently:
#
-# RFC 4533
-# --------
+#
+# == RFC 4533
+#
# This provides a robust mechanism to allow clients to maintain a
# cached copy of a fragment of a directory by the use of cookies which
# can be returned to the server indicating the last successfully processed
# received only contains the DN, or, if the deletion is reported as part of
# the initial refresh phase it may only be the UUID.
#
-# Active Directory
-# ---------------
+#
+# == Active Directory
+#
# Active Directory will only provide updates from the time the query started;
# there is no mechanism to catch up on changes which occurred while the
# client was not connected. In addition it is not possible to apply a
# includes the Deleted Objects container.
#
# Active Directory will only perform persistent searches if the filter is
-# (objectClass=*). To overcome this limitation, FreeRADIUS allows other
+# `(objectClass=*)`. To overcome this limitation, FreeRADIUS allows other
# LDAP filters to be specified which are applied in FreeRADIUS before passing
# packets to the relevant processing sections.
#
# covers the most likely to be required.
#
# One key limitation, due to not having the LDAP schema to interpret attribute
-# types, is that >=, <= and bitwise filters are assumed to be on integer values.
+# types, is that `>=`, `<=` and bitwise filters are assumed to be on integer values.
#
# If your Active Directory tree contains multiple domains, you will need a
# query for each domain that is of interest; running a query at the base
# changes received can be reduced by running the LDAP query against the
# Global Catalog rather than the normal AD LDAP server.
#
-# Persistent Search
-# -----------------
+#
+# == Persistent Search
+#
# Servers implementing Persistent Search have the option to return the full
# directory contents, or simply start reporting changes from the point when
# the query was run.
# changes to keep track of progress - however this has not been observed in
# any testing. If this is implemented, then it can behave in a similar
# manner to the cookie defined in RFC 4533; a search against the change log
-# with a filter of (changeNumber>=n) could be used to read changes since
+# with a filter of `(changeNumber>=n)` could be used to read changes since
# change number 'n'.
#
#
-# Note on user group membership
-# -----------------------------
-# Many directories provide a virtual memberOf attribute which lists
+# == Note on user group membership
+#
+# Many directories provide a virtual `memberOf` attribute which lists
# which groups a user is a member of.
#
# With the directories which have been tested, including OpenLDAP and
-# Active Directory it has been observed that modifying group member lists
+# Active Directory, it has been observed that modifying group member lists
# does not result in notification of changes to the users, even though
# other modifications to the user will result in a notification which
-# can include the memberOf attribute.
+# can include the `memberOf` attribute.
#
# Instead group membership changes are reported as changes to the group object.
#