Hi
As you perhaps remember, I was (probably the only) person with problems
getting the subject configuration working. Well, I'm sorry, it took some
time because I was busy with other things.
Now, I figured out the problem: the problem was the Reply-Message
attribute which I used in my user configuration, i.e. for the user file
containing:
"test user" Auth-Type := System, User-Password == "hello"
Reply-Message = "Hello, %u"
artur Auth-Type := Local, User-Password == "hello"
the user "artur" can login, but not the user "test user".
As you know, the successful login goes like that:
IEEE 802.1X Successful Login:
NAS Server
Access Request (1)
EAP Response (2)
Identity (1)
---------------->
Access Challenge (11)
EAP Request (1)
MD5-Challenge (4)
<----------------
Access Request (1)
EAP Response (2)
MD-Challenge (4)
---------------->
Access Accept (2)
EAP Success (3)
<----------------
In the case where I used the Reply-Message i have this:
NAS Server
Access Request (1)
EAP Response (2)
Identity (1)
---------------->
Access Challenge (11)
EAP Request (1)
MD5-Challenge (4)
<----------------
Access Request (1)
EAP Response (2)
Notification (2)
---------------->
Access Reject (3)
<----------------
Access Request (1)
EAP Response (2)
MD5-Challenge (4)
---------------->
The last message is repeated N times and is always silently discarded by
FreeRadius because it actually doesn't contain the State and the
User-Name attributes. In contrary, the Notification message contains the
both.
My question is, why FreeRadius issues the Reject Message after the
notification? I know, that offcially this message should be used the
other way around (RFC 2284 �3.2)
The Notification Type is optionally used to convey a displayable
message from the authenticator to the peer. The peer SHOULD
display this message to the user or log it if it cannot be
displayed. It is intended to provide an acknowledged notification
of some imperative nature. Examples include a password with an
expiration time that is about to expire, an OTP sequence integer
which is nearing 0, an authentication failure warning, etc. In
most circumstances, notification should not be required.
Nevertheless, which RFC dictates the issuing of the REJECT message in
this case? Couldn't the notification message be just silently discarded?
In fact, I'm still not sure who really issues this message. For me, it
could be the Cisco AP340 (NAS), resending the received Reply-Message
attribute as EAP Notification on all of its links (weird) or Windows XP
(peer) which really receives and shows the Reply-Message and perhaps
feels like it should respond to it? I don't know, because (it's
ridiculous) I can't use WIN-Ethereal to sniff on my wireless interface
(it doesn't catch *any* packets) and Linux doesn't have an EAP/MD5
supplicant as it has been figured out on the list recently. Do you have
any ideas how I can figure out where the message originates from?
Meanwhile - could some of you guys test this behaviour with other APs
(not Cisco 340) or other peers (not Windows XP)? So, we would know who
is responsible for the mess...
One last remark on the user configuration: the Auth-Type has to be
"Local" or "System" using the ":=" operator. The "=" will not work (at
least in my case).
Thanks,
artur
PS Raghu: what's wrong with your mail address - I have a mail delivery
error on your hereuare[dot]com address... (ah)
--
Artur Hecker Groupe Acc�s et Mobilit�
hecker[at]enst[dot]fr D�partement Informatique et R�seaux
+33 1 45 81 7507 46, rue Barrault 75634 Paris cedex 13
http://www.infres.enst.fr ENST Paris
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
