From: Alan T. DeKok Date: Mon, 17 Jul 2023 12:50:35 +0000 (-0400) Subject: clean up X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=7bc1603f4e38c7752dce9d3314f33df276ea6f2d;p=thirdparty%2Ffreeradius-server.git clean up delete advice and descriptions which are ancient and out of date --- diff --git a/doc/antora/modules/concepts/pages/aaa.adoc b/doc/antora/modules/concepts/pages/aaa.adoc index defa64fde5f..b44ec434955 100644 --- a/doc/antora/modules/concepts/pages/aaa.adoc +++ b/doc/antora/modules/concepts/pages/aaa.adoc @@ -12,83 +12,47 @@ FreeRADIUS as a proxy): authorization and authentication. === Authorization -Authorization is a process of obtaining information about the user from -external source (file, database or LDAP), and checking that the -information in request is enough to authenticate user. Authorization -modules deal with data sources, so ldap, sql, files, passwd are -authorization modules. - -The authentication method is decided during the authorization phase, -along with any reply attributes. The reason for this behaviour is that -for example, a user may not be permitted to use a particular -authentication method. So during the authorize phase, we can deny them -the ability to use that kind of authentication. +Authorization is the process of finding and returning information +about what the user is allowed to do. For example, finding out what +kind of authentication methods they are allowed to run, and what VLAN +the user should be placed into. + +Authorization modules generally "get data" from somewhere, +e.g. `ldap`, `sql`, `files`, etc. + +The authentication method is usually determined when the server gets +the users credentials from a database. Once the credentials are +available, the server can authenticate the user. === Authentication Authentication is simply a process of comparing user’s credentials in -request with credentials stored in database. Authentication usually -deals with password encryption. `PAP`, `CHAP`, `MS-CHAP` are authentication -modules. Few modules act as both authorization and authentication. For -example, the `MS-CHAP` module is normally authentication only, but it may -be used during authorization to verify that request contains `MS-CHAP` -related attribute and only in this case perform `MS-CHAP` based -authentication. `LDAP` is normally an authorization module, but it may be -used for authentication (In this case FreeRADIUS will authenticate user -in case he can connect to LDAP server with his account). SQL is only an -authorization module, as dial-in users are not normally given passwords -to access an SQL server. +request with the "known good" credentials retrieved from a +database. Authentication usually deals with password +encryption. The modules `pap`, `chap`, `mschap`, etc. do authentication. + +Some modules do both authentication and limited authorization. For +example, the `mschap` module authenticates MS-CHAP credentials, but it +may also be used as an authorization module, which verifies that +request contains `MS-CHAP` related attribute. If so, the module +instructs the server to use `mschap` for authentication, too + +These dual modules are usually related to protocol-specific +attributes, such as the `pap` module for the `User-Password` +attribute, `chap` for `CHAP-Password, `mschap` for `MS-CHAP-*`, etc. === Request Processing -During authorization and authentication processes, there are 3 lists of -RADIUS attributes supported by FreeRADIUS: request items, config items -and reply items. (See `man 5 users` for additional information.) -Attributes from the RADIUS authentication request packet are included -into request items list. Both authorization and authentication modules -can add attributes into reply items list. These attributes will be added -to reply will be sent by RADIUS server to NAS. There is third list, -called config items. It’s used for internal FreeRADIUS operations, for -example to pass some data from authorization to authentication module. - -Before authorization begins FreeRADIUS creates request items list with -attributes from request and empty config and reply lists. - -An authorization module searches a database with attributes -(e.g. `User-Name`) taken from request list as a key, and fetches all -relevant records. It retrieves 3 types of attributes: check attributes, -configure attributes and reply attributes. It compares the check -attributes with attributes from request items. If none of database -record for this `User-Name` matches in check attributes with request items -authorization will fail. If a matching record is found, then the -configure attributes will be added to configure items, and the reply -attributes will be added to reply items list. The check list may be -required if we need to authenticate users with same name for different -services (for example to treat User1 from NAS1 and User1 from NAS2 as -different users). - -There should be at list one configure attribute provided by -authorization module, called `Auth-Type` (since this attribute is from -config items list it can’t be in request or reply). This attribute -decides which module will be used to authenticate the user. The Config -items also contains information from database required to authenticate -user, for example valid user’s password or it’s hash, login -restrictions, etc. - -A quite common mistake is to place the attributes in the wrong lists, -for example placing `Auth-Type`, `Password`, `Password.NT` etc in the check -list, or in the reply list. When run in debugging mode, the server will -normally issue `WARNING` messages saying that the attributes are in the -wrong list. - -If you place Password into check list and user does cleartext -authentication it may work, because authorization module compares 2 -cleartext passwords. But if user does some encrypted authentication (for -example `MS-CHAP`), then the authorization will fail, because the Password -in the request items will not match the password in the check -attributes. You should place Password attribute obtained from database -into configure items and also place Auth-Type attribute with value of -`MS-CHAP` into same list. The same goes for `Password.NT` (before calling -`MS-CHAP` Password attribute should be converted to `Password.NT`, it may be -achieved by calling mschap module in authorization section after module -which does actual authorization). +When the server processes requests, it manages four +xref:reference:unlang/list.adoc[attribute lists]: + +`request`:: attributes taken from the received packet + +`reply`:: attributes which will be sent in the reply + +`control`:: attributes used to control how the server operates. These are never sent in a packet + +`session-state`:: attributes which are saved and restroed across multiple request / reply exchanges. + +All of these lists are available to all modules. All of these lists are available in xref:reference:unlang/index.adoc[Unlang] +