From: nolade Date: Tue, 28 Jan 2025 17:00:19 +0000 (-0500) Subject: Updated nav files and lots of xref stuff Resolved filepaths for files in the referenc... X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=6a2391efeac88cd14bfa627447c72b3722e839d8;p=thirdparty%2Ffreeradius-server.git Updated nav files and lots of xref stuff Resolved filepaths for files in the reference and howto modules Update xrefs and fix broken links.Add file panic.gdb.adoc (found in src raddb panic.gdb) update ref nav file --- diff --git a/doc/antora/antora.yml b/doc/antora/antora.yml index a3f334ee50c..75e29ed5bf1 100644 --- a/doc/antora/antora.yml +++ b/doc/antora/antora.yml @@ -10,9 +10,9 @@ prerelease: Devel start_page: ROOT:index.adoc nav: - modules/ROOT/nav.adoc -- modules/reference/nav.adoc -- modules/installation/nav.adoc - modules/concepts/nav.adoc +- modules/reference/nav.adoc - modules/howto/nav.adoc +- modules/installation/nav.adoc - modules/tutorials/nav.adoc - modules/developers/nav.adoc diff --git a/doc/antora/modules/ROOT/pages/faq.adoc b/doc/antora/modules/ROOT/pages/faq.adoc index b269ae4a468..a22f2401c86 100644 --- a/doc/antora/modules/ROOT/pages/faq.adoc +++ b/doc/antora/modules/ROOT/pages/faq.adoc @@ -98,7 +98,7 @@ Then the server will always respond with the correct address. Yes, you can. Assuming you already have daemontools installed, configured and running in your system (see http://cr.yp.to/daemontools.html), you will have to make two decisions: 1. The log account and group name (_log.log_ is used in this example). Logging programs run under this _account.group_. If this _account.group pair_ does not exist yet, create it now. -2. The radiusd local service directory (_/etc/radiusd_ is used in this example). This is where radiusd will store logs and a few configuration files. +//2. The radiusd local service directory (_/etc/radiusd_ is used in this example). This is where radiusd will store logs and a few configuration files. Then perform these steps: @@ -454,20 +454,20 @@ If you're REALLY interested in knowing how to debug the RADIUS server yourself, Ready to process requests. * If it doesn't, then it should print out an error message. Read it. * If it takes a long time to start up, and THEN prints out the message, then your DNS is broken. -8. Ensure that you have localhost in your _raddb/clients_ file. FreeRADIUS comes configured this way, so it should be there. -9. Ensure you have a valid user in your _raddb/users_ file. If everything else fails, go to the top of the file and add the following entry: +6. Ensure that you have localhost in your _raddb/clients_ file. FreeRADIUS comes configured this way, so it should be there. +7. Ensure you have a valid user in your _raddb/users_ file. If everything else fails, go to the top of the file and add the following entry: bob Cleartext-Password := "bob" Reply-Message = "Hello, bob" -12. Run the radtest program from the LOCAL machine, in another window. This will tell you if the server is alive and is answering requests. +8. Run the radtest program from the LOCAL machine, in another window. This will tell you if the server is alive and is answering requests. radtest bob bob localhost 0 testing123 -14. Ensure that you see the Reply-Message above and that you do NOT see an "Access denied" message. If you get an Access-Accept message, this means that the server is running properly. -15. Configure another machine as a RADIUS client and run radtest from that machine too. You SHOULD see the server receive the request and send a reply. +9. Ensure that you see the Reply-Message above and that you do NOT see an "Access denied" message. If you get an Access-Accept message, this means that the server is running properly. +10. Configure another machine as a RADIUS client and run radtest from that machine too. You SHOULD see the server receive the request and send a reply. * If the server does NOT receive the request then the ports are confused. RADIUS historically uses 1645/UDP, where RFC 2138 and many new systems use the proper value of 1812/UDP. See _/etc/services_ or use the -p option to specify a different port. * Run tcpdump in another window on the RADIUS client machine. Use the command: * `tcpdump udp` * Look CAREFULLY at the packets coming from the RADIUS server. Which address are they coming from? Which port? -16. If authentication works from a different machine then you have the server set up correctly. -17. Now you should use a more complicated configuration to see if the server receives and replies with the attributes you want. There is little information that can be offered here in the FAQ as your individual systems configuration can not be predicted. However, a few hints can help: +11. If authentication works from a different machine then you have the server set up correctly. +12. Now you should use a more complicated configuration to see if the server receives and replies with the attributes you want. There is little information that can be offered here in the FAQ as your individual systems configuration can not be predicted. However, a few hints can help: * ALWAYS test your configurations running the server in debugging mode if you want to debug a problem. If you do not do so then DO NOT expect anyone else to be able to help you. * `radiusd -X` * Read RFC 2138 to see what the RADIUS attributes are and how they work @@ -769,13 +769,13 @@ Which gives : (tcpdump output) The whole netmask business is a complicated one. An IP interface has an IP address and usually a netmask associated with it. Netmasks on point-to-point interfaces like a PPP link are generally not used. -If you set the Framed-IP-Netmask attribute in a radius profile, you are setting the netmask of the interface on the side of the [[NAS]]. The Framed-IP-Netmask attribute is NOT something you can set to influence the netmask on the side of the dialin user. And usually, that makes no sense anyway even if you could set it. +If you set the Framed-IP-Netmask attribute in a radius profile, you are setting the netmask of the interface on the side of the NAS. The Framed-IP-Netmask attribute is NOT something you can set to influence the netmask on the side of the dialin user. And usually, that makes no sense anyway even if you could set it. The result of this on most NAS is that they start to route a subnet (the subnet that contains the assigned IP address and that is as big as the netmask indicates) to that PPP interface and thus to the user. If that is exactly what you want, then that's fine, but if you do not intend to route a whole subnet to the user, then by all means do NOT use the Framed-IP-Netmask attribute. -Many [[NAS]] interpret a left-out [[Framed-IP-Netmask]] as if it were set to 255.255.255.255, but to be certain you should set the Framed-IP-Netmask to 255.255.255.255. +Many NAS interpret a left-out Framed-IP-Netmask as if it were set to 255.255.255.255, but to be certain you should set the Framed-IP-Netmask to 255.255.255.255. -For example, the following entries do almost the same on most [[NAS]]: +For example, the following entries do almost the same on most NAS: user Cleartext-Password := "blegh" Service-Type = Framed-User, @@ -789,7 +789,7 @@ For example, the following entries do almost the same on most [[NAS]]: Framed-IP-Address = 192.168.5.78, Framed-Route = "192.168.5.64/28 0.0.0.0 1" -The result is that the end user gets IP address 192.168.5.78 and that the whole network with IP addresses 192.168.5.64 - 195.64.5.79 is routed over the PPP link to the user (see the [[RADIUS]] [[RFC]]s for the exact syntax of the Framed-Route attribute). +The result is that the end user gets IP address 192.168.5.78 and that the whole network with IP addresses 192.168.5.64 - 195.64.5.79 is routed over the PPP link to the user (see the RADIUS RFCs for the exact syntax of the Framed-Route attribute). ### How do I make CHAP work with LDAP? diff --git a/doc/antora/modules/ROOT/pages/index.adoc b/doc/antora/modules/ROOT/pages/index.adoc index 1c9d0843820..d04d192bb93 100644 --- a/doc/antora/modules/ROOT/pages/index.adoc +++ b/doc/antora/modules/ROOT/pages/index.adoc @@ -40,7 +40,7 @@ desired outcome. At a high level, the subject areas describe: * The xref:reference:raddb/index.adoc[configuration files] located in `/etc/raddb/`, or `/etc/freeradius/` * The syntax of the xref:reference:unlang/index.adoc[unlang] processing language * Various xref:howto:index.adoc[how-to] guides -* xref:howto:installation/index.adoc[Installing] and xref:howto:installation/upgrade.adoc[upgrading] FreeRADIUS +* xref:installation:index.adoc[Installing] and xref:installation:upgrade.adoc[upgrading] FreeRADIUS * xref:developers:index.adoc[Developer documentation] This organization means that for example, the `ldap` module will have diff --git a/doc/antora/modules/concepts/pages/modules/ldap_authentication.adoc b/doc/antora/modules/concepts/pages/modules/ldap_authentication.adoc index cebabc369f9..1ec20001db1 100644 --- a/doc/antora/modules/concepts/pages/modules/ldap_authentication.adoc +++ b/doc/antora/modules/concepts/pages/modules/ldap_authentication.adoc @@ -40,7 +40,7 @@ involves giving the FreeRADIUS "read-only" user permission to read the `userPassword` field. Again, the best method is to test authentication is with the -xref:modules/ldap_search.adoc[ldapsearch] tool. These tests *must* be +ldap search tool. These tests *must* be run prior to configuring FreeRADIUS. We strongly recommend having the LDAP database return the `userPassword` field to FreeRADIUS, so that FreeRADIUS can authenticate the user. @@ -67,7 +67,7 @@ formats. There is sufficient information in the password values to determine what format it is in (base64, binary, or text), and what password "encryption" mechanism has been used (crypt, MD5, SHA, SSHA2, SHA3, etc). All that is necessary is that the -xref:raddb:mods-available/ldap.adoc[ldap module] be configured to map +xref:reference:raddb/mods-available/ldap.adoc[ldap module] be configured to map the `userPassword` LDAP field to the `&control:Password-With-Header` attribute in FreeRADIUS. FreeRADIUS will then "do the right thing" to authenticate the user. @@ -75,7 +75,7 @@ authenticate the user. This mapping is done in the default module configuration. There are no additional changes required for FreeRADIUS to correctly read and decode the `userPassword` field from LDAP. Please see the -xref:raddb:mods-available/pap.adoc[pap module] for a full list of +xref:reference:raddb/mods-available/pap.adoc[pap module] for a full list of supported password "encryption" formats. == Additional Considerations diff --git a/doc/antora/modules/developers/pages/index.adoc b/doc/antora/modules/developers/pages/index.adoc index d0fecc1b773..1fecdda0027 100644 --- a/doc/antora/modules/developers/pages/index.adoc +++ b/doc/antora/modules/developers/pages/index.adoc @@ -5,7 +5,7 @@ List with some usual howtos for FreeRADIUS. Programming reference documentation can be found at the https://doc.freeradius.org/[Doxygen] site. -# Instructions for Developers +## Instructions for Developers As the name suggests, FreeRADIUS is developed under the GNU General Public License, Version 2 (GPLv2). diff --git a/doc/antora/modules/developers/pages/rfc_compliance.adoc b/doc/antora/modules/developers/pages/rfc_compliance.adoc index bb2333c95fb..195923c3587 100644 --- a/doc/antora/modules/developers/pages/rfc_compliance.adoc +++ b/doc/antora/modules/developers/pages/rfc_compliance.adoc @@ -1,7 +1,7 @@ = RFC Compliance -=== RADIUS Related +== RADIUS Related * RFC 2865 Remote Authentication Dial In User Service (RADIUS) (obsoletes RFC 2138 and RFC 2058) * RFC 2866 RADIUS Accounting (obsoletes RFC 2139 and RFC 2059) @@ -10,7 +10,7 @@ * RFC 2869 RADIUS Extensions * RFC 2548 Microsoft Vendor-Specific RADIUS Attributes -=== Authentication Related +== Authentication Related * RFC 1994 PPP Challenge Handshake Authentication Protocol (CHAP) * RFC 2284 PPP Extensible Authentication Protocol (EAP) @@ -18,7 +18,7 @@ * RFC 2759 Microsoft PPP CHAP Extensions, Version 2 * RFC 3748 Extensible Authentication Protocol (EAP) -=== SNMP Related +== SNMP Related * RFC 1227 SNMP MUX Protocol and MIB * RFC 2619 RADIUS Authentication Server MIB diff --git a/doc/antora/modules/howto/nav.adoc b/doc/antora/modules/howto/nav.adoc index b5630791123..49d7318f346 100644 --- a/doc/antora/modules/howto/nav.adoc +++ b/doc/antora/modules/howto/nav.adoc @@ -44,7 +44,7 @@ *** xref:modules/sqlcounter/index.adoc[SQL-Counter] *** xref:modules/sqlippool/index.adoc[SQL-IP-Pool] -**** xref:modules/sqlippool/generating.adoc[Generating IPs] +**** xref:modules/sqlippool/populating.adoc[Generating IPs] **** xref:modules/sqlippool/insert.adoc[Inserting IPs into SQL] ** xref:protocols/index.adoc[Protocols] diff --git a/doc/antora/modules/howto/pages/git.adoc b/doc/antora/modules/howto/pages/git.adoc index 2ead11b355e..bbd1dc83f01 100644 --- a/doc/antora/modules/howto/pages/git.adoc +++ b/doc/antora/modules/howto/pages/git.adoc @@ -2,7 +2,7 @@ As well as being an excellent SCM (Source control management) tool, git is also very useful for tracking changes to configuration files, and even for performing remote administration of servers. -=== The basics +== The basics For basic configuration management one only has to: @@ -30,7 +30,7 @@ And if it's all gone horribly wrong: There are many many tutorials available if you want to learn more generic git administration, this one is extra pretty: http://gitimmersion.com. -==== Remote administration +=== Remote administration The basic functionality of git is useful on its own, but one of the features that really makes git shine among the SCMs is its support for commit hooks. Hooks don't require anything special to function (like gitosis or the git-daemon), they work just as well over straight SSH. diff --git a/doc/antora/modules/howto/pages/modules/rest/index.adoc b/doc/antora/modules/howto/pages/modules/rest/index.adoc index 91e6ea76e12..6b9a8c92120 100644 --- a/doc/antora/modules/howto/pages/modules/rest/index.adoc +++ b/doc/antora/modules/howto/pages/modules/rest/index.adoc @@ -8,7 +8,7 @@ FreeRADIUS can be used to communicate with REST APIs. This section describes the basic configuration needed to configure the REST module to communicate with a REST service. -== xref:modules/rest/fixed_data.adoc[Calling REST endpoints with fixed data formats] +//== xref:modules/rest/fixed_data.adoc[Calling REST endpoints with fixed data formats] The REST module was developed to allow business logic to be separated out into a separate discrete service. This reduces the role of FreeRADIUS to a translation @@ -20,10 +20,10 @@ If you will be developing a new REST API to implement business logic for a AAA service, you should follow the guide in this section, and accept and return data in that format the REST module expected. -== xref:modules/rest/custom_data.adoc[Calling REST endpoints with a custom data format] +//== xref:modules/rest/custom_data.adoc[Calling REST endpoints with a custom data format] The REST module can also communicate with arbitrary REST endpoints, -and versions ≥ v4.0.x include a JSON module xref:mods-available/json.adoc[JSON] +and versions ≥ v4.0.x include a JSON module xref:reference:raddb/mods-available/json.adoc[JSON] which allows mapping elements of a JSON response to FreeRADIUS. If you're attempting to integrate an existing REST API, this section will provide diff --git a/doc/antora/modules/howto/pages/modules/sqlippool/index.adoc b/doc/antora/modules/howto/pages/modules/sqlippool/index.adoc index 4998b61bd18..df984a65566 100644 --- a/doc/antora/modules/howto/pages/modules/sqlippool/index.adoc +++ b/doc/antora/modules/howto/pages/modules/sqlippool/index.adoc @@ -491,7 +491,7 @@ Framed-IPv6-Prefix RADIUS attribute then you can put the IPv6 prefixes into the Populate the pool either manually using a text editor or database tool, or via a script. -See xref:modules/sqlippool/generating.adoc[Generating IPs for the +See xref:modules/sqlippool/populating.adoc[Generating IPs for the pools] for instructions on how to create lists of IPs for a pool. And then xref:modules/sqlippool/insert.adoc[Inserting IPs into SQL] diff --git a/doc/antora/modules/howto/pages/modules/sqlippool/insert.adoc b/doc/antora/modules/howto/pages/modules/sqlippool/insert.adoc index 8a7e9507080..f0e32c4e39d 100644 --- a/doc/antora/modules/howto/pages/modules/sqlippool/insert.adoc +++ b/doc/antora/modules/howto/pages/modules/sqlippool/insert.adoc @@ -34,7 +34,7 @@ follows: psql radius -qtAc 'SELECT framedipaddress FROM radippool' > existing_ips.txt ---- -See the xref:modules/sqlippool/generating.adoc[Generating IPs for the +See the xref:modules/sqlippool/populating.adoc[Generating IPs for the pools] page for instructions on how to generate the list of IPs to modify. diff --git a/doc/antora/modules/howto/pages/twitter.adoc b/doc/antora/modules/howto/pages/twitter.adoc index 2807ee35dd6..df574e96b57 100644 --- a/doc/antora/modules/howto/pages/twitter.adoc +++ b/doc/antora/modules/howto/pages/twitter.adoc @@ -1,6 +1,6 @@ Note: The required functionality to do basic twitter operations is only available in FreeRADIUS >= v3.0.4 -# Overview +## Overview The difficult part in twitter integration is signing the requests. If a single character is incorrect, the signature won't match, and the Twitter API will return an authentication diff --git a/doc/antora/modules/howto/pages/vendors/hp.adoc b/doc/antora/modules/howto/pages/vendors/hp.adoc index 78c8db8b661..9e0e41f8a3d 100644 --- a/doc/antora/modules/howto/pages/vendors/hp.adoc +++ b/doc/antora/modules/howto/pages/vendors/hp.adoc @@ -14,7 +14,7 @@ Note: A hashed version of the SRC address is also inserted into the CHAP-Passwor In normal operation the switch will attempt to authenticate the client every _quiet-period_ (a configurable period measured in seconds). That is, when the client connects and either: The RADIUS server returns an Access-Reject, or the RADIUS server is Unreachable, the switch will retry authentication after _quiet-period_ seconds. -##### Beware using guest VLANs with mac-based authentication and dynamic VLAN assignment +#### Beware using guest VLANs with mac-based authentication and dynamic VLAN assignment The quiet-period timer will not fire if an _unauth-vid_ is configured and the client transitions into the 'guest' state. The ASG manual for some products suggests that if the client falls into the 'guest' state because of RADIUS server timeout then they will be re-authenticated, but this was not implemented in software! Beware using the _unauth-vid_ where switches rely on RADIUS servers for VLAN assignment. A RADIUS server failure or power outage could place all clients into the 'guest' state where they will not be able to recover without manual intervention. @@ -64,7 +64,7 @@ Client based mode is a HP proprietary extension to the 802.1X standard, and is u In client based mode a filtering table is maintained for each authenticated port. Only devices which have successfully completed 802.1X authentication have their Mac-Addresses added to the filtering table, so only packets from authenticated devices are allowed to ingress into the network. Multiple authentication sessions for different devices may run concurrently, and accounting information will be provided for each individual session. -###### In earlier firmware, Reply-Messages were encapsulated as EAP-Notification packets. +##### In earlier firmware, Reply-Messages were encapsulated as EAP-Notification packets. In firmware (< H.10.74 or equivalent) the switch encapsulates the contents of the RADIUS Reply-Message attribute in an EAP-Notification packet, which it sends after the EAP-Success/Failure packet. Most supplicants deal with this ok (despite it breaking RFC 3579), but it causes WPA_Supplicant to restart authentication. If you're using 802.1X with older firmware, be sure to filter out the Reply-Message attribute in any Access-Accept packets containing an EAP-Message. @@ -109,7 +109,7 @@ When multiple port-access mechanisms are used, 802.1X based authentication alway If an 802.1X authenticated client sends an EAPOL-Logoff packet, the 802.1X session is terminated and the client will be re-authenticated using Web/Mac based authentication. -###### Setting the _unauth-vid_ for both 802.1X and Mac/Web authenticators will result in unexpected behaviour +#### Setting the _unauth-vid_ for both 802.1X and Mac/Web authenticators will result in unexpected behaviour This usually results in the client being assigned the port-access authenticator _unauth-vid_ after completing Mac/Web authentication. When you need to configure an _unauth-vid_ with multiple authentication mechanisms, set the _unauth-vid_ for the Mac/Web authenticator, not the 802.1X authenticator. Note: Setting unath-vid for 802.1X when concurrent 802.1X/MAC authentication is enabled, is now prohibited in software versions >= H.10.79 or equivalent @@ -171,7 +171,7 @@ The value of Egress-VLANID is a bit string, the first 8 bits specify whether the Note: It is not possible to specify the ingress untagged VLAN with RFC 4675 attributes, so RFC 3580 attributes must be used instead. -###### Ingress-Filters VSA is ignored by all HP ProCurve switches +##### Ingress-Filters VSA is ignored by all HP ProCurve switches The default switching 'philosophy' of ProCurve switches is to filter ingress packets based on the egress VLAN membership of a port, this goes against the 802.1Q standard, which requires that frames be allowed to ingress, even if their tag does not match a VLAN the port is a member of. Supporting this attribute (i.e. allowing promiscuous ingress) would break the ProCurve switching philosophy, and so this attribute is ignored. @@ -264,7 +264,7 @@ conf exit ``` -###### Default edge port GVRP settings are insecure, and may allow circumvention of network policy. +#### Default edge port GVRP settings are insecure, and may allow circumvention of network policy. The default setting for the interface _unknown-vlan_ option is _learn_, this allows GVRP enabled clients to gain access to additional tagged VLANs once the port is in an open state. This is often undesirable from a security standpoint, so the _unknown-vlan_ option should be set to _disable_ on all port-access authenticated edge ports. diff --git a/doc/antora/modules/installation/pages/debian.adoc b/doc/antora/modules/installation/pages/debian.adoc index 48aa1715898..ed10d7ecd53 100644 --- a/doc/antora/modules/installation/pages/debian.adoc +++ b/doc/antora/modules/installation/pages/debian.adoc @@ -3,7 +3,7 @@ * Installing from repositories * Installing from source -== Installing from repositories : +== Installing from repositories This is usually the easiest solution, but at the moment of writing (2016-06) both Ubuntu 16.04 and Ubuntu 14.04.4 contain packages which are EOL and which are not the latest in their own main version. So building from source is recommended as it will contain the latest version, which probably got most of the bugs sorted. @@ -64,8 +64,6 @@ cd /usr/share/doc/freeradius Installing from source can be daunting for people who never did it but as long as you read the output of the building process, it should tell you what went wrong or what is missing. -On GitHub select the branch you wish to install and press clone or download. -======= Your first step is to download the source files which can be found on one of the following sites: 1. http://freeradius.org/download.html[Freeradius.org] - Choose the latest release by selecting the relevant button. @@ -169,7 +167,7 @@ The install might show errors. Read the error !! Ask questions on freeradius lis -= Building on Debian or Ubuntu +== Building on Debian or Ubuntu Building Debian packages (including Ubuntu) of FreeRADIUS from source is kept as simple as possible. diff --git a/doc/antora/modules/installation/pages/redhat_faq.adoc b/doc/antora/modules/installation/pages/redhat_faq.adoc index 187963e2327..30bcfe41b74 100644 --- a/doc/antora/modules/installation/pages/redhat_faq.adoc +++ b/doc/antora/modules/installation/pages/redhat_faq.adoc @@ -4,7 +4,7 @@ There are several "Red Hat" distributions which address different goals and as a consequence have different philosophies driven by different constraints. -=== How is FreeRADIUS distributed on Fedora/RHEL/CentOS systems? +== How is FreeRADIUS distributed on Fedora/RHEL/CentOS systems? FreeRADIUS is distributed on Fedora/RHEL/CentOS systems as a set of RPM packages. There is a main package called "freeradius" and several diff --git a/doc/antora/modules/reference/nav.adoc b/doc/antora/modules/reference/nav.adoc index 0c2d4e868d2..e323706f32f 100644 --- a/doc/antora/modules/reference/nav.adoc +++ b/doc/antora/modules/reference/nav.adoc @@ -198,7 +198,7 @@ **** xref:raddb/mods-available/winbind.adoc[Winbind] **** xref:raddb/mods-available/yubikey.adoc[Yubikey] -*** xref:raddb/index.adoc[Virtual Servers] +*** xref:raddb/sites-available/index.adoc[Virtual Servers] **** xref:raddb/sites-available/abfab-tls.adoc[ABFAB: Listening on TLS] **** xref:raddb/sites-available/abfab-tr-idp.adoc[ABFAB: Trust Router] **** xref:raddb/sites-available/arp.adoc[ARP Virtual Server] diff --git a/doc/antora/modules/reference/pages/raddb/index.adoc b/doc/antora/modules/reference/pages/raddb/index.adoc index 06eaab65e65..d20b94b4210 100644 --- a/doc/antora/modules/reference/pages/raddb/index.adoc +++ b/doc/antora/modules/reference/pages/raddb/index.adoc @@ -76,7 +76,7 @@ policies are loaded by the server, and unused ones are ignored. === `sites-available/` -The xref:raddb/sites-available/index.adoc[sites-available/] directory +The xref:raddb/sites-available/default.adoc[sites-available/] directory contains virtual servers which process packets. They are similar in concept to the virtual servers used by Apache and Nginx. diff --git a/doc/antora/modules/reference/pages/raddb/mods-available/eap.adoc b/doc/antora/modules/reference/pages/raddb/mods-available/eap.adoc index e08e14cbde0..e292da000ad 100644 --- a/doc/antora/modules/reference/pages/raddb/mods-available/eap.adoc +++ b/doc/antora/modules/reference/pages/raddb/mods-available/eap.adoc @@ -207,7 +207,7 @@ the following sections: | `clear session { ... }` | Clear stateful session information from a cache. -| `verify certificate { ... }` | +| `verify certificate { ... }` | Apply policies based on the client certificate presented. | `staple certificate { ... }` @@ -944,7 +944,8 @@ removed in v4.0. See the new policy `copy_request_to_tunnel` in link:../../../../../../sites-available/inner-tunnel.adoc[sites-available/inner-tunnel], and in `policy.d/eap` for -more information. ==== +more information. +==== @@ -1015,7 +1016,6 @@ the fix does appear to work. NOTE: To use `PEAP` you must also configure an inner method in `mods-enabled/eap_inner`. - tls:: Point to the common TLS configuration Which `tls-config` section the TLS negotiation parameters are @@ -1043,7 +1043,6 @@ for more information. ==== - virtual_server:: The virtual server used for "inner" authentication. The inner tunneled request can be sent through a virtual @@ -1057,7 +1056,7 @@ outer request. This configuration is NOT RECOMMENDED. require_client_cert:: Whether we require a client certificate. -Unlike `EAP-TLS`, `PEAP `does not require a client certificate. +Unlike `EAP-TLS`, `PEAP` does not require a client certificate. However, you can require one by setting the following option. You can also override this option by setting diff --git a/doc/antora/modules/reference/pages/raddb/panic.gdb.adoc b/doc/antora/modules/reference/pages/raddb/panic.gdb.adoc new file mode 100644 index 00000000000..3ae253acdc9 --- /dev/null +++ b/doc/antora/modules/reference/pages/raddb/panic.gdb.adoc @@ -0,0 +1,4 @@ +info locals +info args +thread apply all bt full +quit diff --git a/doc/antora/modules/reference/pages/raddb/sites-available/abfab-tr-idp.adoc b/doc/antora/modules/reference/pages/raddb/sites-available/abfab-tr-idp.adoc index c0131d1e23f..6e7375b4a5e 100644 --- a/doc/antora/modules/reference/pages/raddb/sites-available/abfab-tr-idp.adoc +++ b/doc/antora/modules/reference/pages/raddb/sites-available/abfab-tr-idp.adoc @@ -71,7 +71,7 @@ For EAP requests. ``` -.Please see the xref:reference:raddb/mods-available/expiration.adoc[mods-available/expiration] for full documentation. +.Please see the xref:howto:modules/expiration/index.adoc[expiration] for full documentation. ``` expiration diff --git a/doc/antora/modules/reference/pages/raddb/sites-available/check-eap-tls.adoc b/doc/antora/modules/reference/pages/raddb/sites-available/check-eap-tls.adoc new file mode 100755 index 00000000000..1d257f131cb --- /dev/null +++ b/doc/antora/modules/reference/pages/raddb/sites-available/check-eap-tls.adoc @@ -0,0 +1,125 @@ + + +This virtual server allows EAP-TLS to reject access requests +based on some attributes of the certificates involved. + +To use this virtual server, you must enable it in the tls +section of mods-enabled/eap as well as adding a link to this +file in sites-enabled/. + + +Value-pairs that are available for checking include these +attributes in the session-state list: + + TLS-Client-Cert-Subject + TLS-Client-Cert-Issuer + TLS-Client-Cert-Common-Name + TLS-Client-Cert-Subject-Alt-Name-Email + +To see a full list of attributes, run the server in debug mode +with this virtual server configured, and look at the attributes +passed in to this virtual server. + + +This virtual server is also useful when using EAP-TLS as it is +only called once, just before the final Accept is about to be +returned from eap, whereas the outer authorize section is called +multiple times for each challenge / response. For this reason, +here may be a good location to put authentication logging, and +modules that check for further authorization, especially if they +hit external services such as sql or ldap. + + + +Authorize - this is the only section required. + +To accept the access request, set Auth-Type = ::Accept, otherwise +set it to Reject. + + + +By default, we just accept the request: + + + +Check the client certificate matches a string, and reject otherwise + + + + +Check the client certificate common name against the supplied User-Name + + + +This is a convenient place to call LDAP, for example, when using +EAP-TLS, as it will only be called once, after all certificates as +part of the EAP-TLS challenge process have been verified. + +An example could be to use LDAP to check that the connecting host, as +well as presenting a valid certificate, is also in a group based on +the User-Name (assuming this contains the service principal name). +Settings such as the following could be used in the ldap module +configuration: + +basedn = "dc=example, dc=com" +filter = "(servicePrincipalName=%{User-Name})" +base_filter = "(objectClass=computer)" +groupname_attribute = cn +groupmembership_filter = "(&(objectClass=group)(member=%{control.Ldap-UserDn}))" + + + + +Now let's test membership of an LDAP group (the ldap bind user will +need permission to read this group membership): + + + +or, to be more specific, you could use the group's full DN: +if (!(Ldap-Group == "CN=Permitted-Laptops,OU=Groups,DC=example,DC=org")) { + + +This may be a better place to call the files modules when using +EAP-TLS, as it will only be called once, after the challenge-response +iteration has completed. + + + + +Log all request attributes, plus TLS certificate details, to the +auth_log file. Again, this is just once per connection request, so +may be preferable than in the outer authorize section. It is +suggested that 'auth_log' also be in the outer post-auth and +Post-Auth REJECT sections to log reply packet details, too. + + + + +== Default Configuration + +``` +server check-eap-tls { +recv Access-Request { + &control.Auth-Type := ::Accept +# if ("%{session-state.TLS-Client-Cert-Common-Name}" == 'client.example.com') { +# &control.Auth-Type := ::Accept +# } +# else { +# &control.Auth-Type := ::Reject +# &reply.Reply-Message := "Your certificate is not valid." +# } +# if (&User-Name == "host/%{session-state.TLS-Client-Cert-Common-Name}") { +# &control.Auth-Type := ::Accept +# } +# else { +# &control.Auth-Type := ::Reject +# } +# ldap +# if (!(Ldap-Group == "Permitted-Laptops")) { +# &control.Auth-Type := ::Reject +# } +# files + auth_log +} +} +``` diff --git a/doc/antora/modules/reference/pages/raddb/sites-available/control-socket.rej.adoc b/doc/antora/modules/reference/pages/raddb/sites-available/control-socket.rej.adoc index 47f3132e724..d82e83d4811 100644 --- a/doc/antora/modules/reference/pages/raddb/sites-available/control-socket.rej.adoc +++ b/doc/antora/modules/reference/pages/raddb/sites-available/control-socket.rej.adoc @@ -37,7 +37,6 @@ gid:: Name of group that is allowed to connect to the control socket. ``` Access mode. -``` == Default Configuration diff --git a/doc/antora/modules/reference/pages/raddb/sites-available/default.adoc b/doc/antora/modules/reference/pages/raddb/sites-available/default.adoc index 4e61b6b9dba..dd7b9d805af 100644 --- a/doc/antora/modules/reference/pages/raddb/sites-available/default.adoc +++ b/doc/antora/modules/reference/pages/raddb/sites-available/default.adoc @@ -44,9 +44,9 @@ There are many "commented out" references to modules and configurations These references serve as place-holders, and as documentation. If you need the functionality of that module, then: - * configure the module in xref:reference:raddb/mods-available/index.adoc[mods-available/] + * configure the module in xref:raddb/mods-available/index.adoc[mods-available/] * enable the module in `mods-enabled`. e.g. for LDAP, do: `cd mods-enabled;ln -s ../mods-available/ldap` - * uncomment the references to it in this file. + * uncomment the references to it in this file. In most cases, those small changes will result in the server being able to connect to the database, and to authenticate users. diff --git a/doc/antora/modules/reference/pages/raddb/sites-available/default.rej.adoc b/doc/antora/modules/reference/pages/raddb/sites-available/default.rej.adoc index 51760e6da54..76bfb6c3f6f 100644 --- a/doc/antora/modules/reference/pages/raddb/sites-available/default.rej.adoc +++ b/doc/antora/modules/reference/pages/raddb/sites-available/default.rej.adoc @@ -82,9 +82,9 @@ password can be clear-text, or encrypted. ``` -``` == Default Configuration ``` + ``` diff --git a/doc/antora/modules/reference/pages/raddb/sites-available/dhcpv6.adoc b/doc/antora/modules/reference/pages/raddb/sites-available/dhcpv6.adoc index 427ea9800ec..2cf94b81caa 100644 --- a/doc/antora/modules/reference/pages/raddb/sites-available/dhcpv6.adoc +++ b/doc/antora/modules/reference/pages/raddb/sites-available/dhcpv6.adoc @@ -6,7 +6,7 @@ -= The DHCPv6 Virtual Server +== The DHCPv6 Virtual Server ## The Virtual Server diff --git a/doc/antora/modules/reference/pages/raddb/sites-available/index.adoc b/doc/antora/modules/reference/pages/raddb/sites-available/index.adoc new file mode 100755 index 00000000000..771cbdf53e4 --- /dev/null +++ b/doc/antora/modules/reference/pages/raddb/sites-available/index.adoc @@ -0,0 +1,365 @@ +== Virtual Servers + +FreeRADIUS 4.0 supports virtual servers. This is probably the single +largest change that is NOT backwards compatible with 1.x. + +The virtual servers do NOT have to be set up with the `sites-available` +and `sites-enabled` directories. You can still have one "radiusd.conf" +file, and put the server configuration there: + +``` +... +server { + recv Access-Request { + ... + } + authenticate pap { + ... + } + ... +} +... +``` + +The power of virtual servers lies in their ability to separate policies. +A policy can be placed into a virtual server, where it is guaranteed to +affect only the requests that are passed through that virtual server. In +1.x, the policies were global, and it sometimes took much effort to +write a policy so that it only applied in certain limited situations. + +=== What do we mean by "virtual server"? + +A virtual server is a (nearly complete) RADIUS server, just like a +configuration for FreeRADIUS 1.x. However, FreeRADIUS can now run +multiple virtual servers at the same time. The virtual servers can even +proxy requests to each other! + +The simplest way to create a virtual server is to take the all of the +request processing sections from radius.conf, ("authorize" , +"authenticate", etc.) and wrap them in a "server \{}" block, as +above. + +You can create another virtual server by: + +* defining a new "server foo \{…}" section in `radiusd.conf` +* Putting the normal "authorize", etc. sections inside of it +* Adding a "listen" section _inside_ of the "server" section. + +e.g. + +``` +... +server foo { + listen { + ipaddr = 127.0.0.1 + port = 2000 + type = auth + } + + recv Access-Request { + &control.Password.Cleartext := "bob" + pap + } + + authenticate pap { + pap + } +} +... +``` + +With that text added to `radiusd.conf`, run the server in debugging mode +(`radiusd -X`), and in another terminal window, type: + +``` +$ radtest bob bob localhost:2000 0 testing123 +``` + +You should see the server return an Access-Accept. + +=== Capabilities and limitations + +The only sub-sections that can appear in a virtual server section are: + +``` +listen +client +authorize +authenticate +post-auth +pre-proxy +post-proxy +preacct +accounting +session +``` + +All other configuration parameters (modules, etc.) are global. + +Inside of a virtual server, the authorize, etc. sections have their +normal meaning, and can contain anything that an authorize section could +contain in 1.x. + +When a "listen" section is inside of a virtual server definition, it +means that all requests sent to that IP/port will be processed through +the virtual server. There cannot be two "listen" sections with the +same IP address and port number. + +When a "client" section is inside of a virtual server definition, it +means that that client is known only to the "listen" sections that are +also inside of that virtual server. Not only is this client definition +available only to this virtual server, but the details of the client +configuration is also available only to this virtual server. + +i.e. Two virtual servers can listen on different IP address and ports, +but both can have a client with IP address 127.0.0.1. The shared secret +for that client can be different for each virtual server. + +=== More complex "listen" capabilities + +The "listen" sections have a few additional configuration items that +were not in 1.x, and were not mentioned above. These configuration items +enable almost any mapping of IP / port to clients to virtual servers. + +The configuration items are: + +``` +virtual_server = + + If set, all requests sent to this IP / port are processed + through the named virtual server. + + This directive can be used only for "listen" sections + that are global. i.e. It CANNOT be used if the + "listen" section is inside of a virtual server. + +clients = + + If set, the "listen" section looks for a "clients" section: + + clients { + ... + } + + It looks inside of that named "clients" section for + "client" subsections, at least one of which must + exist. Each client in that section is added to the + list of known clients for this IP / port. No other + clients are known. + + If it is set, it over-rides the list of clients (if + any) in the same virtual server. Note that the + clients are NOT additive! + + If it is not set, then the clients from the current + virtual server (if any) are used. If there are no + clients in this virtual server, then the global + clients are used. + + i.e. The most specific directive is used: + * configuration in this "listen" section + * clients in the same virtual server + * global clients + + The directives are also *exclusive*, not *additive*. + If you have one client in a virtual server, and + another client referenced from a "listen" section, + then that "listen" section will ONLY use the second + client. It will NOT use both clients. +``` + +=== More complex "client" capabilities + +The "client" sections have a few additional configuration items that +were not in 1.x, and were not mentioned above. These configuration items +enable almost any mapping of IP / port to clients to virtual servers. + +The configuration items are: + +``` +virtual_server = + + If set, all requests from this client are processed + through the named virtual server. + + This directive can be used only for "client" sections + that are global. i.e. It CANNOT be used if the + "client" section is inside of a virtual server. +``` + +If the "listen" section has a "server" entry, and a matching client +is found ALSO with a "server" entry, then the clients server is used +for that request. + +=== Worked examples + +Listening on one socket, and mapping requests from two clients to two +different servers. + +``` +listen { + ... +} +client one { + ... + virtual_server = server_one +} +client two { + ... + virtual_server = server_two +} +server server_one { + recv Access-Request { + ... + } + ... +} +server server_two { + recv Access-Request { + ... + } + ... +} +``` + +This could also be done as: + +``` +listen { + ... + virtual_server = server_one +} +client one { + ... +} +client two { + ... + virtual_server = server_two +} +server server_one { + recv Access-Request { + ... + } + ... +} +server server_two { + recv Access-Request { + ... + } + ... +} +``` + +In this case, the default server for the socket is "server_one", so +there is no need to set that in the client "one" configuration. The +"server_two" configuration for client "two" over-rides the default +setting for the socket. + +Note that the following configuration will NOT work: + +``` +listen { + ... + virtual_server = server_one +} +client one { + ... +} +server server_one { + recv Access-Request { + ... + } + ... +} +server server_two { + client two { + ... + } + recv Access-Request { + ... + } + ... +} +``` + +In this example, client "two" is hidden inside of the virtual server, +where the "listen" section cannot find it. + +=== Outlined examples + +This section outlines a number of examples, with alternatives. + +* one server, multiple sockets +** multiple "listen" sections in a "server" section +* one server per client +** define multiple servers +** have a global "listen" section +** have multiple global "clients", each with "virtual_server = X" +* two servers, each with their own sockets +** define multiple servers +** put "client" sections into each "server" +** put a "listen" section into each "server" ++ +Each server can list the same client IP, and the secret can be +different. +* two sockets, sharing a list of clients, but pointing to different +servers +** define global "listen" sections +** in each, set "virtual_server = X" +** in each, set "clients = Y" +** define "clients Y" section, containing multiple clients. ++ +This also means that you can have a third socket, which doesn’t share +any of these clients. + +=== How to decide what to do + +If you want _completely_ separate policies for a socket or a client, +then create a separate virtual server. Then, map the request to that +server by setting configuration entries in a "listen" section or in a +"client" section. + +Start off with the common cases first. If most of the clients and/or +sockets get a particular policy, make that policy the default. Configure +it without paying attention to the sockets or clients you want to add +later, and without adding a second virtual server. Once it works, then +add the second virtual server. + +If you want to reuse the previously defined sockets with the second +virtual server, then you will need one or more global "client" +sections. Those clients will contain a "virtual_server = …" entry that +will direct requests from those clients to the appropriate virtual +server. + +=== List of provided virtual servers + +* xref:raddb/sites-available/abfab-tls.adoc[abfab tls] +* xref:raddb/sites-available/abfab-tr-idp.adoc[abfab tr idp] +* xref:raddb/sites-available/arp.adoc[arp] +* xref:raddb/sites-available/bfd.adoc[bfd] +* xref:raddb/sites-available/buffered-sql.adoc[buffered sql] +* xref:raddb/sites-available/challenge.adoc[challenge] +* xref:raddb/sites-available/channel_bindings.adoc[channel_bindings] +* xref:raddb/sites-available/check-eap-tls.adoc[check eap tls] +* xref:raddb/sites-available/coa.adoc[coa] +* xref:raddb/sites-available/control-socket.adoc[control socket] +* xref:raddb/sites-available/copy-acct-to-home-server.adoc[copy acct to home server] +* xref:raddb/sites-available/decoupled-accounting.adoc[decoupled accounting] +* xref:raddb/sites-available/default.adoc[default] +* xref:raddb/sites-available/detail.adoc[detail] +* xref:raddb/sites-available/dhcp.adoc[dhcp] +* xref:raddb/sites-available/dhcp.relay.adoc[dhcp relay] +* xref:raddb/sites-available/dynamic-clients.adoc[dynamic clients] +* xref:raddb/sites-available/example.adoc[example] +* xref:raddb/sites-available/inner-tunnel.adoc[inner tunnel] +* xref:raddb/sites-available/ldap_sync.adoc[ldap_sync] +* xref:raddb/sites-available/originate-coa.adoc[originate coa] +* xref:raddb/sites-available/proxy-inner-tunnel.adoc[proxy inner tunnel] +* xref:raddb/sites-available/radius-acct.adoc[radius acct] +* xref:raddb/sites-available/robust-proxy-accounting.adoc[robust proxy accounting] +* xref:raddb/sites-available/status.adoc[status] +* xref:raddb/sites-available/tacacs.adoc[tacacs] +* xref:raddb/sites-available/tls.adoc[tls] +* xref:raddb/sites-available/tls-cache.adoc[tls cache] +* xref:raddb/sites-available/virtual.example.com.adoc[virtual example com] +* xref:raddb/sites-available/vmps.adoc[vmps] diff --git a/doc/antora/modules/reference/pages/raddb/sites-available/status.adoc b/doc/antora/modules/reference/pages/raddb/sites-available/status.adoc index a6f136d1bda..a9c74bcbde9 100644 --- a/doc/antora/modules/reference/pages/raddb/sites-available/status.adoc +++ b/doc/antora/modules/reference/pages/raddb/sites-available/status.adoc @@ -110,9 +110,9 @@ Add statistics based on the Vendor-Specific.FreeRADIUS.Stats4-* queries. Due to internal limitations, the statistics might not be exactly up to date. Do not expect all of the numbers to add up perfectly. -``` == Default Configuration ``` + ``` diff --git a/doc/antora/modules/reference/pages/raddb/sites-available/tls-cache.adoc b/doc/antora/modules/reference/pages/raddb/sites-available/tls-cache.adoc new file mode 100755 index 00000000000..3bbbc2c731d --- /dev/null +++ b/doc/antora/modules/reference/pages/raddb/sites-available/tls-cache.adoc @@ -0,0 +1,138 @@ + +This virtual server controls caching of TLS sessions. + +When a TLS session is used, the server will automatically create +the following attributes in the session-state list. These attributes +are the ones for the *server* certificate. + + +If a client certificate is required (e.g. EAP-TLS or sometimes PEAP / TTLS), +the following attributes are also created in the session-state list: + + + + + + +This section can be run to verify a client certificate if +additional checks need to be performed beyond standard +checks verification against a trust chain, CRLs and OCSP. + +Attributes extracted from the certificates forming the +client certificate chain will be in the session state list. + +Returning 'ok', 'updated' or 'noop' will cause the verification +to succeed. Other return codes will cause the verification +to fail. + + + +This section is run whenever the server needs to read an +entry from the TLS session cache. + +It should read the attribute &session-state.TLS-Session-Data +from the cache, along with any other attributes which +were in the cache + +On success it should return 'ok' or 'updated'. + +The return code has no real effect on session processing +and will just cause the server to emit a warning. + + + + +This section is run whenever the server needs to write an +entry to the TLS session cache. + +It should write the attribute &session-state.Session-Data +to the cache, along with any other attributes which +need to be cached. + +On success it should return 'ok' or 'updated'. + +The return code has no real effect on session processing +and will just cause the server to emit a warning. + + + + +This section is run whenever the server needs to delete an +entry from the TLS session cache. + +On success it should return 'ok', 'updated', 'noop' or 'notfound' + +The return code has no real effect on session processing +and will just cause the server to emit a warning. + + + + +This section is run after certificate attributes are added +to the request list, and before performing OCSP validation. + +It should read the attribute &control.TLS-OCSP-Cert-Valid +from the cache. + +On success it should return 'ok', 'updated', 'noop' or 'notfound' +To force OCSP validation failure, it should return 'reject'. + + + + +This section is run after OCSP validation has completed. + +It should write the attribute &reply.TLS-OCSP-Cert-Valid +to the cache. + +On success it should return 'ok' or 'updated'. + +The return code has no real effect on session processing +and will just cause the server to emit a warning. + + + +== Default Configuration + +``` +# TLS-Cert-Serial +# TLS-Cert-Expiration +# TLS-Cert-Subject +# TLS-Cert-Issuer +# TLS-Cert-Common-Name +# TLS-Cert-Subject-Alt-Name-Email +# TLS-Client-Cert-Serial +# TLS-Client-Cert-Expiration +# TLS-Client-Cert-Subject +# TLS-Client-Cert-Issuer +# TLS-Client-Cert-Common-Name +# TLS-Client-Cert-Subject-Alt-Name-Email +server tls-cache { + namespace = tls + verify certificate { + ok + } + load session { + &control.Cache-Allow-Insert := no + cache_tls_session + } + store session { + &control.Cache-TTL := 0 + cache_tls_session + } + clear session { + &control.Cache-TTL := 0 + &control.Cache-Allow-Insert := no + cache_tls_session + } + load ocsp-state { + &control.Cache-Allow-Insert := no + cache_ocsp + } + store ocsp-state { + &control.Cache-TTL := "%{&reply.TLS-OCSP-Next-Update * -1}" + &control.Cache-Allow-Merge := no + cache_ocsp + } +} +``` diff --git a/doc/antora/modules/reference/pages/unlang/interpreter.adoc b/doc/antora/modules/reference/pages/unlang/interpreter.adoc index ec9d69584bf..da2ced9adc5 100644 --- a/doc/antora/modules/reference/pages/unlang/interpreter.adoc +++ b/doc/antora/modules/reference/pages/unlang/interpreter.adoc @@ -27,9 +27,9 @@ functions, etc. Despite these limitations, it has proven to be useful and powerful. While the server includes plugins for languages such as -xref:reference:raddb/mods-available/lua.adoc[lua], -xref:reference:raddb/mods-available/python.adoc[python], and -xref:reference:raddb/mods-available/perl.adoc[perl], most policies can be done +xref:raddb/mods-available/lua.adoc[lua], +xref:raddb/mods-available/python.adoc[python], and +xref:raddb/mods-available/perl.adoc[perl], most policies can be done in simple `unlang` statements. More general purpose programming languages are more powerful than `unlang`, but they are generally sustantially slower. @@ -53,8 +53,8 @@ recv foo { ---- The processing sections are defined in -xref:reference:raddb/sites-available/index.adoc[virtual servers]. The -xref:reference:raddb/sites-available/index.adoc[virtual server] documentation +xref:raddb/sites-available/index.adoc[virtual servers]. The +xref:raddb/sites-available/index.adoc[virtual server] documentation describes the larger context of which packets are recieved, and when they are received. This section concentrates on the more narrow topic `unlang` itself. diff --git a/doc/antora/modules/reference/pages/xlat/string.adoc b/doc/antora/modules/reference/pages/xlat/string.adoc index 2c1ed1adc05..57730bd4b36 100644 --- a/doc/antora/modules/reference/pages/xlat/string.adoc +++ b/doc/antora/modules/reference/pages/xlat/string.adoc @@ -9,7 +9,6 @@ The following functions perform string manipulation. | Function | Description | xref:xlat/concat.adoc[concat] | Concatenate strings with delimiters | xref:xlat/explode.adoc[explode] | Split a string based on delimiters -| xref:xlat/length.adoc[length] | Get the length of a string | xref:xlat/lpad.adoc[lpad] | Left pad a string | xref:xlat/pairs.adoc[pairs] | Serialize a list of attributes to a string | xref:xlat/rpad.adoc[rpad] | Right pad a string diff --git a/doc/antora/modules/tutorials/pages/failover.adoc b/doc/antora/modules/tutorials/pages/failover.adoc index b80161e2e11..5fc7f0f6b5a 100644 --- a/doc/antora/modules/tutorials/pages/failover.adoc +++ b/doc/antora/modules/tutorials/pages/failover.adoc @@ -50,7 +50,7 @@ accounting { The "redundant" section is a configuration directive which tells the server to process the second module if the first one fails. Any number of modules can be listed in a "redundant" section. The server will process each in turn, until one of the modules succeeds. It will then stop processing the "redundant" list. -= Rewriting results for single modules +== Rewriting results for single modules Normally, when a module fails, the entire section ("authorize", "accounting", etc.) stops being processed. In some cases, we may want to permit "soft failures". That is, we may want to tell the server that it is "ok" for a module to fail, and that the failure should not be treated as a fatal error. @@ -76,7 +76,7 @@ redundant { The "fail = 1" entry tells the server to remember the "fail" code, with priority "1". The normal configuration is "fail = return", which means "if the detail module fails, stop processing the accounting section". -= Fail-over configuration entries +== Fail-over configuration entries Modules normally return on of the following codes as their result: @@ -114,7 +114,7 @@ The used for a value may be any decimal number between 1 and 99999. Th This configurability allows the administrator to permit some modules to fail, so long as a later module succeeds. -= More Complex Configurations +== More Complex Configurations The "authorize" section is normally a list of module names. We can create sub-lists by using the section name "group". The "redundant" section above is just a short-hand for "group", with a set of default return codes, which are different than the normal "stop processing the list on failure". @@ -156,13 +156,13 @@ return code found by processing the list. This process can be extended to any number of modules listed in a "group" section. -= More Complex Configuration using "if" and "else" +== More Complex Configuration using "if" and "else" As of version 2.0, the server allows "if"-style checking in the configuration sections. The section is still processed as a list, so there is no looping or "goto" support. But by using "if", the administrator can have branching paths of execution, where none was possible before. The "if" syntax added in 2.0.0-pre0 has been completely re-written in 2.0.0-pre2, to add major new functionality. Documentation will be updated later... -= Virtual Modules +== Virtual Modules Some configurations may require using the same list of modules, in the same order, in multiple sections. For those systems, the configuration can be simplified through the use of "virtual" modules. These modules are configured as named sub-sections of the "instantiate" section, as follows:: ---- @@ -180,11 +180,11 @@ The name "sql1_or_2" can then be used in any other section, such as "authorize" These virtual modules are full-fledged objects in and of themselves. One virtual module can refer to another virtual module, and they can contain "if" conditions, or any other configuration permitted in a section. -= Redundancy and Load-Balancing +== Redundancy and Load-Balancing See load balancing for information on simple redundancy (fail-over) and load balancing. -= The Gory Details +== The Gory Details The fundamental object is called a MODCALLABLE, because it is something that can be passed a specific radius request and returns one of the RLM_MODULE_* results. It is a function - if you can accept the fact that pieces of radiusd.conf are functions. There are two kinds of MODCALLABLEs: GROUPs and SINGLEs. diff --git a/doc/antora/modules/tutorials/pages/final_group_project.adoc b/doc/antora/modules/tutorials/pages/final_group_project.adoc index f0efc7c31df..df7c8ad29b7 100644 --- a/doc/antora/modules/tutorials/pages/final_group_project.adoc +++ b/doc/antora/modules/tutorials/pages/final_group_project.adoc @@ -145,7 +145,7 @@ login, retrieve the user's password and store it in *Files:* -- xref:reference:raddb/mods-available/suffix.adoc[`etc/raddb/mods-available/suffix`] +//- xref:reference:raddb/mods-available/suffix.adoc[`etc/raddb/mods-available/suffix`] - xref:reference:raddb/mods-available/files.adoc[`etc/raddb/mods-available/files`] - `etc/raddb/mods-config/files/authorize` - xref:reference:raddb/mods-available/ldap.adoc[`etc/raddb/mods-available/ldap`]