The entries should be ordered

[M T]

Thank you, Mr. DeKok.  I very much appreciate your taking the time to
respond.    I've seen the processing sequence mentioned frequently in my
reading, and thought perhaps the "should be ordered" was somewhat more
significant than merely alphabetical.



After my initial eMail to this list, I happened to come across something in
the mail archives and felt
http://lists.freeradius.org/mailman/htdig/freeradius-users/2004-January/027248.html
(subject heading:   radcheck entries)  was helpful in clarifying the meaning
(at least to my understanding) of "should be ordered"  ….  with emphasis on
Byron's response (included below)



(from above link)

The gist of the mail-list inquiry from Klaus Heck is:

"Now I want allow more than one computer per user name, meaning I want to
add
another entry with the same name "Charlie Brown", but with a different MAC
address value. In the standard implementation of freeradius, this does not
work. It seems as if it just checks the first value it read, or it checks
more than one, but all need to match simultaneously. The first time the
condition does not hold, the reject is sent.  Is there a way to change the
behavior of freeradius in order to have more than one entry for the same
UserName? It should send an access-accept whenever at least one entry is
true."



Byron's response is:

> Make sure you have a fall through on the first one listed if you don't it
will read the first entry and with no fall through it gets rejected.


MT

On 12/29/05, Alan DeKok <aland at ox.org> wrote:
>
> M T <subscribed.email at gmail.com> wrote:
> > Does "the entries should be ordered" mean in alphabetical
> order?  (username
> > first)
>
> It means they're processed from the top of the users file to the
> bottom, in that order.
>
> Alan DeKok.
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20051229/c4b555a9/attachment.html>