Digest using an external database for the Password
Hi I am running version 2.1.12. I want to use FreeRadius in the following way: - Use Digest Authentication - The password is stored in an external database (it has a complicated schema) that I am connecting to via sql.conf. - I want to extract the password from this database so that it can be used in Digest Authentication (SIP – using RFC 4590) Now I have tested FreeRadius with the radclient using digest authentication by placing the Cleartext-Password in the users file – this worked. Is it possible to get the Cleartext-Password (or is it the User-Password) from my external database through authorize_check_query ? If so, how do I assign this attribute to the value returned in my query? I can’t store any information in my external database as I am not allowed to create any tables The following query would return the password – can I use it in authorize_check_query? authorize_check_query="SELECT password FROM fusion.cdm_credentials WHERE person_id=(SELECT person_id FROM fusion.cdm_person WHERE user_name='%{User-Name}');" As you can see in the query I have to use password as it is a column entry in my database There is a similar mechanism for LDAP where you can use the passsword_attribute Or am I totally off track? Thx Mike -------------------- Note: The information contained in this message may be privileged and confidential and protected from disclosure. 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, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Thrupoint, Inc. nXaR2cC3
Mike Brennan wrote:
* Use Digest Authentication * The password is stored in an external database (it has a complicated schema) that I am connecting to via sql.conf. * I want to extract the password from this database so that it can be used in Digest Authentication (SIP – using RFC 4590)
Is the password stored in clear-text? If so, it can work. If not, it's impossible.
Is it possible to get the Cleartext-Password (or is it the User-Password) from my external database through authorize_check_query ?
Yes. But you need to edit it.
If so, how do I assign this attribute to the value returned in my query?
You create an "Attribute = value", like with everything else in the server.
I can’t store any information in my external database as I am not allowed to create any tables
That's fine.
The following query would return the password – can I use it in authorize_check_query?
authorize_check_query="SELECT password FROM fusion.cdm_credentials WHERE person_id=(SELECT person_id FROM fusion.cdm_person WHERE user_name='%{User-Name}');"
No. The authorize_check_query needs to return "Attribute = value", as shown by the default configuration. You can update your query to return that. Or, don't use "sql" in the "authorize" section, as it expects to see the default FreeRADIUS schema. List "sql" in "instantite", and then do: authorize { ... update control { Cleartext-Password := "%{sql: SELECT password FROM fusion ...}" } ... } i.e. if you have a SELECT which returns a password, you can assign that directly to the Cleartext-Password attribute yourself.
Or am I totally off track?
No. Alan DeKok.
Hi Alan Yes the password is in clear text. Thx - I will let you know if I am successful Regards Mike -----Original Message----- From: freeradius-users-bounces+mbrennan=thrupoint.com@lists.freeradius.org [mailto:freeradius-users-bounces+mbrennan=thrupoint.com@lists.freeradius.o rg] On Behalf Of Alan DeKok Sent: 25 April 2013 13:47 To: FreeRadius users mailing list Subject: Re: Digest using an external database for the Password Mike Brennan wrote:
* Use Digest Authentication * The password is stored in an external database (it has a complicated schema) that I am connecting to via sql.conf. * I want to extract the password from this database so that it can be used in Digest Authentication (SIP - using RFC 4590)
Is the password stored in clear-text? If so, it can work. If not, it's impossible.
Is it possible to get the Cleartext-Password (or is it the User-Password) from my external database through authorize_check_query ?
Yes. But you need to edit it.
If so, how do I assign this attribute to the value returned in my query?
You create an "Attribute = value", like with everything else in the server.
I can't store any information in my external database as I am not allowed to create any tables
That's fine.
The following query would return the password - can I use it in authorize_check_query?
authorize_check_query="SELECT password FROM fusion.cdm_credentials WHERE person_id=(SELECT person_id FROM fusion.cdm_person WHERE user_name='%{User-Name}');"
No. The authorize_check_query needs to return "Attribute = value", as shown by the default configuration. You can update your query to return that. Or, don't use "sql" in the "authorize" section, as it expects to see the default FreeRADIUS schema. List "sql" in "instantite", and then do: authorize { ... update control { Cleartext-Password := "%{sql: SELECT password FROM fusion ...}" } ... } i.e. if you have a SELECT which returns a password, you can assign that directly to the Cleartext-Password attribute yourself.
Or am I totally off track?
No. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -------------------- Note: The information contained in this message may be privileged and confidential and protected from disclosure. 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, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Thrupoint, Inc. nXaR2cC3
Hi Alan Thx for your input I did the following: In radiusd.conf file, within the instantiate section the following was added: sql authorize { ... update control { Cleartext-Password := "%{sql: SELECT password FROM fusion ...}" } ... } In the inner-tunnel file I commented out the sql in the authorize section. It seemed to work - see attached small snippet from my debug. In the attached file there is still a rlm_sql_mysql: MYSQL check_error: 1146 received message I have missed something else? Thx again Mike -----Original Message----- From: freeradius-users-bounces+mbrennan=thrupoint.com@lists.freeradius.org [mailto:freeradius-users-bounces+mbrennan=thrupoint.com@lists.freeradius.o rg] On Behalf Of Alan DeKok Sent: 25 April 2013 13:47 To: FreeRadius users mailing list Subject: Re: Digest using an external database for the Password Mike Brennan wrote:
* Use Digest Authentication * The password is stored in an external database (it has a complicated schema) that I am connecting to via sql.conf. * I want to extract the password from this database so that it can be used in Digest Authentication (SIP - using RFC 4590)
Is the password stored in clear-text? If so, it can work. If not, it's impossible.
Is it possible to get the Cleartext-Password (or is it the User-Password) from my external database through authorize_check_query ?
Yes. But you need to edit it.
If so, how do I assign this attribute to the value returned in my query?
You create an "Attribute = value", like with everything else in the server.
I can't store any information in my external database as I am not allowed to create any tables
That's fine.
The following query would return the password - can I use it in authorize_check_query?
authorize_check_query="SELECT password FROM fusion.cdm_credentials WHERE person_id=(SELECT person_id FROM fusion.cdm_person WHERE user_name='%{User-Name}');"
No. The authorize_check_query needs to return "Attribute = value", as shown by the default configuration. You can update your query to return that. Or, don't use "sql" in the "authorize" section, as it expects to see the default FreeRADIUS schema. List "sql" in "instantite", and then do: authorize { ... update control { Cleartext-Password := "%{sql: SELECT password FROM fusion ...}" } ... } i.e. if you have a SELECT which returns a password, you can assign that directly to the Cleartext-Password attribute yourself.
Or am I totally off track?
No. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -------------------- Note: The information contained in this message may be privileged and confidential and protected from disclosure. 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, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Thrupoint, Inc. nXaR2cC3
Mike Brennan wrote:
Hi Alan Thx for your input I did the following: In radiusd.conf file, within the instantiate section the following was added: sql authorize { ... update control { Cleartext-Password := "%{sql: SELECT password FROM fusion ...}" } ... }
That is *not* what I said to do. Some amount of independent thought is required. List "sql" in the "instantiate" section. DON'T put the rest of the text above. DO edit the "inner-tunnel" file. Look for the "authorize" section. The text above shows an EXAMPLE of what you put in the "authorize" section. That's why it uses the word "authorize" DON'T put the "..." text in the config files. That was meant to show that OTHER text was also in the "authorize" section. DON'T put the "..." text in the SQL query. That was meant to show the REST of the SQL query DO think about what you're doing. DO put the ENTIRE sql SELECT statement into the example text I showed above.
In the inner-tunnel file I commented out the sql in the authorize section.
It seemed to work - see attached small snippet from my debug. In the attached file there is still a rlm_sql_mysql: MYSQL check_error: 1146 received message I have missed something else?
Yes. That error is a MySQL error. You've mis-typed the query. Go read MySQL documentation to see how to create a correct query. Alan DeKok.
Hi Alan Did as you suggested - the error has gone I did put in the correct text in the sql statement (just did not want to rewrite in e-mail) and it was not this that was failing. The error was because I overwrote in the sql.conf file the radius_db with my database name - I commented out this and the error disappeared. Thx for your help Mike -----Original Message----- From: freeradius-users-bounces+mbrennan=thrupoint.com@lists.freeradius.org [mailto:freeradius-users-bounces+mbrennan=thrupoint.com@lists.freeradius.o rg] On Behalf Of Alan DeKok Sent: 25 April 2013 16:20 To: FreeRadius users mailing list Subject: Re: Digest using an external database for the Password Mike Brennan wrote:
Hi Alan Thx for your input I did the following: In radiusd.conf file, within the instantiate section the following was added: sql authorize { ... update control { Cleartext-Password := "%{sql: SELECT password FROM fusion ...}" } ... }
That is *not* what I said to do. Some amount of independent thought is required. List "sql" in the "instantiate" section. DON'T put the rest of the text above. DO edit the "inner-tunnel" file. Look for the "authorize" section. The text above shows an EXAMPLE of what you put in the "authorize" section. That's why it uses the word "authorize" DON'T put the "..." text in the config files. That was meant to show that OTHER text was also in the "authorize" section. DON'T put the "..." text in the SQL query. That was meant to show the REST of the SQL query DO think about what you're doing. DO put the ENTIRE sql SELECT statement into the example text I showed above.
In the inner-tunnel file I commented out the sql in the authorize section.
It seemed to work - see attached small snippet from my debug. In the attached file there is still a rlm_sql_mysql: MYSQL check_error: 1146 received message I have missed something else?
Yes. That error is a MySQL error. You've mis-typed the query. Go read MySQL documentation to see how to create a correct query. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -------------------- Note: The information contained in this message may be privileged and confidential and protected from disclosure. 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, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Thrupoint, Inc. nXaR2cC3
Hi I now a have solution where an SBC is acting as a Radius Client that is connecting to FreeRadius (2.1.12) to do SIP Digest authentication. The password is stored in an external database (this is not the default schema but my own). I have extracted the password (clear text) using an sql query.
From the previous e-mail I put the sql query in the inner-tunnel (this was confirmed by Alan), however, I think this maybe incorrect - I believe it should go in the default file (AM I CORRECT?)
Now I have done two tests - one test passes the other fails. The test that passes - see the following two files: draft_sterman_aaa_sip_03_freeradius_debug for the radiusd -X output and radiusclient_draft_sterman_aaa_sip_03 for the Radiusclient output. As can be seen this passes and my endpoint is authenticated. The other test fails - see the following two files: rfc4590_freeradius_debug and the radiusclient_rfc4590. The authentication fails, I suspect that the attributes passed seems to cause FreeRadius to reject the authentication. Not sure whether it is the client causing the trouble with erroneous setting of the attributes or whether Freeradius is interpreting them incorrectly It would be good to get to the bottom of the problem with using RFC 4590 - I hope the debug files help. In the debug some fields are set as removed - this is what I replaced sensitive information with. Thx Mike -----Original Message----- From: freeradius-users-bounces+mbrennan=thrupoint.com@lists.freeradius.org [mailto:freeradius-users-bounces+mbrennan=thrupoint.com@lists.freeradius.o rg] On Behalf Of Alan DeKok Sent: 25 April 2013 16:20 To: FreeRadius users mailing list Subject: Re: Digest using an external database for the Password Mike Brennan wrote:
Hi Alan Thx for your input I did the following: In radiusd.conf file, within the instantiate section the following was added: sql authorize { ... update control { Cleartext-Password := "%{sql: SELECT password FROM fusion ...}" } ... }
That is *not* what I said to do. Some amount of independent thought is required. List "sql" in the "instantiate" section. DON'T put the rest of the text above. DO edit the "inner-tunnel" file. Look for the "authorize" section. The text above shows an EXAMPLE of what you put in the "authorize" section. That's why it uses the word "authorize" DON'T put the "..." text in the config files. That was meant to show that OTHER text was also in the "authorize" section. DON'T put the "..." text in the SQL query. That was meant to show the REST of the SQL query DO think about what you're doing. DO put the ENTIRE sql SELECT statement into the example text I showed above.
In the inner-tunnel file I commented out the sql in the authorize section.
It seemed to work - see attached small snippet from my debug. In the attached file there is still a rlm_sql_mysql: MYSQL check_error: 1146 received message I have missed something else?
Yes. That error is a MySQL error. You've mis-typed the query. Go read MySQL documentation to see how to create a correct query. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -------------------- Note: The information contained in this message may be privileged and confidential and protected from disclosure. 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, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Thrupoint, Inc. nXaR2cC3
Mike Brennan wrote:
From the previous e-mail I put the sql query in the inner-tunnel (this was confirmed by Alan), however, I think this maybe incorrect - I believe it should go in the default file (AM I CORRECT?)
(a) you can wander around making random changes to "fix" things, or (b) you can understand what's going on. It's not hard. And no, I'm not going to spoon-feed you. The answer is in front of you. It's in the debug logs you posted. Have you read them, looking for "inner-tunnel"?
The other test fails - see the following two files: rfc4590_freeradius_debug and the radiusclient_rfc4590. The authentication fails, I suspect that the attributes passed seems to cause FreeRadius to reject the authentication. Not sure whether it is the client causing the trouble with erroneous setting of the attributes or whether Freeradius is interpreting them incorrectly
FreeRADIUS doesn't implement RFC 4590. So far as I've seen, no one else does, either.
It would be good to get to the bottom of the problem with using RFC 4590 - I hope the debug files help. In the debug some fields are set as removed - this is what I replaced sensitive information with.
What client are you using to generate the digest authentication? Alan DeKok.
Ok - I think I get it........, if I just want to use the default I should remove the soft link in the site-enabled to the inner-tunnel. This should be sufficient for my deployment at the moment - although I will be looking into clustering this and using potentially LVS (this no doubt will be another world of pain - my database backend is going to be an Oracle cluster.....) As for RFC 4590 support, I believe IEA Software support it. I confused the fact that on your web site you list RFC 4590 in the "list of RFCs" as a tacit indication of support. Is RFC 4590 on your roadmap? The client generating the DIGEST is an ACME SBC it supports a number of DIGEST RFC's Sorry for being a pain Regards Mike -----Original Message----- From: freeradius-users-bounces+mbrennan=thrupoint.com@lists.freeradius.org [mailto:freeradius-users-bounces+mbrennan=thrupoint.com@lists.freeradius.o rg] On Behalf Of Alan DeKok Sent: 30 April 2013 13:36 To: FreeRadius users mailing list Subject: Re: Digest using an external database for the Password Mike Brennan wrote:
From the previous e-mail I put the sql query in the inner-tunnel (this was confirmed by Alan), however, I think this maybe incorrect - I believe it should go in the default file (AM I CORRECT?)
(a) you can wander around making random changes to "fix" things, or (b) you can understand what's going on. It's not hard. And no, I'm not going to spoon-feed you. The answer is in front of you. It's in the debug logs you posted. Have you read them, looking for "inner-tunnel"?
The other test fails - see the following two files: rfc4590_freeradius_debug and the radiusclient_rfc4590. The authentication fails, I suspect that the attributes passed seems to cause FreeRadius to reject the authentication. Not sure whether it is the client causing the trouble with erroneous setting of the attributes or whether Freeradius is interpreting them incorrectly
FreeRADIUS doesn't implement RFC 4590. So far as I've seen, no one else does, either.
It would be good to get to the bottom of the problem with using RFC 4590 - I hope the debug files help. In the debug some fields are set as removed - this is what I replaced sensitive information with.
What client are you using to generate the digest authentication? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -------------------- Note: The information contained in this message may be privileged and confidential and protected from disclosure. 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, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Thrupoint, Inc. nXaR2cC3
Mike Brennan wrote:
As for RFC 4590 support, I believe IEA Software support it.
I'm sure that's nice for them.
I confused the fact that on your web site you list RFC 4590 in the "list of RFCs" as a tacit indication of support. Is RFC 4590 on your roadmap?
No. RFC 4590 was wrong. It was replaced by RFC 5090. And we don't plan on implementing RFC 5090, because no NAS vendor implements it.
The client generating the DIGEST is an ACME SBC it supports a number of DIGEST RFC's
Everyone uses the sterman draft. It's arguably wrong, but it's what people do. Alan DeKok.
Hi,
Hi Alan Thx for your input I did the following: In radiusd.conf file, within the instantiate section the following was added: sql
authorize { ... update control { Cleartext-Password := "%{sql: SELECT password FROM fusion ...}"
}
do you really mean that you added the above into the instatiate section? dont. you instantiate SQL - but you have things configured in your sql module and are calling it elsewhere..which is why you get this:
rlm_sql (sql): Reserving sql socket id: 4 [sql] expand: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radcheck WHERE username = '' ORDER BY id rlm_sql_mysql: MYSQL check_error: 1146 received rlm_sql_getvpdata: database query error [sql] SQL query error; rejecting user
you've still got 'sql' being called..and still have default calls looking for that statement and using radcheck table alan
participants (3)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Mike Brennan