+:module_name:
+
= Configuring the CHAP module
The xref:raddb:mods-available/chap.adoc[mods-available/chap]
the CHAP module, and what they do. This document explains how to
perform testing with the CHAP module
-The default server configuration should be tested via the following
-command:
-
-[source,shell]
-----
-radiusd -XC
-----
-
-If the configuration is correct, then the server will print the
-following message:
-
-[source,log]
-----
-Configuration appears to be OK
-----
-
-If that message does not appear, then it is necessary to correct any
-and all errors before proceeding to the next step. It is a good idea
-to ensure that the current configuration works _before_ making changes
-to it.
+include::howto:partial$pre_test.adoc[]
== Editing mods-available/chap
== Testing the Server
-The configuration of the server can be tested for syntactical
-correctness via the following command:
-
-[source,shell]
-----
-radiusd -XC
-----
-
-When the configuration is correct, then the server will print the
-following message:
-
-[source,log]
-----
-Configuration appears to be OK
-----
-
-Note that this test checks only that the configuration files can be
-parsed. It does not check that the LDAP server can be reached.
-
-When the configuration is correct, FreeRADIUS can then be started in debugging mode:
-
-[source,shell]
-----
-radiusd -X
-----
-
-If the `ldap` module has been configured correctly, the final (or
-almost final) message will be
-
-[source,log]
-----
-Ready to process requests
-----
-
-This message should be in bold on the console. Depending on which
-other modules are enabled, there may be a small number messages after
-this one.
-
-If the server starts, then the next step is then to perform
-authentication tests.
-
-=== Errors
-
-If the 'Ready to process requests` message does not appear, then the
-debug output will contain error messages clearly describing what went
-wrong. These error message *must* be read in order to gain insight as
-to the source of the problem.
-
-Otherwise, look for messages containing `ERROR` or `WARNING`, or
-the module name. While the server can produce a large volume of
-messages, most of those can be ignored when debugging a particular
-problem. Simply search for a few key strings based on the files you
-changed, and the solution to the problem should be clear.
-
-We recommend running the `radiusd -XC` test was performed before
-making any module changes for other reasons. If previous
-configuration worked, and the only change was to a particular module,
-then the source of the error is simple. There is no need to go
-searching through other configuration files or third-party web sites.
-Instead, change and test the module configuration until the server
-works.
+include::howto:partial$post_test.adoc[]
== Testing CHAP Authentication
...
----
-For the purposes of this test, the other debug messages can be
-ignored.
+For the purposes of this test, the other messages in the debug output
+can be ignored.
+
+In the above output, the `chap` module is first run in the `recv
+Access-Request { ... }` section. The module looks for `CHAP-Password`
+in the request packet, and if found, sets `Auth-Type := CHAP`. That
+setting tells the server core to call the `chap` module again for
+authentication.
+
+Once the `recv Access-Request { ... }` section has finished
+processing, the server calls the `authenticate chap { ... }` section.
+In the default configuration, that section contains just a reference
+to the `chap` module. The `chap` module finds a `Cleartext-Password`
+which has previously been added to the request, and performs the CHAP
+calculations. If the calculated CHAP values match the CHAP values in
+the request packet, then the user is authenticated. Otherwise,
+authentication fails and the user is rejected.
+
+This two-phase processing of CHAP ensures that the `chap` module is
+independent of any database. That is, the "known good" password can
+be obtained from any other module, such as `ldap`, `sql`, `files`,
+etc. The `chap` module only needs to know that it handles CHAP, and
+that it has been given a `Cleartext-Password` in order to authenticate
+the user. The source of that `Cleartext-Password` is unimportant.
+
+== Disabling CHAP
+
+The local system requirements may be that CHAP authentication is
+forbidden. In that case, the `chap` module should be removed from the
+`recv Access-Request { ... }` section, and the `authenticate chap {
+... }` section should be deleted. The server will then be unable to
+process CHAP authentication requests. All `Access-Request` packets
+that contain a `CHAP-Password` attribute will then result in an
+`Access-Reject`.
be validated via the xref:modules/ldap_search.adoc[`ldapsearch`]
command-line tool.
-The default server configuration should also be tested via the following command:
-
-[source,shell]
-----
-radiusd -XC
-----
-
-If the configuration is correct, then the server will print the
-following message:
-
-[source,log]
-----
-Configuration appears to be OK
-----
-
-If that message does not appear, then it is necessary to correct any
-and all errors before proceeding to the next step. It is a good idea
-to ensure that the current configuration works _before_ making changes
-to it.
+include::howto:partial$pre_test.adoc[]
== Editing mods-available/ldap
== Testing the Server
-The configuration of the server can be tested for syntactical
-correctness via the following command:
-
-[source,shell]
-----
-radiusd -XC
-----
-
-When the configuration is correct, then the server will print the
-following message:
-
-[source,log]
-----
-Configuration appears to be OK
-----
-
-Note that this test checks only that the configuration files can be
-parsed. It does not check that the LDAP server can be reached.
-
-When the configuration is correct, FreeRADIUS can then be started in debugging mode:
-
-[source,shell]
-----
-radiusd -X
-----
-
-If the `ldap` module has been configured correctly, the final (or
-almost final) message will be
-
-[source,log]
-----
-Ready to process requests
-----
-
-This message should be in bold on the console. Depending on which
-other modules are enabled, there may be a small number messages after
-this one.
-
-If the server starts, then the next step is then to test LDAP module
-with the xref:modules/ldap_authentication.adoc[authentication]
-process.
-
-=== Errors
-
-If the 'Ready to process requests` message does not appear, then the
-debug output will contain error messages clearly describing what went
-wrong. These error message *must* be read in order to gain insight as
-to the source of the problem.
-
-For example, the message `Can't contact LDAP server` means that there
-is a connection issue between the RADIUS server and the LDAP
-database. or that the LDAP module configuration is incorrect. The
-xref:modules/ldap_search.adoc[`ldapsearch`] validation tests must then
-be performed in order to verify both the connection, and the
-configuration parameters.
-
-Otherwise, look for messages containing `ERROR` or `WARNING` or
-`ldap`. While the server can produce a large volume of messages, most
-of those can be ignored when debugging a particular problem. Simply
-search for a few key strings based on the files you changed, and the
-solution to the problem should be clear.
+include::howto:partial$post_test.adoc[]
We recommend running the `radiusd -XC` test was performed before
-making any `ldap` module changes for other reasons. If previous
+making any `ldap` module changes for a few reasons. If previous
configuration worked, and the only change was to the `ldap` module,
then the source of the error is simple. There is no need to go
searching through other configuration files or third-party web sites.
Instead, change and test the module configuration until the server
works.
-
--- /dev/null
+After configuring the module, the server should be tested again
+via the following command:
+
+[source,shell]
+----
+radiusd -XC
+----
+
+When the configuration is correct, then the server will print the
+following message:
+
+[source,log]
+----
+Configuration appears to be OK
+----
+
+Note that this test checks only that the configuration files can be
+parsed. It does not check that the module works correctly when
+packets are received.
+
+When the configuration is correct, FreeRADIUS can then be started in debugging mode:
+
+[source,shell]
+----
+radiusd -X
+----
+
+If the module has been configured correctly, the final (or almost
+final) message will be
+
+[source,log]
+----
+Ready to process requests
+----
+
+This message should be in bold on the console. Depending on which
+other modules are enabled, there may be a small number messages after
+this one.
+
+If the server starts, then the next step is then to perform
+run-time tests.
+
+=== Errors
+
+If the 'Ready to process requests` message does not appear, then the
+debug output will contain error messages clearly describing what went
+wrong. These error message *must* be read in order to gain insight as
+to the source of the problem.
+
+Otherwise, look for messages containing `ERROR` or `WARNING`, or
+the module name. While the server can produce a large volume of
+messages, most of those can be ignored when debugging a particular
+problem. Simply search for a few key strings based on the files you
+changed, and the solution to the problem should be clear.
+
+We recommend running the `radiusd -XC` test was performed before
+making any module changes for other reasons. If previous
+configuration worked, and the only change was to a particular module,
+then the source of the error is simple. There is no need to go
+searching through other configuration files or third-party web sites.
+Instead, change and test the module configuration until the server
+works.
--- /dev/null
+The default server configuration should be tested via the following
+command:
+
+[source,shell]
+----
+radiusd -XC
+----
+
+If the configuration is correct, then the server will print the
+following message:
+
+[source,log]
+----
+Configuration appears to be OK
+----
+
+If that message does not appear, then it is necessary to correct any
+and all errors before proceeding to the next step. It is a good idea
+to ensure that the current configuration works _before_ making changes
+to it.
projects / thirdparty / freeradius-server.git / commitdiff
