RE: EAP post auth reject and access-challenge
Hi, I have a setup that just does admin logins for NAS equipment, some of it presents via PAP and some of it peap/mschapv2. When the user is rejected I do a linelog or sql insert, capturing a failure reason from each module. Basically an EAP reject of a user creates two entries to the logging. I do failure logging within the inner-tunnel VS as well as the default because I wanted it to capture a failure reason to the line log based on the module-failure-reason string, which is lost after the eap session rejects and can't be seen in the default. As you commented in an email from last week, updating the outer.control variable to try and pass module-failure-reason doesn't work due to the access-challenge presenting a new session. I'm also doing some stuff in the authorization section which can reject a user based on some ldap information. I thought I could perhaps just update the default tunnel post-auth reject section to not do a linelog if auth-type has been set to EAP but it doesn't work when clients are rejected in this ldap section; the EAP auth-type is set but it never authenticates as the reject is triggered first, and so a linelog would never be recorded in the inner tunnel post auth reject section. I hope that's not too confusing, it's hard to explain. Thanks Andy -----Original Message----- From: freeradius-users-bounces+andy.franks=sath.nhs.uk@lists.freeradius.org [mailto:freeradius-users-bounces+andy.franks=sath.nhs.uk@lists.freeradiu s.org] On Behalf Of Phil Mayers Sent: 10 June 2013 16:02 To: freeradius-users@lists.freeradius.org Subject: Re: EAP post auth reject and access-challenge On 10/06/13 15:45, Franks Andy (RLZ) IT Systems Engineer wrote:
Hi,
Just wondered if someone could explain the reason why, on rejection
of EAP authentication, an access challenge request is sent out to the NAS, and whether it's something we can control or not?
I assume you're referring to the fact that the inner tunnel reject is sent as an outer access-challenge? The packet flow is this: C: Access-Request EAP / TLS-setup S: Access-Challenge EAP / TLS-setup ... C: Access-Request EAP / TLS / inner access-request S: Access-Challenge EAP / TLS / inner access-reject C: Access-Request EAP / TLS [ack] S: Access-Reject EAP / reject Basically, the protocols send the inner reject as a TLS frame, so that the client can't be tricked by a fake reject. The client then ACKs it, and the server then sends the RADIUS-level reject. So no, you can't turn it off - it's part of the protocol specifications. Why is this a problem for you? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 10/06/13 17:29, Franks Andy (RLZ) IT Systems Engineer wrote:
I'm also doing some stuff in the authorization section which can reject a user based on some ldap information. I thought I could perhaps just update the default tunnel post-auth reject section to not do a linelog if auth-type has been set to EAP but it doesn't work when clients are rejected in this ldap section; the EAP auth-type is set but it never authenticates as the reject is triggered first, and so a linelog would never be recorded in the inner tunnel post auth reject section. I hope that's not too confusing, it's hard to explain.
Sorry, I didn't understand that last part. There are a bunch of different ways of solving the "logging twice" if that's the problem you're trying to solve. The easiest is to just not care - we have a similar logging system and log both the inner and outer rejects. Our log "inspection" script shows both, and we just look at the relevant one. Note that EAP sessions can fail in ways that never trigger the inner tunnel, but do set Module-Failure-Message, so you can't just "not log outer" and hope to catch all relevant debugging. You can also have inner accepts with outer rejects (e.g. if the client fails mutual auth) so again, logging just one will miss info. Without knowing what you're trying to accomplish and what your criteria are, I couldn't comment further - logging is a very individual thing that people have different ideas about. But my advice would be to solve this by post-processing the data, not by having extensive logic in your FR config.
participants (2)
-
Franks Andy (RLZ) IT Systems Engineer -
Phil Mayers