Michel Bulgado <[email protected]> writes:

> Try this way, remember the operator.
>
> |312|[email protected]|Calling-Station-Id | += | "72061490"
> |298|[email protected]|MD5-Password       | := | password
> |313|[email protected]|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|[email protected]|Calling-Station-Id | += | "72061490"
 |298|[email protected]|MD5-Password       | := | password
 |313|[email protected]|Calling-Station-Id | += | "72061490"

are identical to the single line

 |298|[email protected]|MD5-Password       | := | password

and the user will be accepted regardless of Calling-Station-Id.


> suffix] Looking up realm "internet.quimefa.cu" for User-Name = 
> "[email protected]"
> [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 [email protected] 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

Reply via email to