I've been asked to implement freeradius on a proprietary system that uses the concept of a password 'grace period', a brief time period during which both the old and new passwords should be allowed. Is this possible with freeradius? The system uses pptp client access (MS-CHAP) with user/passwords in a (proprietary) postgres DB. We are working with freeradius version 1.1.3. Thanks in advance, John This message is confidential to Prodea Systems, Inc unless otherwise indicated or apparent from its nature. This message is directed to the intended recipient only, who may be readily determined by the sender of this message and its contents. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient:(a)any dissemination or copying of this message is strictly prohibited; and(b)immediately notify the sender by return message and destroy any copies of this message in any form(electronic, paper or otherwise) that you have.The delivery of this message and its information is neither intended to be nor constitutes a disclosure or waiver of any trade secrets, intellectual property, attorney work product, or attorney-client communications. The authority of the individual sending this message to legally bind Prodea Systems is neither apparent nor implied,and must be independently verified.
John Kane wrote:
I've been asked to implement freeradius on a proprietary system that uses the concept of a password 'grace period', a brief time period during which both the old and new passwords should be allowed. Is this possible with freeradius?
The system uses pptp client access (MS-CHAP) with user/passwords in a (proprietary) postgres DB. We are working with freeradius version 1.1.3.
Not with any of the 1.* versions. You'd need to upgrade to 2.*. Arran
John Kane wrote:
I've been asked to implement freeradius on a proprietary system that uses the concept of a password 'grace period', a brief time period during which both the old and new passwords should be allowed. Is this possible with freeradius?
[snip]
Not with any of the 1.* versions. You'd need to upgrade to 2.*.
Arran
[JK] Thanks, Arran. Another quick question. Will 2.* do this 'straight out of the box'? If not, will it require much work? We are evaluating whether attempt this in radius, or make changes in our system. Thanks again, John This message is confidential to Prodea Systems, Inc unless otherwise indicated or apparent from its nature. This message is directed to the intended recipient only, who may be readily determined by the sender of this message and its contents. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient:(a)any dissemination or copying of this message is strictly prohibited; and(b)immediately notify the sender by return message and destroy any copies of this message in any form(electronic, paper or otherwise) that you have.The delivery of this message and its information is neither intended to be nor constitutes a disclosure or waiver of any trade secrets, intellectual property, attorney work product, or attorney-client communications. The authority of the individual sending this message to legally bind Prodea Systems is neither apparent nor implied,and must be independently verified.
Hi,
[JK] Thanks, Arran. Another quick question. Will 2.* do this 'straight out of the box'? If not, will it require much work? We are evaluating whether attempt this in radius, or make changes in our system.
your situation is a slightly unique bespoke requirement - as such, it wont work 'straight out of the box' - you'll need to add a few lines of 'unlang' to the config. check out the FreeRADIUS wiki - in particular http://wiki.freeradius.org/Fail-over you'll basically need to make an SQL query for the one type...and if it fails, make another query for the other type. alan
Hi,
[JK] Thanks, Arran. Another quick question. Will 2.* do this 'straight out of the box'? If not, will it require much work? We are evaluating whether attempt this in radius, or make changes in our system.
your situation is a slightly unique bespoke requirement - as such, it wont work 'straight out of the box' - you'll need to add a few lines of 'unlang' to the config.
check out the FreeRADIUS wiki - in particular
http://wiki.freeradius.org/Fail-over
you'll basically need to make an SQL query for the one type...and if it fails, make another query for the other type.
alan -
[JK] Upgraded to 2.1.6 and got basic auth working. Then, after consulting the Fail-over page Alan suggested, I added a second sql section to sql.conf (I have sql_new and sql_old), each with their own sql/postgresql/dialup.conf. The only difference in these two dialup.conf is one gets the current password, the other gets the old password (via sql_old). I added, in the authorize section of sites-available/default, the following: group { sql_new { fail = 1 notfound = 2 noop = 3 ok = 4 updated = 5 reject = 6 userlock = 7 invalid = 8 handled = return } sql_old { fail = 1 notfound = 2 noop = 3 ok = 4 updated = 5 reject = 6 userlock = 7 invalid = 8 handled = return } } Note that I have been playing with various values for the different response scenarios (those listed above were current values at this writing), cannot seem to find anything that works like I need it to. Just to re-iterate; I need freeradius to attempt to authorize using the password returned in the sql_new query (and there WILL be a password returned for any valid user), and if this password does not match what the user sent, then do the query (sql_old) to get the old password (may or maynot be available). IF this password matches, then we accept. Is this possible? Should I be able to continue when the query to sql_new was successful, but due to invalid password, freeradius finds 'MS-CHAP2-Response is incorrect'? Thanks, John This message is confidential to Prodea Systems, Inc unless otherwise indicated or apparent from its nature. This message is directed to the intended recipient only, who may be readily determined by the sender of this message and its contents. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient:(a)any dissemination or copying of this message is strictly prohibited; and(b)immediately notify the sender by return message and destroy any copies of this message in any form(electronic, paper or otherwise) that you have.The delivery of this message and its information is neither intended to be nor constitutes a disclosure or waiver of any trade secrets, intellectual property, attorney work product, or attorney-client communications. The authority of the individual sending this message to legally bind Prodea Systems is neither apparent nor implied,and must be independently verified.
hmm, all you are doing is setting the values to what they normally are...you need something like
group { sql_new { reject = 1 ok = return } sql_old { reject = 1 ok = return } }
alan -
[JK] Tried that earlier Alan. Seems whenever is set ok = return, we process no further. Here's the logs from a 'radtest', where testRadOld is entered as the password (testRad is the new password, testRadOld is the old password in the DB). We see the first query, where there is a password mismatch, but the second query never happens (it does in other configuration settings, but I never see it compare BOTH passwords to what was received): ++- entering group {...} [sql_new] expand: %{User-Name} -> radTest [sql_new] sql_set_user escaped user --> 'radTest' rlm_sql (sql_new): Reserving sql socket id: 3 [sql_new] expand: select repeat('1',1) as Id,tunnelid as UserName,repeat('Cleartext-Password',1) as Attribute, newkey as Value,repeat(':=',1) as op from am_tunnelkey where tunnelid ='%{SQL-User-Name}' ORDER BY id -> select repeat('1',1) as Id,tunnelid as UserName,repeat('Cleartext-Password',1) as Attribute, newkey as Value,repeat(':=',1) as op from am_tunnelkey where tunnelid ='radTest' ORDER BY id rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 1 , fields = 5 [sql_new] User found in radcheck table rlm_sql (sql_new): Released sql socket id: 3 +++[sql_new] returns ok ++- group returns ok ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns updated Found Auth-Type = PAP +- entering group PAP {...} [pap] login attempt with password "testRadOld" [pap] Using clear text password "testRad" [pap] Passwords don't match ++[pap] returns reject Failed to authenticate the user. Login incorrect (rlm_pap: CLEAR TEXT password check failed): [radTest] (from client localhost port 1812) Using Post-Auth-Type Reject +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> radTest attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 1 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 1 Sending Access-Reject of id 26 to 127.0.0.1 port 32800 Thanks, John This message is confidential to Prodea Systems, Inc unless otherwise indicated or apparent from its nature. This message is directed to the intended recipient only, who may be readily determined by the sender of this message and its contents. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient:(a)any dissemination or copying of this message is strictly prohibited; and(b)immediately notify the sender by return message and destroy any copies of this message in any form(electronic, paper or otherwise) that you have.The delivery of this message and its information is neither intended to be nor constitutes a disclosure or waiver of any trade secrets, intellectual property, attorney work product, or attorney-client communications. The authority of the individual sending this message to legally bind Prodea Systems is neither apparent nor implied,and must be independently verified.
Hi,
[JK] Tried that earlier Alan. Seems whenever is set ok = return, we process no further. Here's the logs from a 'radtest', where testRadOld is entered as the password (testRad is the new password, testRadOld is the old password in the DB). We see the first query, where there is a password mismatch, but the second query never happens (it does in other configuration settings, but I never see it compare BOTH passwords to what was received):
ooh. me sir, me sir! (said whilst jumping around holding hand in the air. the SQL module is not doing the checking - its simply collecting the Cleartext-Password for that User-Name (and thus, if user exists its returning 'ok' - therefore the group returns ok
[sql_new] User found in radcheck table rlm_sql (sql_new): Released sql socket id: 3 +++[sql_new] returns ok ++- group returns ok
now, the PAP module kicks in - and that compares the value sent versus the value got from SQL....and so heres where it breaks.
[pap] login attempt with password "testRadOld" [pap] Using clear text password "testRad" [pap] Passwords don't match ++[pap] returns reject
ta da! so, what you've actually got to do is run the pap method twice. once for the user-name/password from sql_new and once for the user-name/password from sql_old. one of those methods would work for a valid user.... thats a funky bit of group/failover requirement that'll have to be cooked up...maybe group { sql_new { pap ok = return } sql_old { pap ok = return } } or something along those broken lines ;-) alan
I was hoping that would not be your response :)
-----Original Message----- From: freeradius-users- bounces+john.kane=prodeasystems.com@lists.freeradius.org [mailto:freeradius-users- bounces+john.kane=prodeasystems.com@lists.freeradius.org] On Behalf Of A.L.M.Buxey@lboro.ac.uk Sent: Wednesday, June 24, 2009 2:56 PM To: FreeRadius users mailing list Subject: Re: Old password 'grace period'
Hi,
[JK] Tried that earlier Alan. Seems whenever is set ok = return, we process no further. Here's the logs from a 'radtest', where testRadOld is entered as the password (testRad is the new password, testRadOld is the old password in the DB). We see the first query, where there is a password mismatch, but the second query never happens (it does in other configuration settings, but I never see it compare BOTH passwords to what was received):
ooh. me sir, me sir! (said whilst jumping around holding hand in the air.
the SQL module is not doing the checking - its simply collecting the Cleartext-Password for that User-Name (and thus, if user exists its returning 'ok' - therefore the group returns ok
[sql_new] User found in radcheck table rlm_sql (sql_new): Released sql socket id: 3 +++[sql_new] returns ok ++- group returns ok
now, the PAP module kicks in - and that compares the value sent versus the value got from SQL....and so heres where it breaks.
[pap] login attempt with password "testRadOld" [pap] Using clear text password "testRad" [pap] Passwords don't match ++[pap] returns reject
ta da!
so, what you've actually got to do is run the pap method twice. once for the user-name/password from sql_new and once for the user-name/password from sql_old. one of those methods would work for a valid user....
thats a funky bit of group/failover requirement that'll have to be cooked up...maybe
group { sql_new { pap ok = return } sql_old { pap ok = return } }
or something along those broken lines ;-)
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
This message is confidential to Prodea Systems, Inc unless otherwise indicated or apparent from its nature. This message is directed to the intended recipient only, who may be readily determined by the sender of this message and its contents. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient:(a)any dissemination or copying of this message is strictly prohibited; and(b)immediately notify the sender by return message and destroy any copies of this message in any form(electronic, paper or otherwise) that you have.The delivery of this message and its information is neither intended to be nor constitutes a disclosure or waiver of any trade secrets, intellectual property, attorney work product, or attorney-client communications. The authority of the individual sending this message to legally bind Prodea Systems is neither apparent nor implied,and must be independently verified.
so, what you've actually got to do is run the pap method twice. once for the user-name/password from sql_new and once for the user-name/password from sql_old. one of those methods would work for a valid user....
thats a funky bit of group/failover requirement that'll have to be cooked up...maybe
group { sql_new { pap ok = return } sql_old { pap ok = return } }
or something along those broken lines ;-)
alan
[JK] freeradius does not like anything like that added into that section. On start-up, I get: /etc/raddb/sites-enabled/default[168]: Failed to parse "sql_new" subsection. /etc/raddb/sites-enabled/default[62]: Errors parsing authorize section. Errors initializing modules John This message is confidential to Prodea Systems, Inc unless otherwise indicated or apparent from its nature. This message is directed to the intended recipient only, who may be readily determined by the sender of this message and its contents. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient:(a)any dissemination or copying of this message is strictly prohibited; and(b)immediately notify the sender by return message and destroy any copies of this message in any form(electronic, paper or otherwise) that you have.The delivery of this message and its information is neither intended to be nor constitutes a disclosure or waiver of any trade secrets, intellectual property, attorney work product, or attorney-client communications. The authority of the individual sending this message to legally bind Prodea Systems is neither apparent nor implied,and must be independently verified.
so, what you've actually got to do is run the pap method twice. once for the user-name/password from sql_new and once for the user-name/password from sql_old. one of those methods would work for a valid user....
thats a funky bit of group/failover requirement that'll have to be cooked up...maybe
group { sql_new { pap ok = return } sql_old { pap ok = return } }
or something along those broken lines ;-)
alan
[JK] freeradius does not like anything like that added into that section. On start-up, I get:
/etc/raddb/sites-enabled/default[168]: Failed to parse "sql_new" subsection. /etc/raddb/sites-enabled/default[62]: Errors parsing authorize section. Errors initializing modules
You should write your custom authentication script. This can be made to work with standard modules/attributes for pap requests with some unlang gymnastics in Post-Auth-Type Reject. But mschap will need custom script. You can utilize existing mschap module but you will need to remove from the list NT and LM passwords created with first password, before you try to call it again with replacement password. Ivan Kalik Kalik Informatika ISP
On 25/6/09 10:33, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
You should write your custom authentication script.
theres probably a way of doing it all in config with unlang etc - but yes, a PERL script which does all of the SQL stuff and authentication itself is probably the way to go for it
I leave you guys alone for 5 minutes.... Use the sql modules to create the pool of database connections required. And list the sql instances in instantiate (the parser isn't clever enough to figure out that the module instances will be required for string expansion calls). radiusd.conf instantiate { sql_old sql_new } authenticate { mschap { update control { Cleartext-Password := "%{sql_new:SELECT <cleartext password query...>}" } mschap { reject = 2 } if(reject){ update control { Cleartext-Password := "%{sql_old:SELECT <cleartext password query...>}" } mschap } } } Don't use the automatic failover stuff, it's not appropriate here... If this doesn't work, post the debug output. There are some issues with rcode priority assignments and unlang, but they're possible to work around. Arran -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2
On 25/6/09 12:01, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
I leave you guys alone for 5 minutes....
8-) as i said, theres probably a way of doing it
:P Granted, was trickier than it first appeared. After a brief discussion with Ivan, looks like this should work (he pointed out the security hole with not checking for a null old password)... instantiate { sql_old } authorize { # Retrieves credentials sql_new # Sets auth-type mschap mschap } authenticate { Auth-Type MS-CHAP { mschap { reject = 2 } if(reject){ # Could alternatively write the value of a custom attribute into Cleartext-password # if both old and new passwords were returned in the call to sql* in authorize. update control { Cleartext-Password := "%{sql_old:SELECT<cleartext password query...>}" } # Stop users logging in with null password (if there's no 'old' password set) if("%{control:Cleartext-Password}" == ''){ reject } # Remove stale password hashes created on first call to rlm_mschap update control { NT-Password -= "%{control:NT-Password}" LM-Password -= "%{control:LM-Password}" } mschap } } Arran -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2
On 25/6/09 14:53, Arran Cudbard-Bell wrote:
On 25/6/09 12:01, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
I leave you guys alone for 5 minutes....
8-) as i said, theres probably a way of doing it
*sigh* the Coffee excuse doesn't work past lunch time does it... (missed out some curly braces) instantiate { sql_old } authorize { # Retrieves credentials sql_new # Sets auth-type mschap mschap } authenticate { Auth-Type MS-CHAP { mschap { reject = 2 } if(reject){ # Could alternatively write the value of a custom attribute into Cleartext-password # if both old and new passwords were returned in the call to sql* in authorize. update control { Cleartext-Password := "%{sql_old:SELECT<cleartext password query...>}" } # Stop users logging in with null password (if there's no 'old' password set) if("%{control:Cleartext-Password}" == ''){ reject } # Remove stale password hashes created on first call to rlm_mschap update control { NT-Password -= "%{control:NT-Password}" LM-Password -= "%{control:LM-Password}" } mschap } } } -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2
Thanks a lot, guys. I am on vacation until Monday, but am very tempted to login to work and give this a try......nah, it can wait until Monday :). Thanks again for you efforts. John
-----Original Message----- From: freeradius-users- bounces+john.kane=prodeasystems.com@lists.freeradius.org [mailto:freeradius-users- bounces+john.kane=prodeasystems.com@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: Thursday, June 25, 2009 9:21 AM To: FreeRadius users mailing list Subject: Re: Old password 'grace period'
On 25/6/09 14:53, Arran Cudbard-Bell wrote:
On 25/6/09 12:01, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
I leave you guys alone for 5 minutes....
8-) as i said, theres probably a way of doing it
*sigh* the Coffee excuse doesn't work past lunch time does it... (missed out some curly braces)
instantiate { sql_old }
authorize { # Retrieves credentials sql_new # Sets auth-type mschap mschap }
authenticate { Auth-Type MS-CHAP { mschap { reject = 2 } if(reject){ # Could alternatively write the value of a custom attribute into Cleartext-password # if both old and new passwords were returned in the call to sql* in authorize. update control { Cleartext-Password := "%{sql_old:SELECT<cleartext password query...>}" } # Stop users logging in with null password (if there's no 'old' password set) if("%{control:Cleartext-Password}" == ''){ reject } # Remove stale password hashes created on first call to rlm_mschap update control { NT-Password -= "%{control:NT-Password}" LM-Password -= "%{control:LM-Password}" } mschap } } }
-- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
This message is confidential to Prodea Systems, Inc unless otherwise indicated or apparent from its nature. This message is directed to the intended recipient only, who may be readily determined by the sender of this message and its contents. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient:(a)any dissemination or copying of this message is strictly prohibited; and(b)immediately notify the sender by return message and destroy any copies of this message in any form(electronic, paper or otherwise) that you have.The delivery of this message and its information is neither intended to be nor constitutes a disclosure or waiver of any trade secrets, intellectual property, attorney work product, or attorney-client communications. The authority of the individual sending this message to legally bind Prodea Systems is neither apparent nor implied,and must be independently verified.
Arran Cudbard-Bell
*sigh* the Coffee excuse doesn't work past lunch time does it... (missed out some curly braces)
instantiate { sql_old }
authorize { # Retrieves credentials sql_new # Sets auth-type mschap mschap }
authenticate { Auth-Type MS-CHAP { mschap { reject = 2 } if(reject){ # Could alternatively write the value of a custom attribute into Cleartext-password # if both old and new passwords were returned in the call to sql* in authorize. update control { Cleartext-Password := "%{sql_old:SELECT<cleartext password query...>}" } # Stop users logging in with null password (if there's no 'old' password set) if("%{control:Cleartext-Password}" == ''){ reject } # Remove stale password hashes created on first call to rlm_mschap update control { NT-Password -= "%{control:NT-Password}" LM-Password -= "%{control:LM-Password}" } mschap } } }
[JK] This works beautifully.....I want to thank Arran and others for the quick response. Very much appreciated. John This message is confidential to Prodea Systems, Inc unless otherwise indicated or apparent from its nature. This message is directed to the intended recipient only, who may be readily determined by the sender of this message and its contents. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient:(a)any dissemination or copying of this message is strictly prohibited; and(b)immediately notify the sender by return message and destroy any copies of this message in any form(electronic, paper or otherwise) that you have.The delivery of this message and its information is neither intended to be nor constitutes a disclosure or waiver of any trade secrets, intellectual property, attorney work product, or attorney-client communications. The authority of the individual sending this message to legally bind Prodea Systems is neither apparent nor implied,and must be independently verified.
[JK] This works beautifully.....I want to thank Arran and others for the quick response. Very much appreciated.
Excellent. Glad to hear :) Thanks, Arran -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Arran Cudbard-Bell -
Ivan Kalik -
John Kane