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.