sr-users October 2005

sr-users@lists.kamailio.org

214 participants
457 discussions

[Serusers] How to do RADIUS authentication with hashed password (MD5 or HA1)?

by Cheng Zhang

I have setup SER to authenticate via FreeRADIUS with MSSQL DB. The problem is that the user's password is stored as cleartext in the database. I'd like to know is there a way to make such setup using hashed password (just MD5 or HA1)? In module auth_db, there is a mod parameter 'calculate_ha1' being set to 0 can be used for similiar purpose. But there is no such option for auth_radius. Maybe this is about how to configure FreeRADIUS, but I couldn't dig anything up from FreeRADIUS mailing list archive either.

18 years, 8 months

[Users] How to do RADIUS authentication with hashed password (MD5 or HA1)?

by Cheng Zhang

18 years, 8 months

[Users] extra accounting problem

by jayesh nambiar

hi all, I want to account src_ips in my acc table. While using openser0.9.5 I used the following modparam syntax: modparam("acc", "db_extra", "src= avp/i:10") and when doing setflag(1), I wrote avp_write() syntax to write src_ip in i:10. But now I am using openser 0.10.x and it gives me an error saying the following: Oct 14 12:35:43 localhost /usr/local/sbin/openser[19916]: ACC - initializing Oct 14 12:35:43 localhost /usr/local/sbin/openser[19916]: xl_parse_item: error - bad parameters Oct 14 12:35:43 localhost /usr/local/sbin/openser[19916]: ERROR:acc:parse_acc_extra: parse failed in <src= avp/i:10> around position 5 Oct 14 12:35:43 localhost /usr/local/sbin/openser[19916]: acc:parse_acc_extra: error Oct 14 12:35:43 localhost /usr/local/sbin/openser[19916]: ERROR:acc:mod_init: failed to parse db_extra param Oct 14 12:35:43 localhost /usr/local/sbin/openser[19916]: init_mod(): Error while initializing module acc Could someone pls let me know, if the syntax for adding extra column in acc table has changed. I have a column named "src" in the acc table. thank you. jayesh --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs. Try it free.

18 years, 8 months

[Serusers] group_radius radius_is_user_in

by lenirsantiago＠yahoo.com

Hello list, I've been trying my hardest today to get group_radius to work, and its function radius_is_user_in(). I'm running ser0.9.4 and freeradius 1.0.4 with the mysql backend and digest authentication. Radius authentication works fine. The problem is that when radius_is_user_in() function gets called, it sends a radius message but without the User-Password field and freeradius complains that it requires it since we are using Digest. I've seen a couple of posts here, but they were never answered: http://lists.iptel.org/pipermail/serusers/2005-March/017342.html http://lists.iptel.org/pipermail/serusers/2005-March/017075.html ----- I have a small test in my ser.cfg file: if (!radius_www_authorize("")) { xlog("L_I","%ci - %fu - User not authenticated, Radius Authenticating...\n"); www_challenge("","0"); break; } else { xlog("L_I","%ci - %fu - User authenticated...\n"); }; if (radius_is_user_in("From", "Dialin")){ xlog("L_I","From: User is in Radius Group Dialin!!!!\n"); } else { xlog("L_I","From: User *IS NOT* Group Dialin!!!!!\n"); }; if (radius_is_user_in("Credentials", "Dialin2")){ xlog("L_I","From: User is in Radius Group Dialin2!!!!\n"); } else { xlog("L_I","From: User *IS NOT* Group Dialin2!!!!!\n"); }; ----- In /etc/raddb/users file I have the following at line 152: DEFAULT Auth-Type = System Fall-Through = 1 DEFAULT Service-Type == Group-Check, Auth-Type := None DEFAULT Service-Type == SIP-Callee-AVPs, Auth-Type := None ----- These are mysql tables: +----+----------+-----------+----+----------+ | id | UserName | Attribute | op | Value | +----+----------+-----------+----+----------+ | 1 | Jhassell | Password | == | changeme | | 2 | Rneis | Password | == | changeme | | 3 | 1000 | Password | == | 1000 | | 4 | 2000 | Password | == | 2000 | | 5 | 3000 | Password | == | 3000 | | 8 | 1000 | Auth-Type | := | Digest | +----+----------+-----------+----+----------+ +----+-----------+-----------+----+--------+ | id | GroupName | Attribute | op | Value | +----+-----------+-----------+----+--------+ | 6 | Dialin | Auth-Type | := | Accept | +----+-----------+-----------+----+--------+ +----+-----------+---------------+----+----------------------------------+-- ----+ | id | GroupName | Attribute | op | Value | prio | +----+-----------+---------------+----+----------------------------------+-- ----+ | 1 | Dialin | Reply-Message | = | "Authenticated by group Dialin" | 0 | | 2 | Dialin2 | Reply-Message | = | "Authenticated by group Dialin2" | 0 | +----+-----------+---------------+----+----------------------------------+-- ----+ +----+----------+---------------+----+------------------+ | id | UserName | Attribute | op | Value | +----+----------+---------------+----+------------------+ | 1 | 1000 | Reply-Message | = | "Authenticated" | | 2 | 1000 | Sip-Group | = | Dialin | | 3 | 1000 | SIP-AVP | = | Sip-Group:Dialin | +----+----------+---------------+----+------------------+ +----+----------+------------+ | id | UserName | GroupName | +----+----------+------------+ | 1 | Jhassell | Dialin | | 2 | Rneis | Staticdial | | 3 | 1000 | Dialin | | 4 | 2000 | Dialin | | 5 | 3000 | Dialin | | 6 | 3000 | Dialin2 | +----+----------+------------+ ------ This is the debug I get from freeradius for the group check: rad_recv: Access-Request packet from host xx.xx.xx.xx:33025, id=15, length=67 User-Name = "1000(a)xx.xx.xx.xx" Sip-Group = "Dialin2" Service-Type = Group-Check NAS-IP-Address = 127.0.0.1 NAS-Port = 0 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 74 modcall[authorize]: module "preprocess" returns ok for request 74 modcall[authorize]: module "chap" returns noop for request 74 modcall[authorize]: module "mschap" returns noop for request 74 modcall[authorize]: module "digest" returns noop for request 74 rlm_realm: Looking up realm "xx.xx.xx.xx" for User-Name = "1000(a)xx.xx.xx.xx" rlm_realm: Found realm "xx.xx.xx.xx" rlm_realm: Adding Stripped-User-Name = "1000" rlm_realm: Proxying request from user 1000 to realm xx.xx.xx.xx rlm_realm: Adding Realm = "xx.xx.xx.xx" rlm_realm: Authentication realm is LOCAL. modcall[authorize]: module "suffix" returns noop for request 74 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 74 users: Matched entry DEFAULT at line 152 users: Matched entry DEFAULT at line 158 modcall[authorize]: module "files" returns ok for request 74 radius_xlat: '1000' rlm_sql (sql): sql_set_user escaped user --> '1000' rlm_sql (sql): Released sql socket id: 0 modcall[authorize]: module "sql" returns ok for request 74 modcall: group authorize returns ok for request 74 rad_check_password: Found Auth-Type Digest auth: type "digest" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 74 ERROR: No Digest-Nonce: Cannot perform Digest authentication modcall[authenticate]: module "digest" returns invalid for request 74 modcall: group authenticate returns invalid for request 74 auth: Failed to validate the user. Delaying request 74 for 1 seconds Finished request 74 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 15 to xx.xx.xx.xx:33025 Reply-Message = "Authenticated" Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 74 ID 15 with timestamp 434f1121 Nothing to do. Sleeping until we see a request. Any help in this matter would be deeply appreciated, Lenir

18 years, 8 months

[Users] group_radius radius_is_user_in

by lenirsantiago＠yahoo.com

Hello list, I've been trying my hardest today to get group_radius to work, and its function radius_is_user_in(). I'm running ser0.9.4 and freeradius 1.0.4 with the mysql backend and digest authentication. Radius authentication works fine. The problem is that when radius_is_user_in() function gets called, it sends a radius message but without the User-Password field and freeradius complains that it requires it since we are using Digest. I've seen a couple of posts here, but they were never answered: http://mail.iptel.org/pipermail/serusers/2005-March/017342.html http://mail.iptel.org/pipermail/serusers/2005-March/017075.html ----- I have a small test in my ser.cfg file: if (!radius_www_authorize("")) { xlog("L_I","%ci - %fu - User not authenticated, Radius Authenticating...\n"); www_challenge("","0"); break; } else { xlog("L_I","%ci - %fu - User authenticated...\n"); }; if (radius_is_user_in("From", "Dialin")){ xlog("L_I","From: User is in Radius Group Dialin!!!!\n"); } else { xlog("L_I","From: User *IS NOT* Group Dialin!!!!!\n"); }; if (radius_is_user_in("Credentials", "Dialin2")){ xlog("L_I","From: User is in Radius Group Dialin2!!!!\n"); } else { xlog("L_I","From: User *IS NOT* Group Dialin2!!!!!\n"); }; ----- In /etc/raddb/users file I have the following at line 152: DEFAULT Auth-Type = System Fall-Through = 1 DEFAULT Service-Type == Group-Check, Auth-Type := None DEFAULT Service-Type == SIP-Callee-AVPs, Auth-Type := None ----- These are mysql tables: +----+----------+-----------+----+----------+ | id | UserName | Attribute | op | Value | +----+----------+-----------+----+----------+ | 1 | Jhassell | Password | == | changeme | | 2 | Rneis | Password | == | changeme | | 3 | 1000 | Password | == | 1000 | | 4 | 2000 | Password | == | 2000 | | 5 | 3000 | Password | == | 3000 | | 8 | 1000 | Auth-Type | := | Digest | +----+----------+-----------+----+----------+ +----+-----------+-----------+----+--------+ | id | GroupName | Attribute | op | Value | +----+-----------+-----------+----+--------+ | 6 | Dialin | Auth-Type | := | Accept | +----+-----------+-----------+----+--------+ +----+-----------+---------------+----+----------------------------------+-- ----+ | id | GroupName | Attribute | op | Value | prio | +----+-----------+---------------+----+----------------------------------+-- ----+ | 1 | Dialin | Reply-Message | = | "Authenticated by group Dialin" | 0 | | 2 | Dialin2 | Reply-Message | = | "Authenticated by group Dialin2" | 0 | +----+-----------+---------------+----+----------------------------------+-- ----+ +----+----------+---------------+----+------------------+ | id | UserName | Attribute | op | Value | +----+----------+---------------+----+------------------+ | 1 | 1000 | Reply-Message | = | "Authenticated" | | 2 | 1000 | Sip-Group | = | Dialin | | 3 | 1000 | SIP-AVP | = | Sip-Group:Dialin | +----+----------+---------------+----+------------------+ +----+----------+------------+ | id | UserName | GroupName | +----+----------+------------+ | 1 | Jhassell | Dialin | | 2 | Rneis | Staticdial | | 3 | 1000 | Dialin | | 4 | 2000 | Dialin | | 5 | 3000 | Dialin | | 6 | 3000 | Dialin2 | +----+----------+------------+ ------ This is the debug I get from freeradius for the group check: rad_recv: Access-Request packet from host xx.xx.xx.xx:33025, id=15, length=67 User-Name = "1000(a)xx.xx.xx.xx" Sip-Group = "Dialin2" Service-Type = Group-Check NAS-IP-Address = 127.0.0.1 NAS-Port = 0 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 74 modcall[authorize]: module "preprocess" returns ok for request 74 modcall[authorize]: module "chap" returns noop for request 74 modcall[authorize]: module "mschap" returns noop for request 74 modcall[authorize]: module "digest" returns noop for request 74 rlm_realm: Looking up realm "xx.xx.xx.xx" for User-Name = "1000(a)xx.xx.xx.xx" rlm_realm: Found realm "xx.xx.xx.xx" rlm_realm: Adding Stripped-User-Name = "1000" rlm_realm: Proxying request from user 1000 to realm xx.xx.xx.xx rlm_realm: Adding Realm = "xx.xx.xx.xx" rlm_realm: Authentication realm is LOCAL. modcall[authorize]: module "suffix" returns noop for request 74 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 74 users: Matched entry DEFAULT at line 152 users: Matched entry DEFAULT at line 158 modcall[authorize]: module "files" returns ok for request 74 radius_xlat: '1000' rlm_sql (sql): sql_set_user escaped user --> '1000' rlm_sql (sql): Released sql socket id: 0 modcall[authorize]: module "sql" returns ok for request 74 modcall: group authorize returns ok for request 74 rad_check_password: Found Auth-Type Digest auth: type "digest" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 74 ERROR: No Digest-Nonce: Cannot perform Digest authentication modcall[authenticate]: module "digest" returns invalid for request 74 modcall: group authenticate returns invalid for request 74 auth: Failed to validate the user. Delaying request 74 for 1 seconds Finished request 74 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 15 to xx.xx.xx.xx:33025 Reply-Message = "Authenticated" Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 74 ID 15 with timestamp 434f1121 Nothing to do. Sleeping until we see a request. Any help in this matter would be deeply appreciated, Lenir

18 years, 8 months

RE: [Serusers] trusting peers

by Dmitry Isakbayev

Hi Klaus, There is another option. A UAC can present an authorization token issued by a trusted Open Settlement Protocol server. If UAS successfully validates the token, it can presume that the client is trusted. The trusted OSP server can use different policies for authenticating the UAC. OSP is an open standard defined by ETSI - the European Telecommunications Standards Institute. It has been widely deployed by VoIP carriers to enforce secure access control for peer to peer inter-domain VoIP routing and Call Detail Record (CDR) collection. The 'osp' module (http://osp-module.berlios.de or http://developer.berlios.de/projects/osp-module) adds support for the OSP to (Open) SER. We are in the process of moving the project to (Open) SER's CVS. Regards, Dmitry > -----Original Message----- > From: serusers-bounces(a)lists.iptel.org > [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Klaus Darilion > Sent: Tuesday, October 11, 2005 8:56 AM > To: ser users; users openser.org > Subject: [Serusers] trusting peers > > Hi all! > > I want to differ between _incoming_ SIP requests from trusted > peers and from untrused (for different call routing). I came > to the following solutions. All of them has some > disadvantages, and I would like to now which you would prefer: > > 1. src_ip: incoming request are authenticated using the > src_ip (only in TCP mode useful) > +: easy to implement > +: easy to differ authenticated from unauthenticated incoming calls > -: lots of configuration (IP addresses may change, ) This > can be implemented using if src_ip==... blocks in > openser.cfg, which would require the change the script > everytime the IP addresses are changed. Also requires restart > of the proxy. > > Also from_gw() from lcr module can be used. But this would > interfere with the already used lcr tasks and IP addresses. > Maybe copy/paste the code into a new function called from_peer(). > > 2. IPsec: makes it hard to differ trusted from untrusted > incomig requests in the application. Again verification of > the src_ip would be necessary. > -: requires sharing secrets with each peer > +: works also with TCP and TLS unaware proxies > > 3. TLS with certificates signed by me. Then, if my SIP proxy > only uses my root CA, all authenticated TLS connection must > be from my trusted peers. > +: simple, as long as there is only 1 perring-club to authenticate > +: works with current (open)ser > -: can't use public CA roots > -: requires signing of the public key of the peer > > 4. TLS with public signed certificates. (open)ser would > validate the TLS certificate. But after that, I need some > function like > tls_is_from_trusted() which checks the Subject of the > certificate against a list of trusted peers. > +: can use public signed CA roots > +: allows to use TLS for incoming trusted and incoming untrusted peers > -: need some more tls specific functions in (open)ser > -: certificate costs $$$ > > 5. Digest Auth between proxies > -: uac module is not standard conform (CSeq Problem) > -: requires sharing secrets with each peer > > If I have forgotten some possibilities or made some mistakes > please correct me. > > regards > klaus > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > >

18 years, 8 months

[Users] OT: please help us make the ENUM number range +43 780 a success

by Klaus Darilion

Hi all! This is a little bit off topic. But people interested in ENUM are sure interested in this. As some of you maybe already know, Austria has a dedicated ENUM driven number range in place since May 2005: +43 780. Reachability of numbers within this range from the PSTN is good within Austria, but still a patchwork from abroad (as with all new number ranges). It is very hard to debug PSTN connectivity from the receiving end - which is why we are asking you to dedicate a few minutes of time and a phone call. To collect the information we've set up a Wiki page: http://www.voip-info.org/wiki/view/43780 To help us make it better, follow these steps: - take a "conventional" phone line of your choice (PSTN, mobile - the more data points, the better) - call the test number "+43 780 004711" - if you hear the word "ENUM" followed by some elevator music, routing from your telco is ok - perfect! - if it doesn't work, take a note of what happened (announcement, error message, error indication etc.) - leave a note about your success or failure to the wiki page indicated above. If possible, add rate information. - repeat this test for any carrier you have access to. If you detect a failure, and happen to know or work for the telco - please notify the relevant person to fix the problem, it is theirs. We're happy to talk to them if you get us in touch. Thanks for your help - we really appreciate it. Feel free to forward this message to people who might contribute more data points. thanks, Klaus Darilion enum.at

18 years, 8 months

[Serusers] serweb: DB Error: no such field

by Ronald Wiplinger

# history |grep "cvs -z3" 568 cvs -z3 checkout sip-server 1004 cvs -z3 -d:pserver:anonymous@cvs.serweb.berlios.de:/cvsroot/serweb co serweb I use cvs! /serweb/user/index.php and login as admin gives me on the tab "my account" DB Error: no such field logout /serweb/admin/index.php and login as admin gives me on the tabs "users" "admin privileges" and "user preferences" DB Error: no such field How to fix that? bye Ronald Wiplinger

18 years, 8 months

[Serusers] DB.php missing in serweb

by Ronald Wiplinger

My php-error.log shows now: [client 192.168.250.108] PHP Warning: main(DB.php): failed to open stream: No such file or directory in /usr/local/serweb/html/main_prepend.php on line 38 [client 192.168.250.108] PHP Fatal error: main(): Failed opening required 'DB.php' (include_path='.:') in /usr/local/serweb/html/main_prepend.php on line 38 # locate DB.php /usr/share/php/DB.php Where do I set this? bye Ronald Wiplinger

18 years, 8 months

[Users] trusting peers

by Klaus Darilion

Hi all! I want to differ between _incoming_ SIP requests from trusted peers and from untrused (for different call routing). I came to the following solutions. All of them has some disadvantages, and I would like to now which you would prefer: 1. src_ip: incoming request are authenticated using the src_ip (only in TCP mode useful) +: easy to implement +: easy to differ authenticated from unauthenticated incoming calls -: lots of configuration (IP addresses may change, ) This can be implemented using if src_ip==... blocks in openser.cfg, which would require the change the script everytime the IP addresses are changed. Also requires restart of the proxy. Also from_gw() from lcr module can be used. But this would interfere with the already used lcr tasks and IP addresses. Maybe copy/paste the code into a new function called from_peer(). 2. IPsec: makes it hard to differ trusted from untrusted incomig requests in the application. Again verification of the src_ip would be necessary. -: requires sharing secrets with each peer +: works also with TCP and TLS unaware proxies 3. TLS with certificates signed by me. Then, if my SIP proxy only uses my root CA, all authenticated TLS connection must be from my trusted peers. +: simple, as long as there is only 1 perring-club to authenticate +: works with current (open)ser -: can't use public CA roots -: requires signing of the public key of the peer 4. TLS with public signed certificates. (open)ser would validate the TLS certificate. But after that, I need some function like tls_is_from_trusted() which checks the Subject of the certificate against a list of trusted peers. +: can use public signed CA roots +: allows to use TLS for incoming trusted and incoming untrusted peers -: need some more tls specific functions in (open)ser -: certificate costs $$$ 5. Digest Auth between proxies -: uac module is not standard conform (CSeq Problem) -: requires sharing secrets with each peer If I have forgotten some possibilities or made some mistakes please correct me. regards klaus

18 years, 8 months

← Newer
1
...
23
24
25
26
27
28
29
...
46
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users October 2005