Bjørn Mork wrote:
Michel Bulgado <michel@casa.co.cu> writes:
Try this way, remember the operator.
|312|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490" |298|test@internet.quimefa.cu|MD5-Password | := | password |313|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490"
Please read the manual. In this case, that's users(5):
Attribute += Value Always matches as a check item, and adds the current attribute with value to the list of configuration items. As a reply item, it has an identical meaning, but the attribute is added to the reply items.
This means that the 3 lines
|312|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490" |298|test@internet.quimefa.cu|MD5-Password | := | password |313|test@internet.quimefa.cu|Calling-Station-Id | += | "72061490"
are identical to the single line
|298|test@internet.quimefa.cu|MD5-Password | := | password
and the user will be accepted regardless of Calling-Station-Id.
suffix] Looking up realm "internet.quimefa.cu" for User-Name = "test@internet.quimefa.cu" [suffix] No such realm "internet.quimefa.cu"
This is normal, and no problem. You may define a realm using LOCAL authentication to avoid it, but it won't change anything except remove the debug message.
sql] User test@internet.quimefa.cu not found ++[sql] returns notfound
The sql module returns notfound if the check items don't match. This is expected in this case as I explained: Two different equality tests on a single attribute will never match.
But in the end because it connects the user's which is declared in the file "users". apparently you have stated that locate the user in the database and also in this file, you must define where you will store your users and then put the phone number.
The debug output showed that the user matched a DEFAULT entry in users. That's a perfectly normal configuration.
In fact, there is no problem defining the same user in both "users" and sql (and possibly other modules as well). The control and reply lists of the matching entries just add up, and the final result is then evaluated.
But I agree that for simplicity it's probably best to define the specific user entries in one place. And that's what Osmany has done. The DEFAULT entry is probably just adding something generic, which is common for all users.
Bjørn
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thanks for the class, as we say in our country: "Every day you learn something new." There are no problems is to define a user, in fact he did on both sides, in the file "users" and database "sql". I would do it in one place, so you do not go crazy when you add a user or update any information of it, for example the phone number where you will be connected. Although the problem persists, the user can connect from any other phone number and may not be a problem of operator, but this by specifying the number in a single place, and not in the sql file "users". Assuming this well held on both sides and again I'm wrong, maybe in the section "authorize" I miss you to use the module "checkval. Even so if you could post your configuration, would be useful. Don't you think?