Thank you for the response, even if it was ridden with unnecessary sarcasm. I wasn't trying to argue, I was trying to understand why an Access-Reject wasn't sent back. Thank you for explaining that. While I don't necessarily agree with your logic, I can see why you would think this is sufficient for normal 802.1X authentication and denial. The problem comes when you try to do something with a rejected user, for example, throw them in a different vlan. If the reject never comes, or waits for the user to log out, issues can arise. Again, thank you for your explanation; it was very insightful, even if it was condescending and rude. Regards, -Tyler
-----Original Message----- From: freeradius-users-bounces@lists.freeradius.org [mailto:freeradius- users-bounces@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Thursday, October 11, 2007 3:35 AM To: FreeRadius users mailing list Subject: Re: Simultaneous-Use and PEAP doesn't work correctly.
Marcotte, Tyler wrote:
I can understand that nowhere in any documentation does it say that an Access-Reject is sent back (I just double-checked to verify). However, what I don't understand is why not?
Because it's an EAP method, *and* it's TLS. Go read the debug output again: the inner tunnel MS-CHAP authentication has to send an MS-CHAP "authentication failed" response to the supplicant. Since this has to go in the TLS tunnel, it has to go in an Access-Challenge, because there is often multiple round trips required to get all of that data to the supplicant.
Further, the EAP specifications say that the server CANNOT short-circuit the EAP conversation, by sending an EAP-Failure in the middle of a conversation.
If you're using this with 802.1X (which I'm trying to do) the radius client most likely does not understand reply-messages. It only understands Access-Challenges, Requests, Accepts, and Rejects for types of RADIUS packets. It can also understand other Vendor Specific attributes depending on the vendor, but I've yet to encounter one that can understand a Reply-Message.
You're thinking about the problem entirely wrong. The RADIUS client *does* understand Reply-Message. It just can't do anything with it. The protocol used between the RADIUS client and the supplicant is EAPoL, which has no way to carry the Reply-Message.
If a End User isn't allowed onto the network because he's already logged in, why wouldn't you want to send an Access-Reject?
Because you're fixated on Access-Reject, and *not* on the user session getting dropped. If the user session goes away, who cares about sending an Access-Reject?
Let me guess what's happening, because you did NOT say what happens after the Access-Challenge is sent.
What happens is this: The server sends the Access-Challenge. NOTHING MORE HAPPENS. The client doesn't send another Access-Request. Therefore, the server doesn't send an Access-Reject. You then see no Access-Reject You then conclude "OH NO! THE USER WASN'T REJECTED".
Here's a simple proof of the illogic of that argument: The client doesn't send another Access-Reject. i.e. the client is NO LONGER REQUESTING ACCESS. i.e. the client has GONE AWAY. It is NO MORE. (Insert further "parrot sketch" lines here.)
What happening is that the inner tunnel MS-CHAP session tells the supplicant that the user has been rejected. At that point, there is no need for the supplicant to continue the conversation. So it doesn't.
Since EAP is driven 100% by the client, the server has no need to send an Access-Reject. Why you ask? But doesn't the server need to send an Access-Reject to kick the user off? Isn't something going terribly, horrible, wrong?
No. The server doesn't have to reject users if they're not requesting access. If the user goes away part way through an EAP conversation, then the NAS will AUTOMATICALLY reject their session.
There is NO NEED for the server to send an Access-Reject. Your insistence that it's a problem when there's no Access-Reject is based on a misunderstanding of how the system works. Stop arguing. Stop thinking that something is going wrong. Start believing me that there's no problem. The user IS getting rejected, even if there is no Access-Reject being sent.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html