On Wed, 11 May 2011, Alan DeKok wrote:
Date: Wed, 11 May 2011 09:10:18 From: Alan DeKok <aland@deployingradius.com> Reply-To: FreeRadius developers mailing list <freeradius-devel@lists.freeradius.org> To: FreeRadius developers mailing list <freeradius-devel@lists.freeradius.org> Subject: Re: how to add MSCHAPV2 Retry Max
John.Hayward@wheaton.edu wrote:
Storing data for (potentially) 100's of 1000's of users means "use a DB".
I was hoping to only store the value of retry remaining when there was a failure of authentication for the session.
What's a "session"? I probably used the wrong term here. What I intended to say was something like a "Negotiation" sequence. In rfc2759 ==== 9.1.5. Failed hack attack with 3 attempts allowed
<- Authenticator Challenge Peer Response/Challenge -> <- Failure (E=691 R=1), disable short timeout Response (++ID) to challenge in Failure message -> <- Failure (E=691 R=1), disable short timeout Response (++ID) to challenge in Failure message -> <- Failure (E=691 R=0) ==== Keeping track of the number of retries used in the current "Negotiation" sequence is what I am attempting.
The RADIUS server doesn't track sessions. They're stored in a DB. (Accounting start / interim / stop). The server tracks EAP authentications, but that's different, and the EAP module already implements a retry counter.
MSCHAP authentication doesn't involve the idea of "sessions". Look at rlm_mschap: there is no session tracking.
I'll look at EAP module and see if the retry counter could be used to keep track of the retries of a particular "Negotiation" sequence of the MSCHAP authentication. johnh...