[SR-Users] Authentication Feature Question

Ali Jawad ali.jawad at splendor.net
Wed Jan 4 09:46:09 CET 2012


On a seperate note, am I correct to assume that in order to remove
domain calculation from Kamailio I need to work around

static inline int get_ha1(struct username* _username, str* _domain,
./authorize.c:                    const str* _table, char* _ha1,
db1_res_t** res)

in authorize.c ?

Regards
On Wed, Jan 4, 2012 at 10:17 AM, Ali Jawad <ali.jawad at splendor.net> wrote:
> Hi
> When I did set modparam("auth_db", "calculate_ha1", 0  )
>
> Kamailio is crashing see
>
> http://pastebin.com/anaKan0Y
>
> Regards
>
> On Tue, Jan 3, 2012 at 11:54 PM, Ali Jawad <ali.jawad at splendor.net> wrote:
>> Hi
>> It fetches one value from the database to compare it against a second
>> value that has to be computed right, in the computation of the second
>> hash where is the domain part fetched from  ?
>> Regards
>>
>> On Wed, Jan 4, 2012 at 12:26 AM, Daniel-Constantin Mierla
>> <miconda at gmail.com> wrote:
>>> Hello,
>>>
>>>
>>> On 1/3/12 10:08 PM, Ali Jawad wrote:
>>>>
>>>> Hi
>>>>
>>>> In Xlite/eyebeam I put in the username and one of my 3 kamailio
>>>> servers respectively as the sip registrar, I.e. register1.domain.com,
>>>> register2.domain.com and register3.domain.com, that is why I was
>>>> saying that hashing will create different hashes based on the register
>>>> domain.  With reference to my first related post, one kamailio server
>>>> is for softphones, one for sip devices and one for mobile phones with
>>>> SIP software. Each server has a slightly different NAT and Call
>>>> routing structure.
>>>
>>> but your service domain is 'domain.com', specific server addresses (domains)
>>> per UA type should be set as outbound proxy on the UA devices.
>>>
>>>> This is why I wanted to eliminate the domain factor from the hashing
>>>> procedure, I am sure it chooses the right value from the DB  value
>>>> because it is the same value shown in the log of kamailio against
>>>> which a comparison is being done and because it works if I put
>>>> register.domain.com in the domain column rehash the HA! value of the
>>>> db.
>>>
>>>
>>> When auth_db module is configured to take the hashed value from database
>>> (calculate_ha1 parameter is 0), there is no more computation of it in
>>> kamailio -- it is just fetched from database and used -- so it does not
>>> matter anymore the domains in the sip message.
>>>
>>> Check to see if the xlite does not have a realm field that has to be set
>>> properly.
>>>
>>>
>>>
>>>>>>>>> values at 0xb7b78dac
>>>>>>>>>>
>>>>>>>>>>  5(18649) DEBUG:<core>        [db_val.c:117]: converting STRING
>>>>>>>>>> [6f966cd9c628f14cdc20172f96a4d065]<====##### This is the value in
>>>>>>>>>> the DB based on domain.com
>>>>>>>>>>  5(18649) DEBUG: auth [api.c:210]: check_response: Our result =
>>>>>>>>>> '6f95e6235edca0b7765042ef119fd83b'<====##### This value appears to
>>>>>>>>>> be the value generated register.domain.com
>>>>>>>>>>  5(18649) DEBUG: auth [api.c:220]: check_response: Authorization
>>>>
>>>> How can I enable the SQL query log ?
>>>
>>>
>>> I don't know by hart, googling should help you.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>>>
>>>> On Tue, Jan 3, 2012 at 8:12 PM, Daniel-Constantin Mierla
>>>> <miconda at gmail.com>  wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> why are you using register.domain.com as domain for registration? Isn't
>>>>> domain.com the right one?
>>>>>
>>>>> Can you enable the sql query log for mysql server and double check if the
>>>>> right value (column) is selected from the database table?
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>
>>>>>
>>>>> On 1/3/12 5:13 PM, Ali Jawad wrote:
>>>>>>
>>>>>> Hi
>>>>>> Please see the below, thanks !
>>>>>>
>>>>>> interface: eth1 (xx.xx.xx.0/255.255.255.0)
>>>>>> match: support1
>>>>>>
>>>>>> U +6.698682 yy.yy.yy.146:18832 ->    xx.xx.xx.51:5060
>>>>>> REGISTER sip:register.domain.com SIP/2.0.
>>>>>> Via: SIP/2.0/UDP
>>>>>>
>>>>>>
>>>>>> 192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport.
>>>>>> Max-Forwards: 70.
>>>>>>
>>>>>>
>>>>>> Contact:<sip:support1 at 192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp>.
>>>>>> To: "Test Ast"<sip:support1 at register.domain.com>.
>>>>>> From: "Test Ast"<sip:support1 at register.domain.com>;tag=f710b930.
>>>>>> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY..
>>>>>> CSeq: 1 REGISTER.
>>>>>> Expires: 3600.
>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
>>>>>> SUBSCRIBE, INFO.
>>>>>> User-Agent: eyeBeam release 1102q stamp 51814.
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>>
>>>>>> U +0.005245 xx.xx.xx.51:5060 ->    yy.yy.yy.146:18832
>>>>>> SIP/2.0 401 Unauthorized.
>>>>>> Via: SIP/2.0/UDP
>>>>>>
>>>>>>
>>>>>> 192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport=18832;received=yy.yy.yy.146.
>>>>>> To: "Test
>>>>>>
>>>>>> Ast"<sip:support1 at register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.3053.
>>>>>> From: "Test Ast"<sip:support1 at register.domain.com>;tag=f710b930.
>>>>>> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY..
>>>>>> CSeq: 1 REGISTER.
>>>>>> WWW-Authenticate: Digest realm="domain.com",
>>>>>> nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl".
>>>>>> Server: kamailio (3.2.1 (i386/linux)).
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>>
>>>>>> U +0.428042 yy.yy.yy.146:18832 ->    xx.xx.xx.51:5060
>>>>>> REGISTER sip:register.domain.com SIP/2.0.
>>>>>> Via: SIP/2.0/UDP
>>>>>>
>>>>>>
>>>>>> 192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport.
>>>>>> Max-Forwards: 70.
>>>>>>
>>>>>>
>>>>>> Contact:<sip:support1 at 192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp>.
>>>>>> To: "Test Ast"<sip:support1 at register.domain.com>.
>>>>>> From: "Test Ast"<sip:support1 at register.domain.com>;tag=f710b930.
>>>>>> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY..
>>>>>> CSeq: 2 REGISTER.
>>>>>> Expires: 3600.
>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
>>>>>> SUBSCRIBE, INFO.
>>>>>> User-Agent: eyeBeam release 1102q stamp 51814.
>>>>>> Authorization: Digest
>>>>>>
>>>>>>
>>>>>> username="support1",realm="domain.com",nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl",uri="sip:register.domain.com",response="6122245b77e2df0b90179304464341e7",algorithm=MD5.
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>>
>>>>>> U +0.005146 xx.xx.xx.51:5060 ->    yy.yy.yy.146:18832
>>>>>> SIP/2.0 401 Unauthorized.
>>>>>> Via: SIP/2.0/UDP
>>>>>>
>>>>>>
>>>>>> 192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport=18832;received=yy.yy.yy.146.
>>>>>> To: "Test
>>>>>>
>>>>>> Ast"<sip:support1 at register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.fce3.
>>>>>> From: "Test Ast"<sip:support1 at register.domain.com>;tag=f710b930.
>>>>>> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY..
>>>>>> CSeq: 2 REGISTER.
>>>>>> WWW-Authenticate: Digest realm="domain.com",
>>>>>> nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl".
>>>>>> Server: kamailio (3.2.1 (i386/linux)).
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>> [root at kam-rtp-100-51 mysql]# mail alijawad1 at gmail.com<    output.txt
>>>>>> [root at kam-rtp-100-51 mysql]#  ngrep -W byline -T support1  -q -d eth1
>>>>>> interface: eth1 (xx.xx.xx.0/255.255.255.0)
>>>>>> match: support1
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> U +5.321505 yy.yy.yy.146:63610 ->    xx.xx.xx.51:5060
>>>>>> REGISTER sip:register.domain.com SIP/2.0.
>>>>>> Via: SIP/2.0/UDP
>>>>>>
>>>>>>
>>>>>> 192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport.
>>>>>> Max-Forwards: 70.
>>>>>>
>>>>>>
>>>>>> Contact:<sip:support1 at 192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp>.
>>>>>> To: "Test Ast"<sip:support1 at register.domain.com>.
>>>>>> From: "Test Ast"<sip:support1 at register.domain.com>;tag=ba705453.
>>>>>> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI..
>>>>>> CSeq: 1 REGISTER.
>>>>>> Expires: 3600.
>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
>>>>>> SUBSCRIBE, INFO.
>>>>>> User-Agent: eyeBeam release 1102q stamp 51814.
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>>
>>>>>> U +0.004782 xx.xx.xx.51:5060 ->    yy.yy.yy.146:63610
>>>>>> SIP/2.0 401 Unauthorized.
>>>>>> Via: SIP/2.0/UDP
>>>>>>
>>>>>>
>>>>>> 192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport=63610;received=yy.yy.yy.146.
>>>>>> To: "Test
>>>>>>
>>>>>> Ast"<sip:support1 at register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.6b98.
>>>>>> From: "Test Ast"<sip:support1 at register.domain.com>;tag=ba705453.
>>>>>> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI..
>>>>>> CSeq: 1 REGISTER.
>>>>>> WWW-Authenticate: Digest realm="domain.com",
>>>>>> nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk".
>>>>>> Server: kamailio (3.2.1 (i386/linux)).
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>>
>>>>>> U +0.400706 yy.yy.yy.146:63610 ->    xx.xx.xx.51:5060
>>>>>> REGISTER sip:register.domain.com SIP/2.0.
>>>>>> Via: SIP/2.0/UDP
>>>>>>
>>>>>>
>>>>>> 192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport.
>>>>>> Max-Forwards: 70.
>>>>>>
>>>>>>
>>>>>> Contact:<sip:support1 at 192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp>.
>>>>>> To: "Test Ast"<sip:support1 at register.domain.com>.
>>>>>> From: "Test Ast"<sip:support1 at register.domain.com>;tag=ba705453.
>>>>>> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI..
>>>>>> CSeq: 2 REGISTER.
>>>>>> Expires: 3600.
>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
>>>>>> SUBSCRIBE, INFO.
>>>>>> User-Agent: eyeBeam release 1102q stamp 51814.
>>>>>> Authorization: Digest
>>>>>>
>>>>>>
>>>>>> username="support1",realm="domain.com",nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk",uri="sip:register.domain.com",response="4bfd80b0b836c20b748ee19a1c886284",algorithm=MD5.
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>>
>>>>>> U +0.005302 xx.xx.xx.51:5060 ->    yy.yy.yy.146:63610
>>>>>> SIP/2.0 401 Unauthorized.
>>>>>> Via: SIP/2.0/UDP
>>>>>>
>>>>>>
>>>>>> 192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport=63610;received=yy.yy.yy.146.
>>>>>> To: "Test
>>>>>>
>>>>>> Ast"<sip:support1 at register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.2f76.
>>>>>> From: "Test Ast"<sip:support1 at register.domain.com>;tag=ba705453.
>>>>>> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI..
>>>>>> CSeq: 2 REGISTER.
>>>>>> WWW-Authenticate: Digest realm="domain.com",
>>>>>> nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk".
>>>>>> Server: kamailio (3.2.1 (i386/linux)).
>>>>>> Content-Length: 0.
>>>>>> .
>>>>>>
>>>>>> On Tue, Jan 3, 2012 at 6:08 PM, Daniel-Constantin Mierla
>>>>>> <miconda at gmail.com>    wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I need the entire flow for registration, including the 401 reply and
>>>>>>> the
>>>>>>> following REGISTER request.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Daniel
>>>>>>>
>>>>>>>
>>>>>>> On 1/3/12 5:02 PM, Ali Jawad wrote:
>>>>>>>>
>>>>>>>> Hi
>>>>>>>> Please see the ngrep below, please note that if I use in the db
>>>>>>>> register.domain.com and generate a hash against it for HA1 it
>>>>>>>> works,but then the user cant logon to register2.domain.com
>>>>>>>>
>>>>>>>>
>>>>>>>> U +10.630576 xx.yy.yy.yy:20020 ->      xx.xx.xx.xx:5060
>>>>>>>> REGISTER sip:register.domain SIP/2.0.
>>>>>>>> Via: SIP/2.0/UDP
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 192.168.0.191:20020;branch=z9hG4bK-d8754z-af65a442980c375f-1---d8754z-;rport.
>>>>>>>> Max-Forwards: 70.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Contact:<sip:support1 at 192.168.0.191:20020;rinstance=4009190a4e109ac6;transport=udp>.
>>>>>>>> To: "Test Ast"<sip:support1 at register.domain>.
>>>>>>>> From: "Test Ast"<sip:support1 at register.domain>;tag=976bb004.
>>>>>>>> Call-ID: MDFmZDU2ZTI2YjJjMGNlMGFmOTIzMWFmZGQ1ZTNjMDE..
>>>>>>>> CSeq: 1 REGISTER.
>>>>>>>> Expires: 3600.
>>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
>>>>>>>> SUBSCRIBE, INFO.
>>>>>>>> User-Agent: eyeBeam release 1102q stamp 51814.
>>>>>>>> Content-Length: 0.
>>>>>>>>
>>>>>>>> On Tue, Jan 3, 2012 at 5:58 PM, Daniel-Constantin Mierla
>>>>>>>> <miconda at gmail.com>      wrote:
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 1/3/12 4:48 PM, Ali Jawad 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 ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> the first parameter in www_authorize and www_challenge functions is
>>>>>>>>> the
>>>>>>>>> realm and it is used to build the digest response.
>>>>>>>>>
>>>>>>>>> Is your phone putting user at domain in authorization header? Can you
>>>>>>>>> paste
>>>>>>>>> here the ngrep of registration?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Daniel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I might be wrong....thanks for the help so far.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>>
>>>>>>>>>> On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla
>>>>>>>>>> <miconda at 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 at 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
>>>>>>>>>>>>>> Jawad<ali.jawad at 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>> --
>>>>> 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
>
>
>
> --
> Ali Jawad
> Information Systems Manager
> Splendor Telecom (www.splendor.net)
> Beirut, Lebanon
> Phone: +9611373725/ext 116
> FAX: +9611375554



-- 
Ali Jawad
Information Systems Manager
Splendor Telecom (www.splendor.net)
Beirut, Lebanon
Phone: +9611373725/ext 116
FAX: +9611375554



More information about the sr-users mailing list