Why doesn't := "Always match?"
A man page (http://www.die.net/doc/linux/man/man5/users.5.html) for the users file says, "Attribute := Value ... Always matches as a check item..." So does that mean, no matter what the value is, it will always match the attribute? I don't see that happening. As an experiment, I have a supplicant in a WiFi phone with user name of "plong" and password of "123". With the following entry in the users file: plong Auth-Type = Local, User-Password := "126" ...I assumed it would match even though the value is different; however, it does not match, and the access request is rejected: rlm_chap: login attempt by "plong" with CHAP password rlm_chap: Using clear text password 126 for user plong authentication. rlm_chap: Pasword check failed To get it to match, I have to have the correct value: plong Auth-Type = Local, User-Password := "123" which results in this debug output: rlm_chap: login attempt by "plong" with CHAP password rlm_chap: Using clear text password 123 for user plong authentication. rlm_chap: chap user plong authenticated succesfully In fact, := behaves exactly like == in this case. What's the deal? Why doesn't := "always match?" Am I misunderstanding what it means to "match?" Paul
Paul Long wrote:
A man page (http://www.die.net/doc/linux/man/man5/users.5.html) for the users file says, "Attribute := Value ... Always matches as a check item..." So does that mean, no matter what the value is, it will always
Well, the wording might be a bit confusing. FreeRadius works the following way: 1. All attribute-value pairs that come in are the "request" pairs 2. Internal server attribute per-request are the "config" pairs 3. Attribute-value pairs to go back to the client are the "reply" pairs someuser User-Password := "somevalue" ...actually sets (unconditionally) the User-Password AVP in the "config" items. This password is *COMPARED* to the password supplied by the client in the "request" items. It's not a simple equality - a CHAP request will require a challenge/response calculation with the config password + request challenge and then an equality test of the chap response.
match the attribute? I don't see that happening. As an experiment, I have a supplicant in a WiFi phone with user name of "plong" and password of "123". With the following entry in the users file:
plong Auth-Type = Local, User-Password := "126"
...I assumed it would match even though the value is different; however,
Though I realise the terminology might be initially confusing, how did you imagine a user with a password of "123" would be matched/accepted by a password of "126".
it does not match, and the access request is rejected:
rlm_chap: login attempt by "plong" with CHAP password rlm_chap: Using clear text password 126 for user plong authentication. rlm_chap: Pasword check failed
To get it to match, I have to have the correct value:
plong Auth-Type = Local, User-Password := "123"
which results in this debug output:
rlm_chap: login attempt by "plong" with CHAP password rlm_chap: Using clear text password 123 for user plong authentication. rlm_chap: chap user plong authenticated succesfully
Yes...
In fact, := behaves exactly like == in this case. What's the deal? Why doesn't := "always match?" Am I misunderstanding what it means to "match?"
As per man(5) users: Attribute := Value Always matches as a check item, and replaces in the configuration items any attribute of the same name. If no attribute of that name appears in the request, then this attribute is added. As a reply item, it has an identical meaning, but for the reply items, instead of the request items. Basically, := is a "force set" operator. In a "check" item, it sets a check/config pair. In a reply item, it sets/forces a reply pair. See doc/aaa.txt
Comments inline... Phil Mayers wrote:
Paul Long wrote:
A man page (http://www.die.net/doc/linux/man/man5/users.5.html) for the users file says, "Attribute := Value ... Always matches as a check item..." So does that mean, no matter what the value is, it will always
Well, the wording might be a bit confusing.
FreeRadius works the following way:
1. All attribute-value pairs that come in are the "request" pairs 2. Internal server attribute per-request are the "config" pairs 3. Attribute-value pairs to go back to the client are the "reply" pairs
someuser User-Password := "somevalue"
...actually sets (unconditionally) the User-Password AVP in the "config" items. This password is *COMPARED* to the password supplied by the client in the "request" items. Okay, so then what is meant in the man page by "Always matches a check item?" Should it have said, "Always checks a check item?" :-) As is, it sounds like it always returns true. It's not a simple equality - a CHAP request will require a challenge/response calculation with the config password + request challenge and then an equality test of the chap response.
match the attribute? I don't see that happening. As an experiment, I have a supplicant in a WiFi phone with user name of "plong" and password of "123". With the following entry in the users file:
plong Auth-Type = Local, User-Password := "126"
...I assumed it would match even though the value is different; however,
Though I realise the terminology might be initially confusing, how did you imagine a user with a password of "123" would be matched/accepted by a password of "126". I didn't expect it to match.accept. I was just playing around with values trying to better understand the operators. I have everything working the way I want--I was just going for extra credit. :-)
it does not match, and the access request is rejected:
rlm_chap: login attempt by "plong" with CHAP password rlm_chap: Using clear text password 126 for user plong authentication. rlm_chap: Pasword check failed
To get it to match, I have to have the correct value:
plong Auth-Type = Local, User-Password := "123"
which results in this debug output:
rlm_chap: login attempt by "plong" with CHAP password rlm_chap: Using clear text password 123 for user plong authentication. rlm_chap: chap user plong authenticated succesfully
Yes...
In fact, := behaves exactly like == in this case. What's the deal? Why doesn't := "always match?" Am I misunderstanding what it means to "match?"
As per man(5) users:
Attribute := Value Always matches as a check item, and replaces in the configuration items any attribute of the same name. If no attribute of that name appears in the request, then this attribute is added. As a reply item, it has an identical meaning, but for the reply items, instead of the request items.
Basically, := is a "force set" operator. In a "check" item, it sets a check/config pair. So "Always matches a check item" just means that a check will be performed and says nothing about the outcome of that check? In a reply item, it sets/forces a reply pair.
See doc/aaa.txt - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jul 21, 2006, at 6:31 PM, Paul Long wrote:
Phil Mayers wrote:
Paul Long wrote:
A man page (http://www.die.net/doc/linux/man/man5/users.5.html) for the users file says, "Attribute := Value ... Always matches as a check item..." So does that mean, no matter what the value is, it will always
Well, the wording might be a bit confusing.
FreeRadius works the following way:
1. All attribute-value pairs that come in are the "request" pairs 2. Internal server attribute per-request are the "config" pairs 3. Attribute-value pairs to go back to the client are the "reply" pairs
someuser User-Password := "somevalue"
...actually sets (unconditionally) the User-Password AVP in the "config" items. This password is *COMPARED* to the password supplied by the client in the "request" items. Okay, so then what is meant in the man page by "Always matches a check item?" Should it have said, "Always checks a check item?" :-) As is, it sounds like it always returns true.
The way I think of it is that the "match" criterion only applies to which clause of the users file gets selected. Subsequent processing of the request may still cause the request to be rejected.
match the attribute? I don't see that happening. As an experiment, I have a supplicant in a WiFi phone with user name of "plong" and password of "123". With the following entry in the users file:
plong Auth-Type = Local, User-Password := "126"
...I assumed it would match even though the value is different; however,
I'll try to give an example. Suppose you had two entries, using '==' for the same user: plong Auth-Type = Local, User-Password == "126" plong Auth-Type = Local, User-Password == "123" Then, if 'plong' supplies the password "123", the 'files' module (which processes the 'users' file) will select the second entry, then the authentication module will compare the passwords in the request and config items, and the user will be accepted. But if you use ':=' plong Auth-Type = Local, User-Password := "126" plong Auth-Type = Local, User-Password := "123" the 'files' module will select the first entry ("always match"), then the authentication module will compare the supplied password "123" with the configured password "126" and the user will be rejected. I hope I got that right; Phil can correct me if not. -- George C. Kaplan gckaplan@ack.berkeley.edu Communication & Network Services 510-643-0496 University of California at Berkeley
Hi All Here is the solution for freeradius 1.0.5 on Mac OS X with mysql 5.0. The general location of includes and libraries are in the following folder System Include: /usr/include System Library: /usr/lib But the mysql includes and libraries are placed in the following folder MySQL Include: /usr/local/mysql/include MySQL Library: /usr/local/mysql/lib Even if you try to pass the location with --with-mysql-include-dir or --with-mysql-lib-dir the configure script fails to get the required files A workaround is as follows 1) Create a link from the System Include and Library folder with the name as "mysql/include" and "mysql/lib" to MySQL Include and Library. Hence the files in System Include and Library would look as follows: System Library$ls -la ......... ......... mysql/lib-->/usr/local/mysql/lib ......... ......... System Include$ls -la ......... ......... mysql/include-->/usr/local/mysql/include ......... ......... 2) Copy all the includes and libraries from MySQL Include and Library folder to System Include and Library folders. 3) Follow the instructions to compile. During make you will get a error stating to re-run "ranlib" on "libmysqlclient.a" 4) Delete the file from the path as referred in the error. This error is because the system will have 2 copies of the same file one at MySQL Library and second at System Library. 5) Re-run "make" followed my make install HTH. Regards & Thanks ================ Mahesh S Kudva ----------------------------------------------- Robosoft Technologies - Come home to Technology
I'll try to give an example. Suppose you had two entries, using '==' for the same user:
plong Auth-Type = Local, User-Password == "126"
plong Auth-Type = Local, User-Password == "123"
Then, if 'plong' supplies the password "123", the 'files' module (which processes the 'users' file) will select the second entry, then the authentication module will compare the passwords in the request and config items, and the user will be accepted.
Hmm. So it does. I didn't think the server behaved that way. It does not seem terribly consistent.
Phil Mayers wrote:
I'll try to give an example. Suppose you had two entries, using '==' for the same user:
plong Auth-Type = Local, User-Password == "126"
plong Auth-Type = Local, User-Password == "123"
Then, if 'plong' supplies the password "123", the 'files' module (which processes the 'users' file) will select the second entry, then the authentication module will compare the passwords in the request and config items, and the user will be accepted.
Hmm. So it does. I didn't think the server behaved that way. It does not seem terribly consistent.
OK, now *I'm* confused. What's inconsistent about the above behavior? -- George C. Kaplan gckaplan@ack.berkeley.edu Communication & Network Services 510-643-0496 University of California at Berkeley
George C. Kaplan wrote:
Phil Mayers wrote:
I'll try to give an example. Suppose you had two entries, using '==' for the same user:
plong Auth-Type = Local, User-Password == "126"
plong Auth-Type = Local, User-Password == "123"
Then, if 'plong' supplies the password "123", the 'files' module (which processes the 'users' file) will select the second entry, then the authentication module will compare the passwords in the request and config items, and the user will be accepted.
Hmm. So it does. I didn't think the server behaved that way. It does not seem terribly consistent.
OK, now *I'm* confused. What's inconsistent about the above behavior?
I was referring to the use of the == versus := operator against User-Password being inconsistent: == compares THERE AND THEN the "request" User-Password to the right-hand-side of the operator. It will only ever work for PAP requests, not CHAP, MS-CHAP, digest, etc. := sets the config/check User-Password to the right hand side of the operator. The authorize section completes, then authenticate is run, and the server uses the password in the config items to check the password in the request items - this will work for all authentication types.
Paul Long wrote:
Basically, := is a "force set" operator. In a "check" item, it sets a check/config pair.
So "Always matches a check item" just means that a check will be performed and says nothing about the outcome of that check?
check items == config items. config items == attribute/value pairs that did not come in the request, are not going in the reply, but are attached to the request/reply and represent "configuration" for that request. For example, if you have a database with username/password in it, you might extract the password from the database into a config item "User-Password". This is totally *different* than e.g. a User-Password that might be in a PAP request. So, := means "set this attribute to this value in the config items, replacing any others of this name" The config items are then processed variously against the request items to validate or reject the request. Hence "check items" being another name - they're used to "check" the request.
In a reply item, it sets/forces a reply pair.
See doc/aaa.txt - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (4)
-
George C. Kaplan -
Mahesh S Kudva -
Paul Long -
Phil Mayers