Freeradius users operators

Question

I faced with one issue, which I can't understand in Freeradius users file. My goal is just authenticate external user "shad" with password "test". I added line in /etc/raddb/users the following line: shad Cleartext-Password == "test" Result was Reject. If I change "==" operator to ":=" Authentication is successful. So my question is the following: Why I can't use "==" operator while FreeRadius documentation tells: "Attribute == Value As a check item, it matches if the named attribute is present in the request, AND has the given value."

And one more question. In some resourses I faced with such lines: shad Auth-Type := Local, User-Password == "test" I tried and it doesn't work. Responce is Reject with log: [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this.

Solution

How the users file works

For the answer below, pairs is referring to Attribute Value Pairs (AVPs), that is, a tuple consisting of an attribute an operator and a value.

There are three lists of attribute(s) (pairs) that are accessible from the users file. These are bound to the request the server is currently processing, and they don't persist across multiple request/response rounds.

• request - Contains all the pairs from the original request received from the NAS (Network Access Server) via the network.
• control - Initially contains no pairs, but is populated with pairs that control how modules process the current request. This is done from the users file or unlang (the FreeRADIUS policy language used in virtual servers).
• reply - Contains pairs you want to send back to the NAS via the network.

The users file module determines the list it's going to use for inserting/searching, by where the pair is listed in the entry, and the operator.

The first line of the entry contains check pairs that must match in order for the entry to be used. The first line also contains control pairs, those you want to be inserted into the control list if all the check pairs match.

Note: It doesn't matter which order the pairs are listed in. control pairs will not be inserted unless all the check pairs evaluate to true.

check and control pairs are distinguished by the operator used. If an assignment operator is used i.e. ':=' or '=' then the pair will be treated as a control pair. If an equality operator such as '>', '<', '==', '>=', '<=', '=~' is used, the pair will be treated as a check pair.

Subsequent lines in the same entry contain only reply pairs. If all check pairs match, reply pairs will be inserted into the reply list.

Cleartext-Password

Cleartext-Password is strictly a control pair. It should not be present in any of the other lists.

Cleartext-Password is one of a set of attributes, which should contain the 'reference' (or 'known good') password, that is, the local copy of the users password. An example of another pair in this set is SSHA-Password - this contains a salted SHA hash of the users password.

The reference password pairs are searched for (in the control list) by modules capable of with authenticating users using the 'User-Password' pair. In this case that module is 'rlm_pap'.

User-Password

User-Password is strictly a request pair. It should not be present in any of the other lists.

User-Password is included in the request from the NAS. It contains the plaintext version of the password the user provided to the NAS. In order to authenticate a user, a module needs to compare the contents of User-Password with a control pair like Cleartext-Password.

In a users file entry when setting reference passwords you'll see entries like:

my_username Cleartext-Password := "known_good_password"

That is, if the username matches the value on the left (my_username), then insert the control pair Cleartext-Password with the value "known_good_password".

To answer the first question the reason why:

shad Cleartext-Password == "test"

Does not work, it is because you are telling the files module to search in the request list, for a pair which does not exist in the request list, and should never exist in the request list.

You might now be thinking oh, i'll use User-Password == "test" instead, and it'll work. Unfortunately it won't. If the password matches then the entry will match, but the user will still be rejected, see below for why.

Auth-Type

Auth-Type is strictly a control pair. It should not be present in any of the other lists.

There are three main sections in the server for dealing with requests 'authorize', 'authenticate', 'post-auth'.

authorize is the information gathering section. This is where database lookups are done to authorise the user, and to retrieve reference passwords. It's also where Auth-Type is determined, that is, the type of authentication we want to perform for the user.

Authenticate is where a specific module is called to perform authentication. The module is determined by Auth-Type.

Post-Auth is mainly for logging, and applying further policies, the modules run in Post-Auth are determined by the response returned from the module run in Authenticate.

The modules in authorize examine the request, and if they think they can authenticate the user, and Auth-Type is not set, they set it to themselves. For example the rlm_pap module will set Auth-Type = 'pap' if it finds the User-Password in the request.

If no Auth-Type is set the request will be rejected.

So to answer your second question, you're forcing pap authentication, which is wrong, you should let rlm_pap set the Auth-Type by listing pap after the files module in the authorize section.

When rlm_pap runs in authenticate, it looks for a member of the set of 'reference' passwords described above, and if it can't find one, it rejects the request, this is what's happening above.

There's also a 'magic' Auth-Type, 'Accept', which skips the authenticate section completely and just accepts the user. If you want the used to do cleartext password comparison without rlm_pap, you can use:

shad Auth-Type := Accept, User-Password == "test"

Comments

[mmuller]

Just wanted to point out, this answer is underrated, it does a better job at explaining the workflow as the official documentation (at least for me) ! Thanks.