From: Arran Cudbard-Bell Date: Thu, 24 Oct 2019 10:45:23 +0000 (-0400) Subject: Add final exercise X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=4e0c682a43fef3c55db01d2a5686dce83d2ef00f;p=thirdparty%2Ffreeradius-server.git Add final exercise --- diff --git a/doc/antora/modules/tutorials/nav.adoc b/doc/antora/modules/tutorials/nav.adoc index a31b8c708cd..55da7b4fc52 100644 --- a/doc/antora/modules/tutorials/nav.adoc +++ b/doc/antora/modules/tutorials/nav.adoc @@ -27,3 +27,5 @@ *** xref:dictionary.adoc[Dictionary] *** xref:virtual.adoc[Virtual] *** xref:radmin.adoc[Radmin] + +*** xref:final_group_project.adoc[Final group project] diff --git a/doc/antora/modules/tutorials/pages/final_group_project.adoc b/doc/antora/modules/tutorials/pages/final_group_project.adoc new file mode 100644 index 00000000000..c9e8aee05a7 --- /dev/null +++ b/doc/antora/modules/tutorials/pages/final_group_project.adoc @@ -0,0 +1,199 @@ += Group Project - Simulating a production service + +*Goal:* To create a simulated, federated, production service + +*Time:* 2-3 hours + +This task is split into multiple sections. If working with an instructor +you should ask for your configuration file to be validated by the instructor +after each section is complete. + +For this task you will need at least two participants. + +== Preparation + +Each participant should decide on the following: + +* A realm e.g. example.com, that their RADIUS server will respond to request for + the realm must be unique within the group. This will be referred to as + `your_realm` in the rest of the text. +* A shared secret for the realm `your_secret`. +* A backend module (`your_module`) to use to authenticate their users. Again, + this should be unique within the group. + Options are: +** `files` +** `ldap` +** `redis` +** `rest` +** `sql` + For everything except `files` it's recommended to pick a module where you're + familiar with the backend protocol. +* A set of credentials (`your_user`, `your_password`). These should not be + sensitive credentials as they will be seen by the rest of the group. + +Each user should send the following information to the instructor or place it in +a shared document: + +- `your_realm` +- `your_secret` +- `your_ip` (the public IP address of your test machine) +- `your_module` +- `your_user` +- `your_password` + +For local preparation, you should ensure that the following sections have no +content: + +- The `recv Access-Request { ... }` or `authorize { ... }` section of + `/etc/raddb/sites-available/default`. +- The `send Access-Accept { ... }` or `post-auth { ... }` section of + `/etc/raddb/sites-available/default`. + _Clear the `post-auth-type reject { ...}` section if present but do not remove_. +- The `send Access-Reject { ... }` section of `/etc/raddb/sites-available/default`. + +After completing each of the sections below, you should check that the +configuration you've produced is valid (radiusd -XC), and if possible, test the +functionality you've configured using `radtest` or `radclient`/ + +== Proxying + +*Goal:* To simulate federated access, by configuring proxy destinations for +multiple upstream home servers. + +*Files:* + +- `etc/raddb/proxy.conf` +- `etc/raddb/sites-available/default` (optionally) +- xref:raddb/mods-available/linelog.adoc[`etc/raddb/mods-available/linelog`] (optionally) + +*Time:* 20-30 minutes + +For each participant in the group, create a realm with a single home server. + +The information for the realm should come from the shared document, and should use +the realm name, the secret, and the ip address supplied by the participant. + +For `your_realm`, you should create a realm which authenticates users locally on +your server. + +Liveliness checks should be performed with 'status-server'. + +All realms should be configured with "nostrip", so the full username is proxied. + +=== Bonus tasks + +- When proxied requests fail, create a linelog message containing the date, the + username and the destination realm. +- Log all outbound packets to the proxy. +- Log all inbound packets from the proxy. +- Reduce the status-server check interval to three seconds. +- Reduce the status-server "number of answers until alive" to two seconds. + +== Clients + +*Goal:* Allow incoming requests from other servers. + +*Files:* + +- `etc/raddb/clients.conf` + +*Time*: 15-20 minutes + +Add client entries for each of the other participants server's, using +the participant's name as the client name, the ip of their server as `ipaddr` and +the secret they supplied as `secret`. + +== Loading credentials + +*Goal:* Setup the backend, and populate it with credentials. + +*Time:* 10-60 minutes + +For your chosen backend: + +- Install any necessary packages +- Load any FreeRADIUS specific schemas + +After the backend has bee setup insert your own credentials, and those for every +other participant in the group, into your backend datastore. + +If the datastore provides no authentication method (`sql`, `redis`), you should +use the value of `&Stripped-User-Name` as the key, and when the user attempts to +login, retrieve the user's password and store it in +`&control:Cleartext-Password`. + +== Authorization + +*Goal:* Retrieve user information from a backend datastore. + +*Files:* + +- xref:raddb:mods-available/suffix.adoc[`etc/raddb/mods-available/suffix`] +- xref:raddb:mods-available/files.adoc[`etc/raddb/mods-available/files`] +- `etc/raddb/users` +- xref:raddb:mods-available/ldap.adoc[`etc/raddb/mods-available/ldap`] +- xref:raddb:mods-available/rest.adoc[`etc/raddb/mods-available/redis`] +- xref:raddb:mods-available/rest.adoc[`etc/raddb/mods-available/rest`] +- xref:raddb:mods-available/sql.adoc[`etc/raddb/mods-available/sql`] + +*Time:* 20-60 minutes + +First, in the `recv Access-Request { ... }` or `authorize { ... }` section of +of an appropriate virtual server, call the suffix module. + +The following backend modules have an built in authorization method: + +- `files` +- `ldap` +- `rest` +- `sql` + +The redis module has a string expansion %{redis:} which can be used +to retrieve a single value from the datastore. + +Call the backend module's authorize method (or run an appropriate expansion) to +determine if the authenticating user exists in the datastore. + +If the user does exist, and your module has an authenticate method (`ldap`, +`rest`), set `&control:Auth-Type` to an appropriate value. + +If the backend module does not have an authenticate method (`redis`, `files`, +`sql`), you should ensure the "known good" copy of the user's password is set in +`&control:Cleartext-Password` and then call the pap module. + +=== Bonus tasks + +- If the user was `notfound` log this fact, along with the username, date and + client IP address. + +== Authentication + +*Goal:* Authenticate a user. + +*Time:* 20-30 minutes + +For `ldap` and `rest` add or uncomment an appropriate `Auth-Type` section. + +For other backend modules, ensure the PAP module's `Auth-Type` section is +uncommented. + +Run `radtest` or `radclient`, with credentials: +`@` and `your_password`. You should receive an Access-Accept. + +== Remote-Authentication + +*Goal:* Verify all participants have configured their RADIUS services correctly. + +*Time:* 20+ minutes + +Check with the other participants to see how much of the exercise they have +completed. If a participant has a working RADIUS server, send request +with `@` and `your_password`, and verify that +their server responds with an Access-Accept. + +If their server does not respond with an Access-Accept, work with the other +participant to debug the issue. + + +// Copyright (C) 2019 Network RADIUS SAS. Licenced under CC-by-NC 4.0. +// Development of this documentation was sponsored by Network RADIUS SAS.