I have came thru a number of references which states that LDAP are specialised database and optimized for read. Would that make it a good idea to authenticate thru LDAP *but* the accounting is handled thru mySQL ? Anybody have done this or am I talking nonsense here? (am 2 days old with RADIUS)
Bubuk Gabrok wrote:
I have came thru a number of references which states that LDAP are specialised database and optimized for read.
You should setup the system you're the most familiar with. Unless you've *huge* RADIUS traffic on your site (more than 500 req/s) you won't notice the performance differences.
Would that make it a good idea to authenticate thru LDAP *but* the accounting is handled thru mySQL ? Anybody have done this or am I talking nonsense here?
This is common to use OpenLDAP for auth and MySQL for acct. http://freeradius.org/radiusd/doc/ldap_howto.txt -- Nicolas Baradakis
I've noticed very strange behavior of freeradius. After processing of 'digest' message I invoke 'authorize_reply_query' that returns list of values in SIP-AVP parameter In log it looks like this [cut] radius_xlat: 'SELECT * FROM test.authorize_reply('SIP','test002@server1.test.pl', 'sip:+48580001@server1.test.pl', 'INVITE' )' rlm_sql_postgresql: query: SELECT * FROM test.authorize_reply('SIP','test002@server1.test.pl', 'sip:+48580001@server1.test.pl', 'INVITE' ) rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: affected rows = [cut] Sending Access-Accept of id 8 to 153.19.130.250 port 44072 SIP-AVP == "#1:+48580001" SIP-AVP == "#2:3" SIP-AVP == "#3:4" Finished request 0 Going to the next request As you see radius returns 3 attributes and it is ok. But I also receive 'non-digest' message: rad_recv: Access-Request packet from host 153.19.130.250:44073, id=9, length=70 User-Name = "+48580001@server1.test.pl" Service-Type = SIP-Callee-AVPs NAS-Port = 0 NAS-IP-Address = 153.19.130.250 I do not why for this message radius invoke: - authorize_check_query - authorize_group_check_query - authorize_group_reply but I do not know why radius DOES NOT invoke authorize_reply_query!! Do you know why ?? Because authorize_reply_query is not invoked I put my logic to authorize_group_reply but it appeared that sql statement in authorize_group_reply CAN only return only one row for the same attribute! I thing it is a bug, to be sure that it is not my bug I've put the same functionality in authorize_repy_query (for digest messages) and it has worked without any problem. I would like that authorize_group_reply returns something like this: SIP-AVP == "#1:+48580001" SIP-AVP == "#test1" SIP-AVP == "#test2" But it only returns: SIP-AVP == "#1:+48580001" Any ideas? I cannot return values in other attributes, and in worst case I return all values in one line of SIP-AVP but it is not best solution. Michal Szymanski http://blog.szymanskich.net
Quoting biuro@globeinphotos.com:
I've noticed very strange behavior of freeradius. After processing of 'digest' message I invoke 'authorize_reply_query' that returns list of values in SIP-AVP parameter
In log it looks like this
Well, probably I've found reason of bug :) rlm_sql (sql): User +48580001@server1.test.pl not found in radcheck simply user was not found in DB and freereadius does not invoke authorize_reply_query. I have to check my program once again but I think it is a reeason.
In log it looks like this
Well, probably I've found reason of bug :) rlm_sql (sql): User +48580001@server1.test.pl not found in radcheck
simply user was not found in DB and freereadius does not invoke authorize_reply_query. I have to check my program once again but I think it is a reeason.
But still question remains, why authorize_reply_group cannot return several values in the same attribute. Regards Michal Szymanski
biuro@globeinphotos.com wrote:
But still question remains, why authorize_reply_group cannot return several values in the same attribute.
It can. You just have to set the operator correctly. See the rlm_sql documentation. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On 7/27/06, Nicolas Baradakis <nbk@sitadelle.com> wrote:
Bubuk Gabrok wrote:
I have came thru a number of references which states that LDAP are specialised database and optimized for read.
You should setup the system you're the most familiar with. Unless you've *huge* RADIUS traffic on your site (more than 500 req/s) you won't notice the performance differences.
Would that make it a good idea to authenticate thru LDAP *but* the accounting is handled thru mySQL ? Anybody have done this or am I talking nonsense here?
This is common to use OpenLDAP for auth and MySQL for acct.
http://freeradius.org/radiusd/doc/ldap_howto.txt
-- Nicolas Baradakis
Thanks for the info.
participants (4)
-
Alan DeKok -
biuro＠globeinphotos.com -
Bubuk Gabrok -
Nicolas Baradakis