I.e. I get
5(18649) DEBUG: <core> [db_val.c:117]: converting STRING [6f966cd9c628f14cdc20172f96a4d065] 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = '6f95e6235edca0b7765042ef119fd83b' 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization failed
Before I get to the part below.
5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: realm='domain.com' 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: Digest realm="domain.com", nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE"
On Tue, Jan 3, 2012 at 5:48 PM, Ali Jawad ali.jawad@splendor.net wrote:
Hi Daniel
Please see
5(18649) DEBUG: <core> [db_res.c:184]: allocate 8 bytes for rows at 0xb7b78d74 5(18649) DEBUG: <core> [db_row.c:119]: allocate 20 bytes for row values at 0xb7b78dac 5(18649) DEBUG: <core> [db_val.c:117]: converting STRING [6f966cd9c628f14cdc20172f96a4d065] 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = '6f95e6235edca0b7765042ef119fd83b' 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization failed 5(18649) DEBUG: <core> [db_res.c:81]: freeing 1 columns 5(18649) DEBUG: <core> [db_res.c:85]: freeing RES_NAMES[0] at 0xb7b78d3c 5(18649) DEBUG: <core> [db_res.c:94]: freeing result names at 0xb7b78bfc 5(18649) DEBUG: <core> [db_res.c:99]: freeing result types at 0xb7b78c64 5(18649) DEBUG: <core> [db_res.c:54]: freeing 1 rows 5(18649) DEBUG: <core> [db_row.c:97]: freeing row values at 0xb7b78dac 5(18649) DEBUG: <core> [db_res.c:62]: freeing rows at 0xb7b78d74 5(18649) DEBUG: <core> [db_res.c:136]: freeing result set at 0xb7b78bb0 5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: realm='nymgo.com' 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: Digest realm="domain.com", nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE" '
I rebuilt the hashes against domain.com and then tried to connect to sip1.domain.com and sip2.domain.com and sip3.domain.com with all of the having
# ----- auth_db params ----- #!ifdef WITH_AUTH modparam("auth_db", "db_url", DBURL) modparam("auth_db", "calculate_ha1", 0 ) modparam("auth_db", "password_column", "ha1") modparam("auth_db", "load_credentials", "") modparam("auth_db", "use_domain", MULTIDOMAIN)
And in the routing process :
if (!www_authorize("domain.com", "subscriber")) {
www_challenge("domain.com", "0"); exit; }
+++++++++++++
My point is that the hashes are caculated from user:doman:pwd which are extracted from the SIP packet and in this case the domains are sip1,sip2,sip3 while the hashes stored in the database are generated against domain.com
If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I have to set the domain/realm in the config file ?
I might be wrong....thanks for the help so far.
Regards
On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 4:12 PM, Ali Jawad wrote:
Hi Daniel This certainly makes sense, I will try it in a few mins, but what I observed at Debug Level 3 is that Hash is calculated before www_authenticate is executed and it shows HA comparison failed, if I do use domain.com instead of $fd and use $domain.com in db domain field and build HA1 filed based on that, wont Kamailio still try to build the HA1 hash which it will compare form user:domain:pwd where domain is fed in to the hash function from the header of the SIP packet ?
the ha1 is actually hash over 'user:realm:pwd' -- it is just common practice to use the domain as realm, since realm should be a unique token to identify the service, but it can be any random string. realm is given as parameter to auth functions in kamailio.cfg
Cheers, Daniel
Regards
On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
you can simply use 'domain.com' as realm parameter to authentication function instead of $fd. Also build ha1 and ha1b with domain.com and then you are safe no matter which sip server is used.
Of course you can build the realm by striping first token before '.' in $fd and pass it to authentication functions, but not sure if makes sense since it should be always domain.com
Cheers, Daniel
On 1/3/12 3:15 PM, Ali Jawad wrote:
Hi After some research it seems to me that the only way to achieve this is to "try" and change how hashing is done in the source code, a little bit too ambitious for me, and it means I will have loads of problems each time an upgrade is released.
Or
Use pseudovariables to fix the value of the $fd value to something constant, while this worked for values like $var(y) I was not able to assign/strip $fd to remove the subdomain part.
Any input please ?
Regards
On Tue, Jan 3, 2012 at 2:06 PM, Ali Jawadali.jawad@splendor.net wrote:
Hi I do have 3 Kamailio servers, one for mobile phone registrations, one for softphone registrations and one for SIP device registrations. Each of those devices connects to it's perspective kamailio server
sip1.domain.com sip2.domain.com sip3.domain.com
All 3 Kamailio servers share the same database, and users can use their kamailio user/pwd on any of the devices, now I want to use encrypted passwords and remove clear text passwords from the database. I did test with one server and all is fine,however if a user want to register from the second kamailio server it does not work, basically because the db domain entry from which the hash is created is sip1.domain.com and stored in the db, while the user connects from to sip2.domain.com this eventually generates a different hash.
Is there anyway to overcome this ? Can I exclude Domain from Hash generation ? Any other option that allows me to do the above ?
Thanks
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Ali Jawad Information Systems Manager Splendor Telecom (www.splendor.net) Beirut, Lebanon Phone: +9611373725/ext 116 FAX: +9611375554