[NOTE]
====
-A Makefile is can fulfill this requirement and have raddb checked every 5 minutes.
+A Makefile is can fulfill this requirement and can be used to check the configuration directory.
====
=== Why are all the Incoming Authentication-Request passwords corrupt?
-The shared secret is incorrect. This is a text string which is a "secret" (in the raddb/clients file) shared by both the NAS and the server. It is used to authenticate and to encrypt/decrypt packets.
+The shared secret is incorrect. This is a text string which is a "secret" (in the `clients.conf` file) shared by both the NAS and the server. It is used to authenticate and to encrypt/decrypt packets.
Run the server in xref:debugging/radiusd_X.adoc[debugging] mode:
Login failed [user/password] ...
-If the text *after* the slash is corrupted, then the shared secret is wrong. Delete it on *both* the NAS and the raddb/clients file and re-enter it. *Don't* check to see if they are the same, as there may be hidden spaces or other characters.
+If the text *after* the slash is corrupted, then the shared secret is wrong. Delete it on *both* the NAS and the `clients.conf` file and re-enter it. *Don't* check to see if they are the same, as there may be hidden spaces or other characters.
Another cause of corrupted passwords being logged is the secret being too long. Certain NAS boxes have limitations on the length of the secret and don't complain about it. FreeRADIUS is limited to 31 characters for the shared secret.
Once you have verified that Samba is installed and working correctly, and that the `ntlm_auth` program works, you can proceed with configuring FreeRADIUS to use ntlm_auth. For initial testing, we use the exec module, and will run the exact command line used in the previous testing step.
-Edit the `ntlm_auth` module configuration which saved as raddb/mods-enabled/ntlm_auth. The example snippet shown below needs to be updated with your site parameters which includes the path and domain.
+Edit the `ntlm_auth` module configuration which saved as `mods-enabled/ntlm_auth`. The example snippet shown below needs to be updated with your site parameters which includes the path and domain.
```
}
```
-This configuration tells the server to run the ntlm_auth program with the user name and password obtained from the Access-Request. You will also have to list ntlm_auth in the authenticate sections of each the raddb/sites-enabled/default file, and of the raddb/sites-enabled/inner-tunnel file:
+This configuration tells the server to run the ntlm_auth program with the user name and password obtained from the Access-Request. You will also have to list ntlm_auth in the authenticate sections of each the `sites-enabled/default` file, and of the `sites-enabled/inner-tunnel` file:
```
authenticate {
== Configure FreeRADIUS to use `ntlm_auth` for MS-CHAP
-Once you have the previous steps working, configure FreeRADIUS to use `ntlm_auth` for MS-CHAP. First, delete the testing entry used above from the users file, as leaving it in will break other authentication types. Then, find the mschap module in raddb/modules/mschap file, and look for the line containing `ntlm_auth = `. It is commented out by default, and should be uncommented, and edited to be as follows. As before, update the fields in bold to match your local configuration.
+Once you have the previous steps working, configure FreeRADIUS to use `ntlm_auth` for MS-CHAP. First, delete the testing entry used above from the users file, as leaving it in will break other authentication types. Then, find the mschap module in `mods-enabled/mschap` file, and look for the line containing `ntlm_auth = `. It is commented out by default, and should be uncommented, and edited to be as follows. As before, update the fields in bold to match your local configuration.
```
== Configure FreeRADIUS to use ntlm_auth for MS-CHAP
-Once you have the previous steps working, configuring FreeRADIUS to use `ntlm_auth` for MS-CHAP is simple. First, delete the testing entry used above from the `users` file, as leaving it in will break other authentication types. Then, find the mschap module in raddb/modules/mschap file, and look for the line containing `ntlm_auth = `. It is commented out by default, and should be uncommented, and edited to be as follows. As before, update the fields in bold to match your local configuration.
+Once you have the previous steps working, configuring FreeRADIUS to use `ntlm_auth` for MS-CHAP is simple. First, delete the testing entry used above from the `users` file, as leaving it in will break other authentication types. Then, find the mschap module in `mods-enabled/mschap` file, and look for the line containing `ntlm_auth = `. It is commented out by default, and should be uncommented, and edited to be as follows. As before, update the fields in bold to match your local configuration.
```
ntlm_auth = "/path/to/ntlm_auth --request-nt-key --allow-mschapv2 --username=%{mschap:User-Name:-None} --domain=%{%{mschap:NT-Domain}:-MYDOMAIN} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}"
8. Start the server with ``radiusd -X || freeradius -X``
9. Check that the ``eapol_test`` files work with *REAL* credentials.
10. Stop the server.
-11. Replace the dummy certs in the ``certs`` directory (``/etc/raddb/certs`` or ``/etc/freeradius/certs/``) with ones issued by [edupki](https://www.edupki.org) or a commerical certification authority.
+11. Replace the dummy certs in the ``certs`` directory (``${confdir}/certs``) with ones issued by [edupki](https://www.edupki.org) or a commerical certification authority.
12. Alter the ``eapol_test`` files so they specify a certification authority.
13. Check that the ``eapol_test`` files work with a *REAL* certificate, and *REAL* credentials.
14. Clone the config onto two servers (or clone the server).
# Uncomment to validate the server's certificate by checking
# it was signed by this CA.
- #ca_cert="raddb/certs/ca.pem"
+ #ca_cert="/path/to/freeradius/config/certs/ca.pem"
password="changeme"
phase2="auth=PAP"
}
# Uncomment to validate the server's certificate by checking
# it was signed by this CA.
- #ca_cert="raddb/certs/ca.pem"
+ #ca_cert="/path/to/freeradius/config/certs/ca.pem"
password="changeme"
phase2="auth=MSCHAPV2 mschapv2_retry=0"
phase1="peapver=0"
# Uncomment to validate the server's certificate by checking
# it was signed by this CA.
- #ca_cert="raddb/certs/ca.pem"
+ #ca_cert="/path/to/freeradius/config/certs/ca.pem"
# supplicant's public cert
- client_cert="raddb/certs/client.crt"
+ client_cert="/path/to/freeradius/config/certs/client.crt"
# supplicant's private key
- private_key="raddb/certs/client.key"
+ private_key="/path/to/freeradius/config/certs/client.key"
# password to decrypt private key
private_key_passwd="whatever"
(0) pap - Setting control.Auth-Type = pap
(0) pap (updated)
(0) } # recv Access-Request (updated)
-(0) Running 'authenticate pap' from file /usr/local/etc/raddb/sites-enabled/default
+(0) Running 'authenticate pap' from file /etc/raddb/sites-enabled/default
(0) authenticate pap {
(0) pap - Login attempt with password
(0) pap - Comparing with "known-good" Password.Cleartext (8)
(0) pap - User authenticated successfully
(0) pap (ok)
(0) } # authenticate pap (ok)
-(0) Running 'send Access-Accept' from file /usr/local/etc/raddb/sites-enabled/default
+(0) Running 'send Access-Accept' from file /etc/raddb/sites-enabled/default
...
----
(0) pap (noop)
(0) } # recv Access-Request (ok)
(0) ERROR: No Auth-Type available: rejecting the user.
-(0) Running 'send Access-Reject' from file /usr/local/etc/raddb/sites-enabled/default
+(0) Running 'send Access-Reject' from file /etc/raddb/sites-enabled/default
----
Here FreeRADIUS describes it:
** this is the recommended option
** fixing this, means you should see `Access-Accept` as described above
. configure FreeRADIUS to attempt to 'bind' (LDAP language for 'login') as the user in the RADIUS request
- ** do this by editing `/usr/local/etc/raddb/sites-available/default`
+ ** do this by editing `sites-available/default`
** amend by adding after the call to `ldap` in `recv Access-Request { ... }` section, so that it looks like:
+
[source,unlang]
(0) pap - WARNING: Authentication will fail unless a "known good" password is available
(0) pap (noop)
(0) } # recv Access-Request (ok)
-(0) Running 'authenticate ldap' from file /usr/local/etc/raddb/sites-enabled/default
+(0) Running 'authenticate ldap' from file /etc/raddb/sites-enabled/default
(0) authenticate ldap {
(0) ldap - Login attempt with password
(0) ldap - Reserved connection (1)
(0) ldap - Released connection (1)
(0) ldap (ok)
(0) } # authenticate ldap (ok)
-(0) Running 'send Access-Accept' from file /usr/local/etc/raddb/sites-enabled/default
+(0) Running 'send Access-Accept' from file /etc/raddb/sites-enabled/default
----
Here FreeRADIUS is describes it:
+++ /dev/null
-=== Authentication
-
-Now in another terminal window run on the FreeRADIUS server to test authentication:
-
-[source,shell]
-----
-cat <<'EOF' | radclient -x localhost auth testing123
-User-Name = "john"
-User-Password = "password"
-EOF
-----
-
-==== `Access-Accept`
-
-If this works you should see `radclient` report `Access-Accept` almostly immediately without delay:
-
-[source,log]
-----
-Sent Access-Request Id 39 from 0.0.0.0:47493 to 127.0.0.1:1812 length 44
- User-Name = john
- User-Password = password
-Received Access-Accept Id 39 from 127.0.0.1:1812 to 0.0.0.0:47493 via lo length 26
- User-Name = "john"
-----
-
-On the FreeRADIUS debug terminal side, you should see something like:
-
-[source,log]
-----
-...
-(0) ldap - Reserved connection (0)
-(0) ldap - EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}})
-(0) ldap - --> (uid=john)
-(0) ldap - Performing search in "dc=example,dc=com" with filter "(uid=john)", scope "sub"
-(0) ldap - Waiting for search result...
-(0) ldap - User object found at DN "uid=john,ou=people,dc=example,dc=com"
-(0) ldap - Processing user attributes
-(0) ldap - control.Password-With-Header += password
-(0) ldap - Released connection (0)
-(0) ldap (updated)
-...
-(0) pap - No {...} in Password-With-Header, re-writing to Cleartext-Password
-(0) pap - Normalized control.Password-With-Header -> control.Cleartext-Password
-(0) pap - Removing control.Password-With-Header
-(0) pap - Setting control.Auth-Type = pap
-(0) pap (updated)
-(0) } # recv Access-Request (updated)
-(0) Running 'authenticate pap' from file /usr/local/etc/raddb/sites-enabled/default
-(0) authenticate pap {
-(0) pap - Login attempt with password
-(0) pap - Comparing with "known-good" Cleartext-Password (8)
-(0) pap - User authenticated successfully
-(0) pap (ok)
-(0) } # authenticate pap (ok)
-(0) Running 'send Access-Accept' from file /usr/local/etc/raddb/sites-enabled/default
-...
-----
-
-Here FreeRADIUS is describing what it did:
-
- . used the `ldap` module
- ** searched for `(uid=john)` in `dc=example,dc=com`
- *** this is doing the same as the following that you could run on the CLI
-+
-[source,shell]
-----
-ldapsearch -LL -H ldap://localhost -x -D cn=freeradius,dc=example,dc=com -w mypassword -b dc=example,dc=com '(uid=john)'
-----
- ** found `uid=john,ou=people,dc=example,dc=com`
- *** if for you no user is found, but you know the user is in your directory, recheck the `user { ... }` section in `mods-available/ldap` as you may have a filter or attribute configuration set incorrectly
- ** found some useful attributes associated with that user
- *** the password which it placed into `control.Password-With-Header`
- *** as RADIUS attributes were changed, it returns `updated` as a result code to unlang
- . the modules `expiration` and `logintime` were used, but both had no effect (`noop`)
- . the module `pap` was used
- ** it found a suitable password to use in `Password-With-Header`
- *** populates `control.Cleartext-Password`
- *** the module decides it has everything it needs to do authentication so sets `control.Auth-Type = pap`
- *** as RADIUS attributes were changed, it returns `updated` as a result code to unlang
- . the authenticate section runs and hands off to `pap` as `control.Auth-Type = pap` was set earlier
- ** `control.Cleartext-Password` is compared to `request:User-Password`
- ** matches so `ok` is returned
- . we return `Access-Accept` as `ok` was returned to unlang
-
-This worked as the LDAP credentials used by FreeRADIUS to connect to the LDAP server is able to extract a the `userPassword` attribute; as could been seen from the example `ldapsearch` command provided earlier.
-
-==== `Access-Reject`
-
-If this fails, the response will be delayed by one second and `Access-Reject` will be returned:
-
-[source,shell]
-----
-Debug : Sent Access-Request Id 130 from 0.0.0.0:49353 to 127.0.0.1:1812 length 44
-Debug : Received Access-Reject Id 130 from 127.0.0.1:1812 to 0.0.0.0:49353 via lo length 20
-(0) -: Expected Access-Accept got Access-Reject
-----
-
-You should now look to the output of the debugging from the FreeRADIUS terminal window which may show something like:
-
-[source,log]
-----
-(0) ldap - Reserved connection (0)
-(0) ldap - EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}})
-(0) ldap - --> (uid=john)
-(0) ldap - Performing search in "dc=example,dc=com" with filter "(uid=john)", scope "sub"
-(0) ldap - Waiting for search result...
-(0) ldap - User object found at DN "uid=john,ou=people,dc=example,dc=com"
-(0) ldap - Processing user attributes
-(0) ldap - Released connection (0)
-(0) ldap (ok)
-(0) expiration (noop)
-(0) logintime (noop)
-(0) pap - WARNING: No "known good" password found for the user. Not setting Auth-Type
-(0) pap - WARNING: Authentication will fail unless a "known good" password is available
-(0) pap (noop)
-(0) } # recv Access-Request (ok)
-(0) ERROR: No Auth-Type available: rejecting the user.
-(0) Running 'send Access-Reject' from file /usr/local/etc/raddb/sites-enabled/default
-----
-
-Here FreeRADIUS describes it:
-
- . used the `ldap` module
- ** searched for `(uid=john)` in `dc=example,dc=com`
- ** found `uid=john,ou=people,dc=example,dc=com`
- ** did *not* find any useful attributes associated with that user
- ** module was successful in operation, but changed no RADIUS attributes so returns `ok`
- . the modules `expiration` and `logintime` were used, but both had no effect (`noop`)
- . the module `pap` was used
- ** it finds no suitable password RADIUS attributes to use
- ** as it makes no changes, the module returns `noop`
- . no `Auth-Type` is set, so FreeRADIUS rejects the request (no even attempting to authenticate)
- . returns `Access-Reject`
-
-This occurs as the LDAP credentials used by FreeRADIUS to connect to the LDAP server is *unable* to extract a the `userPassword` attribute; as could been seen from the example `ldapsearch` command provided earlier.
-
-You have two options avaliable to you here (`Ctrl-C` the running FreeRADIUS server, make the change and restart):
-
- . change the permissions of the LDAP credentials used so that FreeRADIUS can read the LDAP `userPassword` attribute
- ** this is the recommended option
- ** fixing this, means you should see `Access-Accept` as described above
- . configure FreeRADIUS to attempt to 'bind' (LDAP language for 'login') as the user in the RADIUS request
- ** do this by editing `/usr/local/etc/raddb/sites-available/default`
- ** amend by adding after the call to `ldap` in `recv Access-Request { ... }` section, so that it looks like:
-+
-[source,unlang]
-----
--ldap
-if ((ok || updated) && User-Password) {
- update {
- control.Auth-Type := ldap
- }
-}
-----
- ** FreeRADIUS is now configured to attempt to LDAP bind if the `ldap` module finds a user and the RADIUS request contains a `User-Password` RADIUS attribute
-
-If you use LDAP bind'ing to perform user authentication, then when `radclient` receives `Accept-Accept', the FreeRADIUS debug terminal will look like:
-
-[source,log]
-----
-(0) ldap - Reserved connection (0)
-(0) ldap - EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}})
-(0) ldap - --> (uid=john)
-(0) ldap - Performing search in "dc=example,dc=com" with filter "(uid=john)", scope "sub"
-(0) ldap - Waiting for search result...
-(0) ldap - User object found at DN "uid=john,ou=people,dc=example,dc=com"
-(0) ldap - Processing user attributes
-(0) ldap - Released connection (0)
-(0) ldap (ok)
-(0) if ((ok || updated) && User-Password) {
-(0) update {
-(0) control.Auth-Type := ldap
-(0) } # update (noop)
-(0) } # if ((ok || updated) && User-Password) (noop)
-(0) expiration (noop)
-(0) logintime (noop)
-(0) pap - WARNING: No "known good" password found for the user. Not setting Auth-Type
-(0) pap - WARNING: Authentication will fail unless a "known good" password is available
-(0) pap (noop)
-(0) } # recv Access-Request (ok)
-(0) Running 'authenticate ldap' from file /usr/local/etc/raddb/sites-enabled/default
-(0) authenticate ldap {
-(0) ldap - Login attempt with password
-(0) ldap - Reserved connection (1)
-(0) ldap - Login attempt by "john"
-(0) ldap - Using user DN from request "uid=john,ou=people,dc=example,dc=com"
-(0) ldap - Waiting for bind result...
-(0) ldap - Bind successful
-(0) ldap - Bind as user "uid=john,ou=people,dc=example,dc=com" was successful
-(0) ldap - Released connection (1)
-(0) ldap (ok)
-(0) } # authenticate ldap (ok)
-(0) Running 'send Access-Accept' from file /usr/local/etc/raddb/sites-enabled/default
-----
-
-Here FreeRADIUS is describes it:
-
- . used the `ldap` module
- ** searched for `(uid=john)` in `dc=example,dc=com`
- ** found `uid=john,ou=people,dc=example,dc=com`
- ** did *not* find any useful attributes associated with that user
- ** module was successful in operation, but changed no RADIUS attributes so returns `ok`
- . `control.Auth-Type := ldap` was set as the `ldap` module was successful in finding a user
- . the modules `expiration` and `logintime` were used, but both had no effect (`noop`)
- . the module `pap` was used
- ** it finds no suitable password RADIUS attributes to use
- ** as it makes no changes, the module returns `noop`
- . the authenticate section runs and hands off to `ldap` as `control.Auth-Type = ldap` was set earlier
- ** attemps to LDAP bind as `uid=john,ou=people,dc=example,dc=com`
- ** successful so `ok` is returned
- . we return `Access-Accept` as `ok` was returned to unlang
-
-// Copyright (C) 2025 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
-// This documentation was developed by Network RADIUS SAS.
+++ /dev/null
- ** in the `group { ... }` section
- *** check that `filter` can match your groups when searched for
- **** for Active Directory you may need to use `(objectClass=group)` instead
- *** referring to your notes above on how your LDAP server handles authorization, if it uses the LDAP attribute in:
- **** *a dedicated group object (ie. `member`):* uncomment `membership_filter` and possibility amend the value
- **** *the user object (ie. `memberOf`):* check `membership_attribute` is set apprioately
- . enabled the LDAP module
-
-// Copyright (C) 2025 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
-// This documentation was developed by Network RADIUS SAS.
[source,shell]
----
-cd /etc/raddb/sites-enabled
+cd sites-enabled
ln -s ../sites-available/tls
----
====
If the example certificates are not present (for example if FreeRADIUS was
installed from source) then FreeRADIUS will fail to start. The files can be
-regenerated by running `make` in the `/etc/raddb/certs` directory.
+regenerated by running `make` in the `certs` directory.
====
Edit the `tls` virtual server configuration, in order to add
definitions for the clients by extending the `clients radsec {}` section:
-.Example radsec client definitions in `/etc/raddb/sites-available/tls`
+.Example radsec client definitions in `sites-available/tls`
====
clients radsec {
that it accepts all authentication reqeusts and immediately responds
to accounting requests.
-Edit the `/etc/raddb/sites-enabled/default` file so that the beginning of
+Edit the `sites-enabled/default` file so that the beginning of
the `authorize` and `preacct` sections looks as follows:
.Example default virtual server modification to unconditionally accept Access-Requests
For example, say there were two home server pools, pool_a and pool_b, and twenty realms, ten of which used one pool, and ten the other. Listing the home servers of pool_a in ten realms, and the servers of pool_b in another ten realms, starts to lead to a lot of duplication.
-Instead, create a new policy file, raddb/policy.d/proxy and define two policies, proxy_pool_a and proxy_pool_b:
+Instead, create a new module, `policy.d/proxy` and define two policies, `proxy_pool_a` and `proxy_pool_b`:
```
proxy_pool_a {
Add a new `tls` home server definition, which will point to the RadSec
server. We do this by creating a file
-`/etc/raddb/sites-enabled/radsec-homeserver` with the following
+`sites-enabled/radsec-homeserver` with the following
contents:
.Example homeserver, pool and realm definitions for the RadSec service
[TIP]
====
Complete descriptions of each of the above configuration items can be found in the
-`[raddb]/sites-available/tls` example configuration file. For simple tests, however,
+`sites-available/tls` example configuration file. For simple tests, however,
we can omit all of the comments from the file.
====
To use this `tls` home server, we change the `default` virtual server to proxy
all authentication and accounting requests to it.
-Edit the `/etc/raddb/sites-enabled/default` file so that the beginning of
+Edit the `sites-enabled/default` file so that the beginning of
the `authorize` and `preacct` sections looks as follows:
.Example default virtual server modification to proxy requests to a RadSec proxy server
|===
|File|Corresponding configuration item|Purpose
-|/etc/raddb/certs/ca.pem
+|certs/ca.pem
|`ca_file`
|CA certificate which is used to authenticate the server certificate presented by the RadSec server to the client.
-|/etc/raddb/certs/client.pem
+|certs/client.pem
|`certificate_file`
|Client certificate (signed by the CA certificate) that is presented by the test client to the RadSec server.
-|/etc/raddb/certs/client.pem
+|certs/client.pem
|`private_key_file` and `private_key_password`
|Private key corresponding to the client certificate
|===
Now edit the test RadSec client, so that instead of making connections directly
to the RadSec server it makes connections to the HAproxy server.
-On `radseccli` edit the `/etc/raddb/sites-enabled/tls` file, and set
+On `radseccli` edit the `sites-enabled/tls` file, and set
the IP address to the address of the `haproxy` host.
.Example updated test client homeserver configuration
Now amend the test RadSec client so that instead of making connections directly
to the RadSec server it makes them via Traefik.
-On `radseccli` amend `/etc/raddb/sites-enabled/tls` and set the IP address to
+On `radseccli` amend `sites-enabled/tls` and set the IP address to
that of the `traefik` host.
.Example updated test client homeserver configuration
.sp
\fB\-n name\fP
.RS 4
-Read \f(CRraddb/name.conf\fP instead of \f(CRraddb/radiusd.conf\fP.
+Read \f(CRname.conf\fP instead of \f(CRradiusd.conf\fP.
.sp
Note that by default, the server looks for a configuration file
which matches its own name. Creating a soft link from file \f(CRfoo\fP
to \f(CRradiusd\fP, and then running the program \f(CRfoo\fP, will cause the
-binary to look for \f(CRraddb/foo.conf\fP.
+binary to look for \f(CRfoo.conf\fP.
.RE
.sp
\fB\-s\fP
or SQL), then:
.br
-a) Edit \f(CRraddb/modules/foo\fP
+a) Edit \f(CRmods-available/foo\fP
.br
This file contains the default configuration for the module. It contains
entries mean.
.br
-b) Edit \f(CRraddb/sites\-available/default\fP
+b) Edit \f(CRsites\-available/default\fP
.br
This file contains the default policy for the server. e.g. "enable CHAP,
from the lines referencing the module. This enables the module.
.br
-c) Edit \f(CRraddb/sites\-available/inner\-tunnel\fP
+c) Edit \f(CRsites\-available/inner\-tunnel\fP
.br
This file contains the default policy for the "tunneled" portion of
.URL "http://www.freeradius.org" "" ")"
.SH "AUTHOR"
.sp
-Alan DeKok
\ No newline at end of file
+Alan DeKok
. sp -1
. IP \(bu 2.3
.\}
-Read \fIraddb/name.conf\fP instead of \fIraddb/radiusd.conf\fP.
+Read \fIname.conf\fP instead of \fIradiusd.conf\fP.
.RE
.sp
.RS 4
.RE
.SH "SEE ALSO"
.sp
-unlang(5), radiusd.conf(5), raddb/sites\-available/control\-socket
+unlang(5), radiusd.conf(5), sites\-available/control\-socket
.SH "AUTHOR"
.sp
Alan DeKok <\c
.MTO "aland\(atfreeradius.org" "" ">"
.SH "AUTHOR"
.sp
-Alan DeKok
\ No newline at end of file
+Alan DeKok
```
Send an Access-Challenge.
-See raddb/policy.d/control for the definition
+See policy.d/control for the definition
of "challenge"
```
```
```
-// Copyright (C) 2025 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
+// Copyright (C) 2026 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
// This documentation was developed by Network RADIUS SAS.
xref:raddb/mods-available/sqlippool.adoc[SQL] or
xref:raddb/mods-available/redis_ippool.adoc[Redist]
-See raddb/mods-config/sql/ippool/ for the SQL schemas.
+See mods-config/sql/ippool/ for the SQL schemas.
1. Why is it necessary for each server to mark some realms as local?
2. What would happen if each user did not configure the other RADIUS
-server in the "raddb/clients.conf" file?
+server in the `clients.conf` file?
3. What would happen if each user did not configure the realms to
"strip" the realm from the proxied requests?
projects / thirdparty / freeradius-server.git / commitdiff
