how to add MSCHAPV2 Retry Max
Free Radius Developers, Can someone point me to how to: 1) add a configuration value (the retry count allowed). 2) add a state value associated with a session (current retry count). The motivation is: When a windows xp box is authenticating against freeradius with patches to support retry and freeradius is configured to allow retry and the user enters a wrong username the user is presented with a balloon which has: ==== Wireless Network Connection -- Click here to process your login information for the network yyyy ==== The duologue window pops up with title "Re-enter Credentials" The User name entry shows the entered username grayed out The Password has dots for each letter entered The Domain is grayed out There is an Ok and Cancel button. The user cannot correct the wrong username. If they hit either Ok a new balloon pops up with the same info. If they hit cancel in a while (seems about 30 sec) a new balloon pops up. After about 2 minutes a different balloon pops up where they can enter their credentials of User name, password and login domain. If retry is not enabled no balloon which results in a "Re-enter Credentials" dialog box occurs - after a long while (over 2 minutes) a balloon pops up where the user can enter their User name, password and login domain. There seems to be a problem when retry is not enabled of getting the windows client to detect there is a problem and giving up in a quicker time frame. That issue aside I would like to implement a retry count so that if say a retry count of 3 the user would be presented with at most 3 "Re-enter Credentials" dialog box before having the client go into a different mode where it fails and then gives the user a chance to enter user name and password. TIA johnh...
John.Hayward@wheaton.edu wrote:
Free Radius Developers,
Can someone point me to how to: 1) add a configuration value (the retry count allowed).
Add an "int" value to the module config. There are tons of examples of this in the server source.
2) add a state value associated with a session (current retry count).
Use a DB. And once you use a DB, the "max retry" value might as well be hard-coded in the queries.
That issue aside I would like to implement a retry count so that if say a retry count of 3 the user would be presented with at most 3 "Re-enter Credentials" dialog box before having the client go into a different mode where it fails and then gives the user a chance to enter user name and password.
Storing data for (potentially) 100's of 1000's of users means "use a DB". My $0.02 is to write a Perl script to implement the logic, and use rlm_perl. Alan DeKok.
Can someone point me to how to: 1) add a configuration value (the retry count allowed).
Add an "int" value to the module config. There are tons of examples of this in the server source. I added a field to rlm_mschap_t and added appropriate entry to module_config[]
That seemed to do the trick.
2) add a state value associated with a session (current retry count).
Use a DB.
And once you use a DB, the "max retry" value might as well be hard-coded in the queries.
That issue aside I would like to implement a retry count so that if say a retry count of 3 the user would be presented with at most 3 "Re-enter Credentials" dialog box before having the client go into a different mode where it fails and then gives the user a chance to enter user name and password.
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. The vast majority of connections to the radius server succeed since they are cashed in the machines of the users. Failure of passwords occur after a password change or when first connecting to the network both of which are a relatively rare occurrence. Is there another preferred way to keep track of remaining retry counts for a particular session. johnh...
My $0.02 is to write a Perl script to implement the logic, and use rlm_perl.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
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"? 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.
The vast majority of connections to the radius server succeed since they are cashed in the machines of the users. Failure of passwords occur after a password change or when first connecting to the network both of which are a relatively rare occurrence.
Sure.
Is there another preferred way to keep track of remaining retry counts for a particular session.
First, define what a "session" is. Second, realize that the server doesn't already do tracking for that session. :( Third, put session tracking into a DB. The server already integrates with DBs. Alan DeKok.
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...
John.Hayward@wheaton.edu wrote:
What's a "session"? I probably used the wrong term here. What I intended to say was something like a "Negotiation" sequence. In rfc2759
That's nice. What does that have to do with RADIUS? I'm not being obtuse here... I really mean that you need to look at how this interacts with RADIUS. Hint: it doesn't.
Keeping track of the number of retries used in the current "Negotiation" sequence is what I am attempting.
As I've said repeatedly:
The RADIUS server doesn't track sessions. ... 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.
EAP != MSCHAP You will need to write the same kind of session tracking in MSCHAP as is currently done in EAP. You *cannot* re-use the EAP session tracking. And for 99% of the situations, session tracking in MS-CHAP is pointless. You're MUCH better off using a DB. Really. That's why I suggested it. I'm not an idiot. Alan DeKok.
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. The vast majority of connections to the radius server succeed since they are cashed in the machines of the users. Failure of passwords occur after a password change or when first connecting to the network both of which are a relatively rare occurrence.
Is there another preferred way to keep track of remaining retry counts for a particular session.
The rlm_perl script would be able to do this. You need to find/hire a Perl monkey though to do this for you[1]. The following will give them a good template to start with (so they know the type of thing that needs to be done): http://stuff.digriz.org.uk/cache_ldap-userdn.pm Cheers [1] <shameless-self-promo> I own a consultancy hat... -- Alexander Clouter .sigmonster says: OK, enough hype. -- Larry Wall in the perl man page
participants (3)
-
Alan DeKok -
Alexander Clouter -
John.Hayward＠wheaton.edu