*File:*
-- `raddb/sites-available/default`
+- `sites-available/default`
*Documentation pages:*
----
We have defined the cleartext password for the user `bob` here,
-instead of defining it in `raddb/mods-config/files/authorize`, as
+instead of defining it in `mods-config/files/authorize`, as
usual.
Execute the following command to test this configuration:
*Files:*
-- `etc/raddb/sites-available/default`
-- `etc/raddb/users`
+- `sites-available/default`
+- `mods-config/files/authorize`
This exercise is a follow-up to the previous one in
xref:multiple_modules.adoc[Multiple Modules], and it uses the `byname` and `bydate` modules
Fall-Through = 1
----------------------------
-In the `raddb/sites-available/default` file, edit the `authorize` section entries for
+In the `sites-available/default` file, edit the `authorize` section entries for
the `byname` and `bydate` modules to be as follows:
----------------------
*Files:*
-- `etc/raddb/radiusd.conf`
-- `etc/raddb/users`
+- `radiusd.conf`
+- `mods-config/files/authorize`
Run-time variables in the server may include more than simple references to
attributes in packets. The server supports the ability to perform complex
exercise, we will work through a number of different examples of configuring
inter-module calls.
-To start, open `raddb/mods-available/exec` and read the sample configuration for
+To start, open `mods-available/exec` and read the sample configuration for
the `exec` module. Then, edit the users file to add the following entry at the
top:
*File:*
-- `etc/raddb/mods-available/eap`
+- `mods-available/eap`
*Diagram:*
EAP is for wireless authentication. In this exercise, we will configure
and test the EAP-MD5 sub-type of EAP.
-`raddb/mods-available/eap` has a configuration section for the `eap`
+`mods-available/eap` has a configuration section for the `eap`
module. The EAP sub-types are configured inside of that section. By
default, the server ships with the EAP-MD5 module enabled, and with the
EAP module initiating EAP-MD5 for all RADIUS requests containing EAP.
-You should now read the appropriate section of the `raddb/mods-available/eap`
+You should now read the appropriate section of the `mods-available/eap`
file, to verify that the `eap` module is configured and that the `md5`
sub-module of the `eap` module is configured.
*File:*
-- `etc/raddb/mods-available/eap`
+- `mods-available/eap`
*Diagram:*
For the initial testing of EAP-PEAP, we recommend using
`EAP-MSCHAPv2` on the wireless client as the tunneled authentication
protocol. You should check that the `mschap` module is configured in the
-`raddb/modules` directory. The `mschapv2` module performs EAP-MSCHAPv2
+`modules` directory. The `mschapv2` module performs EAP-MSCHAPv2
authentication and is contained in the `eap` section of the
-`raddb/eap.conf`. While these authentication methods are similar, they
+`eap.conf`. While these authentication methods are similar, they
are not identical. Both modules need to be configured for EAP-PEAP to
work.
*Files:*
-- `etc/raddb/mods-available/eap`
+- `mods-available/eap`
- `scripts/certs.sh`
-- `etc/raddb/certs/`
+- `certs/`
EAP-TLS is an authentication protocol that uses a TLS session, along
with client and server certificates, to authenticate a user. You
authority. These certificates may be used for this exercise, but should
not be used in any live deployment of the server.
-You now edit the `etc/raddb/mods-available/eap` file to enable
+You now edit the `mods-available/eap` file to enable
the `tls`. You should also set the configuration entry `default_eap_type`
to `tls`.
client software for details on this process.
The wireless client will require the client certificate from the
-`raddb/certs` directory.
+`certs` directory.
Once the wireless client has been configured to enable EAP-TLS,
you should perform a test authentication to the server. If all goes well,
*File:*
-- `etc/raddb/sites-available/default`
+- `sites-available/default`
*Diagram:*
*Files:*
-- xref:reference:raddb/mods-available/radius.adoc[`etc/raddb/mods-available/radius`]
-- xref:reference:raddb/sites-available/default.adoc[`etc/raddb/sites-available/default`] (optionally)
-- xref:reference:raddb/mods-available/linelog.adoc[`etc/raddb/mods-available/linelog`] (optionally)
+- xref:reference:raddb/mods-available/radius.adoc[`mods-available/radius`]
+- xref:reference:raddb/sites-available/default.adoc[`sites-available/default`] (optionally)
+- xref:reference:raddb/mods-available/linelog.adoc[`mods-available/linelog`] (optionally)
*Time:* 20-30 minutes
*Files:*
-- xref:reference:raddb/clients.conf.adoc[`etc/raddb/clients.conf`]
+- xref:reference:raddb/clients.conf.adoc[`clients.conf`]
*Time*: 15-20 minutes
*Files:*
-//- 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`]
-- xref:reference:raddb/mods-available/redis.adoc[`etc/raddb/mods-available/redis`]
-- xref:reference:raddb/mods-available/rest.adoc[`etc/raddb/mods-available/rest`]
-- xref:reference:raddb/mods-available/sql.adoc[`etc/raddb/mods-available/sql`]
+//- xref:reference:raddb/mods-available/suffix.adoc[`mods-available/suffix`]
+- xref:reference:raddb/mods-available/files.adoc[`mods-available/files`]
+- `mods-config/files/authorize`
+- xref:reference:raddb/mods-available/ldap.adoc[`mods-available/ldap`]
+- xref:reference:raddb/mods-available/redis.adoc[`mods-available/redis`]
+- xref:reference:raddb/mods-available/rest.adoc[`mods-available/rest`]
+- xref:reference:raddb/mods-available/sql.adoc[`mods-available/sql`]
*Time:* 20-60 minutes
configuration entry will cause the server to continue processing the
file.
-Add the following configuration to `raddb/mods-config/files/authorize`:
+Add the following configuration to `mods-config/files/authorize`:
[source,text]
----
assign him the IP address 192.168.10.12. This entry should also cause
the server to continue processing the file.
-Update `raddb/mods-config/files/authorize` with this additional entry:
+Update `mods-config/files/authorize` with this additional entry:
[source,text]
----
and will assign them a default route of 192.168.10.1 with netmask of
255.255.255.0.
-Add this final entry to `raddb/mods-config/files/authorize`:
+Add this final entry to `mods-config/files/authorize`:
[source,text]
----
*Files:*
-- `etc/raddb/mods-available/detail`
+- `mods-available/detail`
- `usr/share/doc/freeradius*/configurable_failover`
- `/var/log/radius/radacct/detail1`
- `/var/log/radius/radacct/detail2`
The first step is to configure the server to have two instances of the
`detail` module. The following information should be added to the
-`etc/raddb/mods-available/detail` file:
+`mods-available/detail` file:
--------------------------------------------------
detail detail1 {
In the file `configurable_failover` in the documentation directory,
there is a section titled "More Complex Configurations". This section contains a
-sample entry for the "accounting" section of `etc/raddb/sites-available/default`.
+sample entry for the "accounting" section of `sites-available/default`.
The sample entry is a "group" with configurable fail-over between two modules named
`detail1` and `detail2`. Copy the "group" section to the start of the
-`accounting` section in your `etc/raddb/sites-available/default` file.
+`accounting` section in your `sites-available/default` file.
Now start the server and verify that it is `Ready to process requests.`
*File:*
-- `etc/raddb/clients.conf`
+- `clients.conf`
The RADIUS server will only communicate with known clients. This
restriction is for security, so that unknown machines on the Internet
*Files:*
-- `etc/raddb/mods-available/counter`
+- `mods-available/counter`
Many system administrators wish to implement "prepaid" billing for
their systems. In this exercise, we will configure the server to use a
simple "prepaid" scheme, wherein all users will be permitted to log in
for only one hour a day.
-Read `etc/raddb/mods-available/counter` and look for the `counter daily` instance
+Read `mods-available/counter` and look for the `counter daily` instance
The documentation for the module consists solely of the comments in
-`etc/raddb/mods-available/counter`, so those comments should be read carefully.
+`mods-available/counter`, so those comments should be read carefully.
Search the rest of the configuration file for references to the `daily` module
and un-comment any references you find.
*File:*
-- `etc/raddb/proxy.conf`
+- `proxy.conf`
*Diagram:*
(the uber user)).
You will configure a realm, called "realm1" in the
-`raddb/proxy.conf` file. This realm will be proxied to the RADIUS server
+`proxy.conf` file. This realm will be proxied to the RADIUS server
administered by the uber user, who will supply the IP address, port,
and shared secret used by their RADIUS server. The entry for the home
server in `proxy.conf` will be configured to "strip" the realm name
*Files:*
-- `etc/raddb/proxy.conf`
-- `etc/raddb/clients.conf`
+- `proxy.conf`
+- `clients.conf`
*Diagram:*
*File:*
-- `etc/raddb/proxy.conf`
+- `proxy.conf`
*Diagram:*
*Files:*
-- `etc/raddb/proxy.conf`
-- `etc/raddb/clients.conf`
+- `proxy.conf`
+- `clients.conf`
For this exercise, the users will be divided into groups of two. One
user will be named "realm1" and the other will be named
*File:*
-- `etc/raddb/sites-enabled/control-socket`
+- `sites-enabled/control-socket`
*`man` page:* radmin, raddebug
*Files:*
-- `etc/raddb/users`
+- `mods-config/files/authorize`
For this exercise, you are assumed to have previously worked
through, and be familiar with, the accounting exercise from
*File:*
-- `etc/raddb/mods-available/sql`
-- `etc/raddb/mods-config/sql/main/*`
+- `mods-available/sql`
+- `mods-config/sql/main/*`
In addition to the file, the server may obtain user configuration
information from an SQL database. In this exercise, you will
The SQL schema used by FreeRADIUS is designed to mirror the users file.
Each SQL dialect has its own set of schema and configuration files.
-They are located in the `raddb/mods-config/sql/main/<dialect>` directory.
+They are located in the `mods-config/sql/main/<dialect>` directory.
The schema is defined by the "schema.sql" file, and the queries are
defined by the `queries.conf` file.
-The main configuration for the SQL module is `raddb/mods-available/sql`
+The main configuration for the SQL module is `mods-available/sql`
it will `$INCLUDE` the appropriate "queries.conf" file for the dialect
chosen.
========================================================================
Unless there is a pre-configured database available we recommend the
sqlite driver be used. If the sqlite specific stanzas are uncommented
-in `raddb/mods-available/sql` it will automatically bootstrap a new
+in `mods-available/sql` it will automatically bootstrap a new
database using the bundled schema.
========================================================================
now, we are interested solely in making the FreeRADIUS server
communicate with the SQL server.
-Open `raddb/mods-available/sql` verify that the first few configuration
+Open `mods-available/sql` verify that the first few configuration
entries are correct. That is, the "server", "login", and "password"
entries should be set up correctly for your local SQL database.
installed in the appropriate library directory.
Once you have verified that the SQL driver exists, have enabled the module
-by creating a symlink from `raddb/mods-available/sql` to
-`raddb/mods-enabled/sql` and you have configured the appropriate sql dialect,
+by creating a symlink from `mods-available/sql` to
+`mods-enabled/sql` and you have configured the appropriate sql dialect,
you should start the server as usual:
------------
*File:*
-- `etc/raddb/mods-available/sql`
-- `etc/raddb/mods-config/sql/main/*`
+- `mods-available/sql`
+- `mods-config/sql/main/*`
Now that we have verified in the previous exercise,
xref:sql.adoc[SQL] that the server can communicate with
As the previous exercise in xref:sql.adoc[SQL]
did not tell the server to query the database, but only to connect to it,
we must now configure FreeRADIUS to query the database. This may be done
-by editing `etc/raddb/sites-available/default`, and listing the `sql`
+by editing `sites-available/default`, and listing the `sql`
module in the "authorize" section.
There should already be a commented-out entry for `sql` in the
request. Verify that the SQL module returns "ok", rather than
"notfound".
-If necessary, edit the `etc/raddb/mods-enabled/sql` file, and enable
+If necessary, edit the `mods-enabled/sql` file, and enable
additional debugging of SQL statements via the `sqltrace` and `sqltracefile`
configuration options. If the SQL queries are performed by the server and
logged to the file, but the request for user "bob" is still rejected, then
3. Why is there no "Fall-Through" entry in an SQL database?
4. Does that DEFAULT entry differ from its use in the file? If so, why,
and how? If not, why not?
-5. What other configuration entries in `etc/raddb/sites-available/default`
+5. What other configuration entries in `sites-available/default`
exist for the `sql` module, and why?
// Copyright (C) 2021 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
*Files / Directories:*
-- `etc/raddb/policy.d/*` (policy.d where we create and define policies)
-- `etc/raddb/sites-available/default` (virtual server where we call the policy)
+- `policy.d/*` (policy.d where we create and define policies)
+- `sites-available/default` (virtual server where we call the policy)
== Preparation
*File:*
-- `etc/raddb/policy.d/*`
+- `policy.d/*`
*`man` page:* unlang
*Time:* 10-20 minutes
*File:*
-- `etc/raddb/policy.d/*`
+- `policy.d/*`
*`man` page:* `unlang`
}
----
-Add the above created policy into `raddb/sites-available/default`:
+Add the above created policy into `sites-available/default`:
[source,unlang]
----
}
----
-Also make sure our testing user "bob" exists in `raddb/mods-config/files/authorize`:
+Also make sure our testing user "bob" exists in `mods-config/files/authorize`:
[source,unlang]
----
*Files:*
-- `etc/raddb/radiusd.conf`
+- `radiusd.conf`
- `etc/mods-config/files/authorize`
-- `etc/raddb/mods-available/detail`
+- `mods-available/detail`
*`man` page:* `radiusd.conf`
The main configuration file `radiusd.conf` and the module configuration
files contains a number of examples of the use of variables. For example,
-the `detail` module (configured in `etc/raddb/mods-enabled/detail`)
+the `detail` module (configured in `mods-enabled/detail`)
has a configuration entry named "filename", which by default has the
following value:
If you don't see any configuration printed for the `detail` file module
ensure it is uncommented in the `accounting {}` section of the
-`raddb/sites-available/default` virtual server.
+`sites-available/default` virtual server.
[source]
----
*File:*
-- `etc/raddb/sites-enabled/virtual`
+- `sites-enabled/virtual`
*documentation page:* raddb/sites-available/README
- *preacct* The pre-accounting section
- *accounting* The accounting section
-Create a new file `raddb/sites-enabled/virtual`. Put the following text
+Create a new file `sites-enabled/virtual`. Put the following text
into it:
-----------------------------------------------