RLM_PERL Integration Issue
Well, I've reached a few conclusions here, and according to the following log I can deduce the following: Cleaning up request 253 ID 35 with timestamp 469a18da Sending Access-Reject of id 36 to 192.168.2.80 port 47588 Waking up in 4 seconds... rad_recv: Access-Request packet from host 192.168.2.80:47589, id=37, length=194 User-Name = "101@192.168.2.80" Digest-Attributes = 0x0a05313031 Digest-Attributes = 0x010e3139322e3136382e322e3830 Digest-Attributes = 0x022a34363961323238356338303335366239633531383533353961623933373332303364333931366635 Digest-Attributes = 0x04127369703a3139322e3136382e322e3830 Digest-Attributes = 0x030a5245474953544552 Digest-Response = "1c40cdddbc1dafeaea453f1f2a726e15" Service-Type = Authenticate-Only X-Ascend-PW-Lifetime = 0x313031 NAS-Port = 5060 NAS-IP-Address = 192.168.2.80 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 255 perl_pool: item 0xa459b10 asigned new request. Handled so far: 8 found interpetator at address 0xa459b10 rlm_perl: RAD_REQUEST: X-Ascend-PW-Lifetime = 0x313031 rlm_perl: RAD_REQUEST: Digest-Response = 1c40cdddbc1dafeaea453f1f2a726e15 rlm_perl: RAD_REQUEST: User-Name = 101@192.168.2.80 rlm_perl: RAD_REQUEST: Service-Type = Authenticate-Only rlm_perl: RAD_REQUEST: NAS-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: NAS-Port = 5060 rlm_perl: RAD_REQUEST: Digest-Attributes = ARRAY(0xa592764) perl_pool total/active/spare [32/0/32] Unreserve perl at address 0xa459b10 modcall[authorize]: module "perl" returns ok for request 255 modcall: leaving group authorize (returns ok) for request 255 auth: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user auth: Failed to validate the user. Login incorrect: [101@192.168.2.80/<no User-Password attribute>] (from client openser port 5060) Delaying request 255 for 1 seconds Finished request 255 Going to the next request It would appear the the autorization portion of the process works just fine, and is being negotiated via the rlm_perl module. However, it would appear that the authentication portion isn't even transfered to the handling of the rlm_perl module for some reason. I've gone over various information I can find, in regards to the usage of Auth-Type settings for rlm_perl, however, all have produced the same result at the above. If any one has information at this point, this would be highly appreciated. z2l ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: 14:52:19 (GMT+0200) Asia/Jerusalem יום שלישי 17 יולי 2007 Subject: Re: RLM_PERL Integration Issue FreeRadius-ML wrote:
Well, right now I would like to start of with something really simple. I'd like to have OpenSER authenticate on FreeRadius, Digest is not a must - for all I care at this point, it can be clear-text. I'm currently using the perl script example from the FreeRadius website, which if i understand correctly, should answer OK on any request to it. That is what I where i want to get to at this point, once that is working, i can continue onwards.
You are trying to do two independent things at the same time. 1) get Digest authentication working. 2) Get Perl working. Alan DeKok.
FreeRadius-ML wrote:
I've reached a few conclusions here, and according to the following log I can deduce the following: ... auth: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user
That message would appear to be clear.
It would appear the the autorization portion of the process works just fine, and is being negotiated via the rlm_perl module. However, it would appear that the authentication portion isn't even transfered to the handling of the rlm_perl module for some reason.
Because you didn't tell the server to use the perl module for authentication. That's what the "Auth-Type" message is about.
I've gone over various information I can find, in regards to the usage of Auth-Type settings for rlm_perl, however, all have produced the same result at the above.
So you're saying "I tried stuff and it didn't work". Nope. When I do it, it works. any why are you trying to make your Perl module perform digest authentication? Do you not realize that the server *already* supports digest? All you have to do is set a Cleartext-Password for the user, and the server Just Does the Right Thing. Alan DeKok.
Hi Alan, Well, the perl script is currently setup to return OK on every request. I had enabled the perl section in the authentication part of the configuration, I'm not that dimwitted. Essentially, I need to work with rlm_perl because I don't want to use user flat files or an SQL, as my end target is to authenticate to some propietary system that we've developed here. z2l ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: 20:42:18 (GMT+0200) Asia/Jerusalem יום שלישי 17 יולי 2007 Subject: Re: RLM_PERL Integration Issue FreeRadius-ML wrote:
I've reached a few conclusions here, and according to the following log I can deduce the following: ... auth: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user
That message would appear to be clear.
It would appear the the autorization portion of the process works just fine, and is being negotiated via the rlm_perl module. However, it would appear that the authentication portion isn't even transfered to the handling of the rlm_perl module for some reason.
Because you didn't tell the server to use the perl module for authentication. That's what the "Auth-Type" message is about.
I've gone over various information I can find, in regards to the usage of Auth-Type settings for rlm_perl, however, all have produced the same result at the above.
So you're saying "I tried stuff and it didn't work". Nope. When I do it, it works. any why are you trying to make your Perl module perform digest authentication? Do you not realize that the server *already* supports digest? All you have to do is set a Cleartext-Password for the user, and the server Just Does the Right Thing. Alan DeKok.
FreeRadius-ML wrote:
Well, the perl script is currently setup to return OK on every request.
Which won't work for digest authentication. Please see the "sterman" draft distributed in doc/rfc/
I had enabled the perl section in the authentication part of the configuration, I'm not that dimwitted.
That's nice. Enabling it is one thing. Telling the server to *use* it is another.
Essentially, I need to work with rlm_perl because I don't want to use user flat files or an SQL, as my end target is to authenticate to some propietary system that we've developed here.
Then you're doing it wrong. List the "digest" module in "authorize" and "authenticate". Then, have the perl authorize function set Cleartext-Password, as suggested in the FAQ. Once that's done, you don't *need* a Perl "authenticate" function. As I said a few messages ago: 1) Get digest working 2) Get Perl working You're still insisting on trying to do both at once. That's why it isn't working. Alan DeKok.
Ok, Here's what I did: 1. I've removed all the rlm_perl configurations from the radiusd.conf file, and enabled the digest authentication back. 2. I've added to my users file the following lines: 101@192.168.2.80 Auth-Type := Digest, User-Password == "101" Reply-Message = "Authenticated" 102@192.168.2.80 Auth-Type := Digest, User-Password == "102" Reply-Message = "Authenticated" test@192.168.2.80 Auth-Type := Digest, User-Password == "test" Reply-Message = "Authenticated" Now, when I try to authorize on FreeRadius, i'm getting the following: modcall: entering group authenticate for request 1 rlm_digest: Configuration item "User-Password" or Digest-HA1 is required for authentication. modcall[authenticate]: module "digest" returns invalid for request 1 modcall: leaving group authenticate (returns invalid) for request 1 I'm using version 1.1.7pre3 Z2L ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: 20:59:53 (GMT+0200) Asia/Jerusalem יום שלישי 17 יולי 2007 Subject: Re: RLM_PERL Integration Issue FreeRadius-ML wrote:
Well, the perl script is currently setup to return OK on every request.
Which won't work for digest authentication. Please see the "sterman" draft distributed in doc/rfc/
I had enabled the perl section in the authentication part of the configuration, I'm not that dimwitted.
That's nice. Enabling it is one thing. Telling the server to *use* it is another.
Essentially, I need to work with rlm_perl because I don't want to use user flat files or an SQL, as my end target is to authenticate to some propietary system that we've developed here.
Then you're doing it wrong. List the "digest" module in "authorize" and "authenticate". Then, have the perl authorize function set Cleartext-Password, as suggested in the FAQ. Once that's done, you don't *need* a Perl "authenticate" function. As I said a few messages ago: 1) Get digest working 2) Get Perl working You're still insisting on trying to do both at once. That's why it isn't working. Alan DeKok.
FreeRadius-ML wrote:
1. I've removed all the rlm_perl configurations from the radiusd.conf file, and enabled the digest authentication back. 2. I've added to my users file the following lines:
101@192.168.2.80 Auth-Type := Digest, User-Password == "101" Reply-Message = "Authenticated"
Don't set Auth-Type. The server will figure it out on it's own. Hmm.. the "digest" module wasn't updated to use Cleartext-Password. Still, you should be using: 10@192.168.2.80 Cleartext-Password := "101" Reply-Message = "Authenticated".
I'm using version 1.1.7pre3
Huh? 1.1.7 isn't out, and nothing we've released is called "-pre3". Alan DeKok.
Ok, i've modified the users file to say Cleartext-Password, and I've removed the Auth-type. However, I'm still getting the following: modcall: entering group authorize for request 14 modcall[authorize]: module "preprocess" returns ok for request 14 rlm_digest: Adding Auth-Type = DIGEST modcall[authorize]: module "digest" returns ok for request 14 modcall: leaving group authorize (returns ok) for request 14 rad_check_password: Found Auth-Type DIGEST auth: type "digest" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 14 rlm_digest: Configuration item "User-Password" or Digest-HA1 is required for authentication. modcall[authenticate]: module "digest" returns invalid for request 14 modcall: leaving group authenticate (returns invalid) for request 14 auth: Failed to validate the user. Login incorrect: [101@192.168.2.80/<no User-Password attribute>] (from client 192.168.2.80 port 5060) Delaying request 14 for 1 seconds Finished request 14 I've downloaded the code from the OpenSUSE package ftp server as a source RPM, and built it on my system. Z2L ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: 21:31:08 (GMT+0200) Asia/Jerusalem יום שלישי 17 יולי 2007 Subject: Re: RLM_PERL Integration Issue FreeRadius-ML wrote:
1. I've removed all the rlm_perl configurations from the radiusd.conf file, and enabled the digest authentication back. 2. I've added to my users file the following lines:
101@192.168.2.80 Auth-Type := Digest, User-Password == "101" Reply-Message = "Authenticated"
Don't set Auth-Type. The server will figure it out on it's own. Hmm.. the "digest" module wasn't updated to use Cleartext-Password. Still, you should be using: 10@192.168.2.80 Cleartext-Password := "101" Reply-Message = "Authenticated".
I'm using version 1.1.7pre3
Huh? 1.1.7 isn't out, and nothing we've released is called "-pre3". Alan DeKok.
On Tue 17 Jul 2007, FreeRadius-ML wrote:
Ok,
i've modified the users file to say Cleartext-Password, and I've removed the Auth-type. However, I'm still getting the following:
modcall: entering group authorize for request 14 modcall[authorize]: module "preprocess" returns ok for request 14 rlm_digest: Adding Auth-Type = DIGEST modcall[authorize]: module "digest" returns ok for request 14 modcall: leaving group authorize (returns ok) for request 14 rad_check_password: Found Auth-Type DIGEST auth: type "digest" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 14 rlm_digest: Configuration item "User-Password" or Digest-HA1 is required for authentication. modcall[authenticate]: module "digest" returns invalid for request 14 modcall: leaving group authenticate (returns invalid) for request 14 auth: Failed to validate the user. Login incorrect: [101@192.168.2.80/<no User-Password attribute>] (from client 192.168.2.80 port 5060) Delaying request 14 for 1 seconds Finished request 14
I've downloaded the code from the OpenSUSE package ftp server as a source RPM, and built it on my system.
Z2L ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: 21:31:08 (GMT+0200) Asia/Jerusalem יום שלישי 17 יולי 2007 Subject: Re: RLM_PERL Integration Issue
FreeRadius-ML wrote:
1. I've removed all the rlm_perl configurations from the radiusd.conf file, and enabled the digest authentication back. 2. I've added to my users file the following lines:
101@192.168.2.80 Auth-Type := Digest, User-Password == "101" Reply-Message = "Authenticated"
Don't set Auth-Type. The server will figure it out on it's own.
Hmm.. the "digest" module wasn't updated to use Cleartext-Password. Still, you should be using:
10@192.168.2.80 Cleartext-Password := "101" Reply-Message = "Authenticated".
I'm using version 1.1.7pre3
Huh? 1.1.7 isn't out, and nothing we've released is called "-pre3".
Actually I was helping him on IRC today briefly and he was using some old 1.1.3 rpms for redhat so I pointed him at my 1.1.7 test rpms... The -pre3 rpms are from this morning's build... Cheers -- Peter Nixon http://peternixon.net/
Hey Peter, If you are free and can jump on the IRC, I would really appreciate some online assistance here. Actually, if anyone can jump on the IRC and assist, that would really be nice. Z2L ----- Original Message ----- From: "Peter Nixon" <listuser@peternixon.net> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: 21:52:47 (GMT+0200) Asia/Jerusalem יום שלישי 17 יולי 2007 Subject: Re: RLM_PERL Integration Issue On Tue 17 Jul 2007, FreeRadius-ML wrote:
Ok,
i've modified the users file to say Cleartext-Password, and I've removed the Auth-type. However, I'm still getting the following:
modcall: entering group authorize for request 14 modcall[authorize]: module "preprocess" returns ok for request 14 rlm_digest: Adding Auth-Type = DIGEST modcall[authorize]: module "digest" returns ok for request 14 modcall: leaving group authorize (returns ok) for request 14 rad_check_password: Found Auth-Type DIGEST auth: type "digest" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 14 rlm_digest: Configuration item "User-Password" or Digest-HA1 is required for authentication. modcall[authenticate]: module "digest" returns invalid for request 14 modcall: leaving group authenticate (returns invalid) for request 14 auth: Failed to validate the user. Login incorrect: [101@192.168.2.80/<no User-Password attribute>] (from client 192.168.2.80 port 5060) Delaying request 14 for 1 seconds Finished request 14
I've downloaded the code from the OpenSUSE package ftp server as a source RPM, and built it on my system.
Z2L ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: 21:31:08 (GMT+0200) Asia/Jerusalem יום שלישי 17 יולי 2007 Subject: Re: RLM_PERL Integration Issue
FreeRadius-ML wrote:
1. I've removed all the rlm_perl configurations from the radiusd.conf file, and enabled the digest authentication back. 2. I've added to my users file the following lines:
101@192.168.2.80 Auth-Type := Digest, User-Password == "101" Reply-Message = "Authenticated"
Don't set Auth-Type. The server will figure it out on it's own.
Hmm.. the "digest" module wasn't updated to use Cleartext-Password. Still, you should be using:
10@192.168.2.80 Cleartext-Password := "101" Reply-Message = "Authenticated".
I'm using version 1.1.7pre3
Huh? 1.1.7 isn't out, and nothing we've released is called "-pre3".
Actually I was helping him on IRC today briefly and he was using some old 1.1.3 rpms for redhat so I pointed him at my 1.1.7 test rpms... The -pre3 rpms are from this morning's build... Cheers -- Peter Nixon http://peternixon.net/
Hi Alan, Ok, after removing everything, reverting back to FreeRadius 1.1.6 release, re-writing the configs, synchronizing the dictionaries properly - I managed to make the radclient test work for me correctly, which means that the FreeRadius server is working properly for me. Now, I've attached the OpenSER SIP proxy, and now upon registration of a SIP phone, the following can be seen from in the debug log: --- Walking the entire request list --- Cleaning up request 16 ID 204 with timestamp 469a4341 Sending Access-Reject of id 205 to 192.168.2.80 port 50226 Waking up in 4 seconds... rad_recv: Access-Request packet from host 192.168.2.80:50227, id=206, length=67 User-Name = "101@192.168.2.80" X-Ascend-PPP-VJ-1172 = 0x73757370656e646564 Service-Type = Voice NAS-Port = 0 NAS-IP-Address = 192.168.2.80 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 18 modcall[authorize]: module "preprocess" returns ok for request 18 modcall[authorize]: module "chap" returns noop for request 18 modcall[authorize]: module "mschap" returns noop for request 18 modcall[authorize]: module "digest" returns noop for request 18 rlm_realm: Looking up realm "192.168.2.80" for User-Name = "101@192.168.2.80" rlm_realm: No such realm "192.168.2.80" modcall[authorize]: module "suffix" returns noop for request 18 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 18 users: Matched entry DEFAULT at line 153 users: Matched entry DEFAULT at line 236 modcall[authorize]: module "files" returns ok for request 18 rlm_pap: Found existing Auth-Type, not changing it. modcall[authorize]: module "pap" returns noop for request 18 modcall: leaving group authorize (returns ok) for request 18 rad_check_password: Found Auth-Type Reject rad_check_password: Auth-Type = Reject, rejecting user auth: Failed to validate the user. Login incorrect: [101@192.168.2.80/<no User-Password attribute>] (from client private-network-1 port 0) Delaying request 18 for 1 seconds Finished request 18 Going to the next request Waking up in 4 seconds... I can understand now that authorize is working nicely, but the Authentication section is wrong. I know there's alot of shit in radiusd.conf, however, it shouldn't prevent from the basics to work correctly, no? Z2L ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: 21:31:08 (GMT+0200) Asia/Jerusalem יום שלישי 17 יולי 2007 Subject: Re: RLM_PERL Integration Issue FreeRadius-ML wrote:
1. I've removed all the rlm_perl configurations from the radiusd.conf file, and enabled the digest authentication back. 2. I've added to my users file the following lines:
101@192.168.2.80 Auth-Type := Digest, User-Password == "101" Reply-Message = "Authenticated"
Don't set Auth-Type. The server will figure it out on it's own. Hmm.. the "digest" module wasn't updated to use Cleartext-Password. Still, you should be using: 10@192.168.2.80 Cleartext-Password := "101" Reply-Message = "Authenticated".
I'm using version 1.1.7pre3
Huh? 1.1.7 isn't out, and nothing we've released is called "-pre3". Alan DeKok.
FreeRadius-ML wrote:
I can understand now that authorize is working nicely, but the Authentication section is wrong. I know there's alot of shit in radiusd.conf, however, it shouldn't prevent from the basics to work correctly, no?
The default configuration works. The "shit" that's there exists precisely for people like you, who try to do 3 things at the same time, without understanding what they're doing. All of the hard work is done by the developers, who understand the server. They then write things called "examples" and "documentation" that instruct you how to get things to work. From the default install, do: 1) uncomment "digest" in authorize and authenticate 2) At the TOP of the "users" file, put: bob Cleartext-Password := "bob", User-Password := "bob" 3) do SIP with that username and password. If it works, say so, and say how wonderful FreeRADIUS is, and how easy it was to get digest authentication working. As for your debug log:
users: Matched entry DEFAULT at line 153 users: Matched entry DEFAULT at line 236 modcall[authorize]: module "files" returns ok for request 18
Did you look at those lines in the "users" file? Perhaps, maybe, it's possible that one of them has an "Auth-Type := Reject"? I note that the default "users" file is LESS than 236 lines long. So, the only conclusion is that *you* edited something which broke authentication. Then, you posted a complaint here about how much "shit" there is in the server. When it's clear you didn't even bother to read or understand the debug output. Your frustration with the server is due in large part due to the work you put in to break the configuration. If, instead, you put that much effort into *understanding* it, your progress would have been much better. Alan DeKok.
Hi Alan, First off, I'd like to apologize for my outburst, it's simply getting to be a little too frustrating to me. I've used FreeRadius in the past in conjunction with GnuGK and rlm_sql, which was working flawlessly for over 3 years time. Now, I'm basically re-learning everything, as the world of OpenSER + FreeRadius is a little new to me, and sometimes frustrates me. The amount of documentation in the configuration files is great, but the lack of updated examples is somewhat annoying. Even Asterisk, which is one of the most undocumented environments in the world, has more configuration examples available. In any case, lets go back to what we were discussing. If I understand you correctly, on the FreeRadius side, I only need to enable digest based authentication and authorization, define the user in the users file - and that should be working just fine? I will follow this and will retry. z2l ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Wednesday, July 18, 2007 9:12:07 AM (GMT+0200) Asia/Jerusalem Subject: Re: RLM_PERL Integration Issue FreeRadius-ML wrote:
I can understand now that authorize is working nicely, but the Authentication section is wrong. I know there's alot of shit in radiusd.conf, however, it shouldn't prevent from the basics to work correctly, no?
The default configuration works. The "shit" that's there exists precisely for people like you, who try to do 3 things at the same time, without understanding what they're doing. All of the hard work is done by the developers, who understand the server. They then write things called "examples" and "documentation" that instruct you how to get things to work. From the default install, do: 1) uncomment "digest" in authorize and authenticate 2) At the TOP of the "users" file, put: bob Cleartext-Password := "bob", User-Password := "bob" 3) do SIP with that username and password. If it works, say so, and say how wonderful FreeRADIUS is, and how easy it was to get digest authentication working. As for your debug log:
users: Matched entry DEFAULT at line 153 users: Matched entry DEFAULT at line 236 modcall[authorize]: module "files" returns ok for request 18
Did you look at those lines in the "users" file? Perhaps, maybe, it's possible that one of them has an "Auth-Type := Reject"? I note that the default "users" file is LESS than 236 lines long. So, the only conclusion is that *you* edited something which broke authentication. Then, you posted a complaint here about how much "shit" there is in the server. When it's clear you didn't even bother to read or understand the debug output. Your frustration with the server is due in large part due to the work you put in to break the configuration. If, instead, you put that much effort into *understanding* it, your progress would have been much better. Alan DeKok.
Hi Alan, First off, I'd like to apologize for my outburst, it's simply getting to be a little too frustrating to me. I've used FreeRadius in the past in conjunction with GnuGK and rlm_sql, which was working flawlessly for over 3 years time. Now, I'm basically re-learning everything, as the world of OpenSER + FreeRadius is a little new to me, and sometimes frustrates me. The amount of documentation in the configuration files is great, but the lack of updated examples is somewhat annoying. Even Asterisk, which is one of the most undocumented environments in the world, has more configuration examples available. In any case, lets go back to what we were discussing. If I understand you correctly, on the FreeRadius side, I only need to enable digest based authentication and authorization, define the user in the users file - and that should be working just fine? I will follow this and will retry. z2l ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Wednesday, July 18, 2007 9:12:07 AM (GMT+0200) Asia/Jerusalem Subject: Re: RLM_PERL Integration Issue FreeRadius-ML wrote:
I can understand now that authorize is working nicely, but the Authentication section is wrong. I know there's alot of shit in radiusd.conf, however, it shouldn't prevent from the basics to work correctly, no?
The default configuration works. The "shit" that's there exists precisely for people like you, who try to do 3 things at the same time, without understanding what they're doing. All of the hard work is done by the developers, who understand the server. They then write things called "examples" and "documentation" that instruct you how to get things to work. From the default install, do: 1) uncomment "digest" in authorize and authenticate 2) At the TOP of the "users" file, put: bob Cleartext-Password := "bob", User-Password := "bob" 3) do SIP with that username and password. If it works, say so, and say how wonderful FreeRADIUS is, and how easy it was to get digest authentication working. As for your debug log:
users: Matched entry DEFAULT at line 153 users: Matched entry DEFAULT at line 236 modcall[authorize]: module "files" returns ok for request 18
Did you look at those lines in the "users" file? Perhaps, maybe, it's possible that one of them has an "Auth-Type := Reject"? I note that the default "users" file is LESS than 236 lines long. So, the only conclusion is that *you* edited something which broke authentication. Then, you posted a complaint here about how much "s***" there is in the server. When it's clear you didn't even bother to read or understand the debug output. Your frustration with the server is due in large part due to the work you put in to break the configuration. If, instead, you put that much effort into *understanding* it, your progress would have been much better. Alan DeKok.
FreeRadius-ML wrote:
Now, I'm basically re-learning everything, as the world of OpenSER + FreeRadius is a little new to me, and sometimes frustrates me. The amount of documentation in the configuration files is great, but the lack of updated examples is somewhat annoying. Even Asterisk, which is one of the most undocumented environments in the world, has more configuration examples available.
The majority of FreeRADIUS installations put users & password into SQL or LDAP, and then don't touch it ever again. For them, the existing examples are mostly OK. For *complex* scenarios, RADIUS quickly gets more complicated than DNS, DHCP, Web servers, and (I suspect) Asterisk. There just isn't enough space in the world to document every configuration that everyone needs.
In any case, lets go back to what we were discussing. If I understand you correctly, on the FreeRadius side, I only need to enable digest based authentication and authorization, define the user in the users file - and that should be working just fine?
Yes. The entire *point* of the default configuration is to have as many authentication protocols as possible work... just by defining a user and password. See: http://deployingradius.com/documents/configuration/pap.html When 2.0 is released, defining a username & password will cause the following authentication methods to work: * PAP * CHAP * MS-CHAP * Digest * EAP-MD5 * EAP-MSCHAPv2 * Cisco LEAP * PEAP-MSCHAPv2 * PEAP-GTC * EAP-TTLS with * PAP * CHAP * MS-CHAP * EAP-MD5 * EAP-MSCHAPv2 Try *that* with any other program: "I added one line in a configuration file, and VOIP works, WiFi works, dial-up works, PPPoE works, VPN's work, for Apple, Windows, and Linux". No fighting, no fuss. Alan DeKok.
Hi Alan, Ok, I did as you instructed, and I admit that I appear to be getting somewhere. The debug log now shows the following: -------------------------------- SNIP ----------------------------------------- rad_recv: Access-Request packet from host 192.168.2.80:33365, id=47, length=192 User-Name = "101@openser.org" Digest-Attributes = 0x0a05313031 Digest-Attributes = 0x010d6f70656e7365722e6f7267 Digest-Attributes = 0x022a34363961613063323661386631313165393066336161303533353430393661323631336462343736 Digest-Attributes = 0x04127369703a3139322e3136382e322e3830 Digest-Attributes = 0x030a5245474953544552 Digest-Response = "3f66a7a38c9d6ff05d9d633063085a0c" Service-Type = IAPP-Register X-Ascend-PW-Lifetime = 0x313031 NAS-Port = 5060 NAS-IP-Address = 192.168.2.80 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 17 modcall[authorize]: module "preprocess" returns ok for request 17 radius_xlat: '/usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070716' rlm_detail: /usr/local/freeradius/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070716 modcall[authorize]: module "auth_log" returns ok for request 17 rlm_digest: Adding Auth-Type = DIGEST modcall[authorize]: module "digest" returns ok for request 17 users: Matched entry 101@openser.org at line 54 modcall[authorize]: module "files" returns ok for request 17 modcall: leaving group authorize (returns ok) for request 17 rad_check_password: Found Auth-Type DIGEST auth: type "digest" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 17 rlm_digest: Converting Digest-Attributes to something sane... Digest-User-Name = "101" Digest-Realm = "openser.org" Digest-Nonce = "469aa0c26a8f111e90f3aa05354096a2613db476" Digest-URI = "sip:192.168.2.80" Digest-Method = "REGISTER" A1 = 101:openser.org:101 A2 = REGISTER:sip:192.168.2.80 H(A1) = f195c177997cee336c919be9279c5703 H(A2) = 046d0643f281affab19fe62ffc848ab5 KD = f195c177997cee336c919be9279c5703:469aa0c26a8f111e90f3aa05354096a2613db476:046d0643f281affab19fe62ffc848ab5 EXPECTED 3f66a7a38c9d6ff05d9d633063085a0c RECEIVED 3f66a7a38c9d6ff05d9d633063085a0c modcall[authenticate]: module "digest" returns ok for request 17 modcall: leaving group authenticate (returns ok) for request 17 Login OK: [101@openser.org/<no User-Password attribute>] (from client openser-network port 5060) Sending Access-Accept of id 47 to 192.168.2.80 port 33365 Finished request 17 Going to the next request Waking up in 4 seconds... rad_recv: Access-Request packet from host 192.168.2.80:33366, id=48, length=67 User-Name = "101@192.168.2.80" X-Ascend-PPP-VJ-1172 = 0x73757370656e646564 Service-Type = Voice NAS-Port = 0 NAS-IP-Address = 192.168.2.80 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 18 modcall[authorize]: module "preprocess" returns ok for request 18 radius_xlat: '/usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070716' rlm_detail: /usr/local/freeradius/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070716 modcall[authorize]: module "auth_log" returns ok for request 18 modcall[authorize]: module "digest" returns noop for request 18 users: Matched entry 101@192.168.2.80 at line 53 modcall[authorize]: module "files" returns ok for request 18 modcall: leaving group authorize (returns ok) for request 18 auth: type Local auth: No User-Password or CHAP-Password attribute in the request auth: Failed to validate the user. Login incorrect: [101@192.168.2.80/<no User-Password attribute>] (from client openser-network port 0) Delaying request 18 for 1 seconds Finished request 18 Going to the next request Waking up in 4 seconds... -------------------------------- SNIP ----------------------------------------- If you were to examine the log, you would see that request number 17 is receiving the LOGIN OK, while request 18 is rejected. The silly part here is this, there is only a single IP Phone on the network, which is using a single OpenSER server. I'm kind'a struck with a silly question, where is the second request coming from? Z2L ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: freeradius@zap2link.com Cc: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Wednesday, July 18, 2007 11:24:19 AM (GMT+0200) Asia/Jerusalem Subject: Re: RLM_PERL Integration Issue FreeRadius-ML wrote:
Now, I'm basically re-learning everything, as the world of OpenSER + FreeRadius is a little new to me, and sometimes frustrates me. The amount of documentation in the configuration files is great, but the lack of updated examples is somewhat annoying. Even Asterisk, which is one of the most undocumented environments in the world, has more configuration examples available.
The majority of FreeRADIUS installations put users & password into SQL or LDAP, and then don't touch it ever again. For them, the existing examples are mostly OK. For *complex* scenarios, RADIUS quickly gets more complicated than DNS, DHCP, Web servers, and (I suspect) Asterisk. There just isn't enough space in the world to document every configuration that everyone needs.
In any case, lets go back to what we were discussing. If I understand you correctly, on the FreeRadius side, I only need to enable digest based authentication and authorization, define the user in the users file - and that should be working just fine?
Yes. The entire *point* of the default configuration is to have as many authentication protocols as possible work... just by defining a user and password. See: http://deployingradius.com/documents/configuration/pap.html When 2.0 is released, defining a username & password will cause the following authentication methods to work: * PAP * CHAP * MS-CHAP * Digest * EAP-MD5 * EAP-MSCHAPv2 * Cisco LEAP * PEAP-MSCHAPv2 * PEAP-GTC * EAP-TTLS with * PAP * CHAP * MS-CHAP * EAP-MD5 * EAP-MSCHAPv2 Try *that* with any other program: "I added one line in a configuration file, and VOIP works, WiFi works, dial-up works, PPPoE works, VPN's work, for Apple, Windows, and Linux". No fighting, no fuss. Alan DeKok.
Hi Alan, Ok, I managed to solve the dual request thingy, apparently that was caused by a config on the OpenSER server. All requests now are coming out as: rad_recv: Access-Request packet from host 192.168.2.80:34908, id=213, length=232 User-Name = "101@openser.org" Digest-Attributes = 0x0a05313031 Digest-Attributes = 0x010d6f70656e7365722e6f7267 Digest-Attributes = 0x022a34363961623634663863363039653664303632303135363461336237666137663633383433346462 Digest-Attributes = 0x04127369703a3139322e3136382e322e3830 Digest-Attributes = 0x030a5245474953544552 Digest-Attributes = 0x050661757468 Digest-Attributes = 0x090a3030303031303636 Digest-Attributes = 0x081237323633376361643532353930373938 Digest-Response = "408602140746b6fab2c70881242f7513" Service-Type = IAPP-Register X-Ascend-PW-Lifetime = 0x313031 NAS-Port = 5060 NAS-IP-Address = 192.168.2.80 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 831 modcall[authorize]: module "preprocess" returns ok for request 831 radius_xlat: '/usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070716' rlm_detail: /usr/local/freeradius/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070716 modcall[authorize]: module "auth_log" returns ok for request 831 rlm_digest: Adding Auth-Type = DIGEST modcall[authorize]: module "digest" returns ok for request 831 users: Matched entry 101@openser.org at line 53 modcall[authorize]: module "files" returns ok for request 831 modcall: leaving group authorize (returns ok) for request 831 rad_check_password: Found Auth-Type DIGEST auth: type "digest" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 831 rlm_digest: Converting Digest-Attributes to something sane... Digest-User-Name = "101" Digest-Realm = "openser.org" Digest-Nonce = "469ab64f8c609e6d06201564a3b7fa7f638434db" Digest-URI = "sip:192.168.2.80" Digest-Method = "REGISTER" Digest-QOP = "auth" Digest-Nonce-Count = "00001066" Digest-CNonce = "72637cad52590798" A1 = 101:openser.org:101 A2 = REGISTER:sip:192.168.2.80 H(A1) = f195c177997cee336c919be9279c5703 H(A2) = 046d0643f281affab19fe62ffc848ab5 KD = f195c177997cee336c919be9279c5703:469ab64f8c609e6d06201564a3b7fa7f638434db:00001066:72637cad52590798:auth:046d0643f281affab19fe62ffc848ab5 EXPECTED 408602140746b6fab2c70881242f7513 RECEIVED 408602140746b6fab2c70881242f7513 modcall[authenticate]: module "digest" returns ok for request 831 modcall: leaving group authenticate (returns ok) for request 831 Login OK: [101@openser.org/<no User-Password attribute>] (from client 192.168.2.80 port 5060) Sending Access-Accept of id 213 to 192.168.2.80 port 34908 Finished request 831 Going to the next request Waking up in 6 seconds... Which as much as I can tell, indicate that the digest authentication/authorization process had completed correctly, and our users had been successfully authed by the Radius Server. Currently, I have an issue indicating that the user is actually not registered on the OpenSER server, but i believe that is caused by something else. Unless you have some form of pointer tip here... z2l ----- Original Message ----- From: "FreeRadius-ML" <freeradius@zap2link.com> To: "Alan DeKok" <aland@deployingradius.com> Cc: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Wednesday, July 18, 2007 11:26:38 AM (GMT+0200) Asia/Jerusalem Subject: Re: RLM_PERL Integration Issue Hi Alan, Ok, I did as you instructed, and I admit that I appear to be getting somewhere. The debug log now shows the following: -------------------------------- SNIP ----------------------------------------- rad_recv: Access-Request packet from host 192.168.2.80:33365, id=47, length=192 User-Name = "101@openser.org" Digest-Attributes = 0x0a05313031 Digest-Attributes = 0x010d6f70656e7365722e6f7267 Digest-Attributes = 0x022a34363961613063323661386631313165393066336161303533353430393661323631336462343736 Digest-Attributes = 0x04127369703a3139322e3136382e322e3830 Digest-Attributes = 0x030a5245474953544552 Digest-Response = "3f66a7a38c9d6ff05d9d633063085a0c" Service-Type = IAPP-Register X-Ascend-PW-Lifetime = 0x313031 NAS-Port = 5060 NAS-IP-Address = 192.168.2.80 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 17 modcall[authorize]: module "preprocess" returns ok for request 17 radius_xlat: '/usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070716' rlm_detail: /usr/local/freeradius/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070716 modcall[authorize]: module "auth_log" returns ok for request 17 rlm_digest: Adding Auth-Type = DIGEST modcall[authorize]: module "digest" returns ok for request 17 users: Matched entry 101@openser.org at line 54 modcall[authorize]: module "files" returns ok for request 17 modcall: leaving group authorize (returns ok) for request 17 rad_check_password: Found Auth-Type DIGEST auth: type "digest" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 17 rlm_digest: Converting Digest-Attributes to something sane... Digest-User-Name = "101" Digest-Realm = "openser.org" Digest-Nonce = "469aa0c26a8f111e90f3aa05354096a2613db476" Digest-URI = "sip:192.168.2.80" Digest-Method = "REGISTER" A1 = 101:openser.org:101 A2 = REGISTER:sip:192.168.2.80 H(A1) = f195c177997cee336c919be9279c5703 H(A2) = 046d0643f281affab19fe62ffc848ab5 KD = f195c177997cee336c919be9279c5703:469aa0c26a8f111e90f3aa05354096a2613db476:046d0643f281affab19fe62ffc848ab5 EXPECTED 3f66a7a38c9d6ff05d9d633063085a0c RECEIVED 3f66a7a38c9d6ff05d9d633063085a0c modcall[authenticate]: module "digest" returns ok for request 17 modcall: leaving group authenticate (returns ok) for request 17 Login OK: [101@openser.org/<no User-Password attribute>] (from client openser-network port 5060) Sending Access-Accept of id 47 to 192.168.2.80 port 33365 Finished request 17 Going to the next request Waking up in 4 seconds... rad_recv: Access-Request packet from host 192.168.2.80:33366, id=48, length=67 User-Name = "101@192.168.2.80" X-Ascend-PPP-VJ-1172 = 0x73757370656e646564 Service-Type = Voice NAS-Port = 0 NAS-IP-Address = 192.168.2.80 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 18 modcall[authorize]: module "preprocess" returns ok for request 18 radius_xlat: '/usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070716' rlm_detail: /usr/local/freeradius/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070716 modcall[authorize]: module "auth_log" returns ok for request 18 modcall[authorize]: module "digest" returns noop for request 18 users: Matched entry 101@192.168.2.80 at line 53 modcall[authorize]: module "files" returns ok for request 18 modcall: leaving group authorize (returns ok) for request 18 auth: type Local auth: No User-Password or CHAP-Password attribute in the request auth: Failed to validate the user. Login incorrect: [101@192.168.2.80/<no User-Password attribute>] (from client openser-network port 0) Delaying request 18 for 1 seconds Finished request 18 Going to the next request Waking up in 4 seconds... -------------------------------- SNIP ----------------------------------------- If you were to examine the log, you would see that request number 17 is receiving the LOGIN OK, while request 18 is rejected. The silly part here is this, there is only a single IP Phone on the network, which is using a single OpenSER server. I'm kind'a struck with a silly question, where is the second request coming from? Z2L ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: freeradius@zap2link.com Cc: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Wednesday, July 18, 2007 11:24:19 AM (GMT+0200) Asia/Jerusalem Subject: Re: RLM_PERL Integration Issue FreeRadius-ML wrote:
Now, I'm basically re-learning everything, as the world of OpenSER + FreeRadius is a little new to me, and sometimes frustrates me. The amount of documentation in the configuration files is great, but the lack of updated examples is somewhat annoying. Even Asterisk, which is one of the most undocumented environments in the world, has more configuration examples available.
The majority of FreeRADIUS installations put users & password into SQL or LDAP, and then don't touch it ever again. For them, the existing examples are mostly OK. For *complex* scenarios, RADIUS quickly gets more complicated than DNS, DHCP, Web servers, and (I suspect) Asterisk. There just isn't enough space in the world to document every configuration that everyone needs.
In any case, lets go back to what we were discussing. If I understand you correctly, on the FreeRadius side, I only need to enable digest based authentication and authorization, define the user in the users file - and that should be working just fine?
Yes. The entire *point* of the default configuration is to have as many authentication protocols as possible work... just by defining a user and password. See: http://deployingradius.com/documents/configuration/pap.html When 2.0 is released, defining a username & password will cause the following authentication methods to work: * PAP * CHAP * MS-CHAP * Digest * EAP-MD5 * EAP-MSCHAPv2 * Cisco LEAP * PEAP-MSCHAPv2 * PEAP-GTC * EAP-TTLS with * PAP * CHAP * MS-CHAP * EAP-MD5 * EAP-MSCHAPv2 Try *that* with any other program: "I added one line in a configuration file, and VOIP works, WiFi works, dial-up works, PPPoE works, VPN's work, for Apple, Windows, and Linux". No fighting, no fuss. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Perhaps you need to return some SIP attributes. Ivan Kalik Kalik Informatika ISP Dana 18/7/2007, "FreeRadius-ML" <freeradius@zap2link.com> piše:
Hi Alan,
Ok, I managed to solve the dual request thingy, apparently that was caused by a config on the OpenSER server. All requests now are coming out as:
rad_recv: Access-Request packet from host 192.168.2.80:34908, id=213, length=232 User-Name = "101@openser.org" Digest-Attributes = 0x0a05313031 Digest-Attributes = 0x010d6f70656e7365722e6f7267 Digest-Attributes = 0x022a34363961623634663863363039653664303632303135363461336237666137663633383433346462 Digest-Attributes = 0x04127369703a3139322e3136382e322e3830 Digest-Attributes = 0x030a5245474953544552 Digest-Attributes = 0x050661757468 Digest-Attributes = 0x090a3030303031303636 Digest-Attributes = 0x081237323633376361643532353930373938 Digest-Response = "408602140746b6fab2c70881242f7513" Service-Type = IAPP-Register X-Ascend-PW-Lifetime = 0x313031 NAS-Port = 5060 NAS-IP-Address = 192.168.2.80 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 831 modcall[authorize]: module "preprocess" returns ok for request 831 radius_xlat: '/usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070716' rlm_detail: /usr/local/freeradius/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070716 modcall[authorize]: module "auth_log" returns ok for request 831 rlm_digest: Adding Auth-Type = DIGEST modcall[authorize]: module "digest" returns ok for request 831 users: Matched entry 101@openser.org at line 53 modcall[authorize]: module "files" returns ok for request 831 modcall: leaving group authorize (returns ok) for request 831 rad_check_password: Found Auth-Type DIGEST auth: type "digest" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 831 rlm_digest: Converting Digest-Attributes to something sane... Digest-User-Name = "101" Digest-Realm = "openser.org" Digest-Nonce = "469ab64f8c609e6d06201564a3b7fa7f638434db" Digest-URI = "sip:192.168.2.80" Digest-Method = "REGISTER" Digest-QOP = "auth" Digest-Nonce-Count = "00001066" Digest-CNonce = "72637cad52590798" A1 = 101:openser.org:101 A2 = REGISTER:sip:192.168.2.80 H(A1) = f195c177997cee336c919be9279c5703 H(A2) = 046d0643f281affab19fe62ffc848ab5 KD = f195c177997cee336c919be9279c5703:469ab64f8c609e6d06201564a3b7fa7f638434db:00001066:72637cad52590798:auth:046d0643f281affab19fe62ffc848ab5 EXPECTED 408602140746b6fab2c70881242f7513 RECEIVED 408602140746b6fab2c70881242f7513 modcall[authenticate]: module "digest" returns ok for request 831 modcall: leaving group authenticate (returns ok) for request 831 Login OK: [101@openser.org/<no User-Password attribute>] (from client 192.168.2.80 port 5060) Sending Access-Accept of id 213 to 192.168.2.80 port 34908 Finished request 831 Going to the next request Waking up in 6 seconds...
Which as much as I can tell, indicate that the digest authentication/authorization process had completed correctly, and our users had been successfully authed by the Radius Server. Currently, I have an issue indicating that the user is actually not registered on the OpenSER server, but i believe that is caused by something else. Unless you have some form of pointer tip here...
z2l
----- Original Message ----- From: "FreeRadius-ML" <freeradius@zap2link.com> To: "Alan DeKok" <aland@deployingradius.com> Cc: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Wednesday, July 18, 2007 11:26:38 AM (GMT+0200) Asia/Jerusalem Subject: Re: RLM_PERL Integration Issue
Hi Alan,
Ok, I did as you instructed, and I admit that I appear to be getting somewhere. The debug log now shows the following:
-------------------------------- SNIP ----------------------------------------- rad_recv: Access-Request packet from host 192.168.2.80:33365, id=47, length=192 User-Name = "101@openser.org" Digest-Attributes = 0x0a05313031 Digest-Attributes = 0x010d6f70656e7365722e6f7267 Digest-Attributes = 0x022a34363961613063323661386631313165393066336161303533353430393661323631336462343736 Digest-Attributes = 0x04127369703a3139322e3136382e322e3830 Digest-Attributes = 0x030a5245474953544552 Digest-Response = "3f66a7a38c9d6ff05d9d633063085a0c" Service-Type = IAPP-Register X-Ascend-PW-Lifetime = 0x313031 NAS-Port = 5060 NAS-IP-Address = 192.168.2.80 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 17 modcall[authorize]: module "preprocess" returns ok for request 17 radius_xlat: '/usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070716' rlm_detail: /usr/local/freeradius/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070716 modcall[authorize]: module "auth_log" returns ok for request 17 rlm_digest: Adding Auth-Type = DIGEST modcall[authorize]: module "digest" returns ok for request 17 users: Matched entry 101@openser.org at line 54 modcall[authorize]: module "files" returns ok for request 17 modcall: leaving group authorize (returns ok) for request 17 rad_check_password: Found Auth-Type DIGEST auth: type "digest" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 17 rlm_digest: Converting Digest-Attributes to something sane... Digest-User-Name = "101" Digest-Realm = "openser.org" Digest-Nonce = "469aa0c26a8f111e90f3aa05354096a2613db476" Digest-URI = "sip:192.168.2.80" Digest-Method = "REGISTER" A1 = 101:openser.org:101 A2 = REGISTER:sip:192.168.2.80 H(A1) = f195c177997cee336c919be9279c5703 H(A2) = 046d0643f281affab19fe62ffc848ab5 KD = f195c177997cee336c919be9279c5703:469aa0c26a8f111e90f3aa05354096a2613db476:046d0643f281affab19fe62ffc848ab5 EXPECTED 3f66a7a38c9d6ff05d9d633063085a0c RECEIVED 3f66a7a38c9d6ff05d9d633063085a0c modcall[authenticate]: module "digest" returns ok for request 17 modcall: leaving group authenticate (returns ok) for request 17 Login OK: [101@openser.org/<no User-Password attribute>] (from client openser-network port 5060) Sending Access-Accept of id 47 to 192.168.2.80 port 33365 Finished request 17 Going to the next request Waking up in 4 seconds... rad_recv: Access-Request packet from host 192.168.2.80:33366, id=48, length=67 User-Name = "101@192.168.2.80" X-Ascend-PPP-VJ-1172 = 0x73757370656e646564 Service-Type = Voice NAS-Port = 0 NAS-IP-Address = 192.168.2.80 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 18 modcall[authorize]: module "preprocess" returns ok for request 18 radius_xlat: '/usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070716' rlm_detail: /usr/local/freeradius/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070716 modcall[authorize]: module "auth_log" returns ok for request 18 modcall[authorize]: module "digest" returns noop for request 18 users: Matched entry 101@192.168.2.80 at line 53 modcall[authorize]: module "files" returns ok for request 18 modcall: leaving group authorize (returns ok) for request 18 auth: type Local auth: No User-Password or CHAP-Password attribute in the request auth: Failed to validate the user. Login incorrect: [101@192.168.2.80/<no User-Password attribute>] (from client openser-network port 0) Delaying request 18 for 1 seconds Finished request 18 Going to the next request Waking up in 4 seconds... -------------------------------- SNIP -----------------------------------------
If you were to examine the log, you would see that request number 17 is receiving the LOGIN OK, while request 18 is rejected. The silly part here is this, there is only a single IP Phone on the network, which is using a single OpenSER server. I'm kind'a struck with a silly question, where is the second request coming from?
Z2L
----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: freeradius@zap2link.com Cc: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Wednesday, July 18, 2007 11:24:19 AM (GMT+0200) Asia/Jerusalem Subject: Re: RLM_PERL Integration Issue
FreeRadius-ML wrote:
Now, I'm basically re-learning everything, as the world of OpenSER + FreeRadius is a little new to me, and sometimes frustrates me. The amount of documentation in the configuration files is great, but the lack of updated examples is somewhat annoying. Even Asterisk, which is one of the most undocumented environments in the world, has more configuration examples available.
The majority of FreeRADIUS installations put users & password into SQL or LDAP, and then don't touch it ever again. For them, the existing examples are mostly OK.
For *complex* scenarios, RADIUS quickly gets more complicated than DNS, DHCP, Web servers, and (I suspect) Asterisk. There just isn't enough space in the world to document every configuration that everyone needs.
In any case, lets go back to what we were discussing. If I understand you correctly, on the FreeRadius side, I only need to enable digest based authentication and authorization, define the user in the users file - and that should be working just fine?
Yes. The entire *point* of the default configuration is to have as many authentication protocols as possible work... just by defining a user and password. See:
http://deployingradius.com/documents/configuration/pap.html
When 2.0 is released, defining a username & password will cause the following authentication methods to work:
* PAP * CHAP * MS-CHAP * Digest * EAP-MD5 * EAP-MSCHAPv2 * Cisco LEAP * PEAP-MSCHAPv2 * PEAP-GTC * EAP-TTLS with * PAP * CHAP * MS-CHAP * EAP-MD5 * EAP-MSCHAPv2
Try *that* with any other program: "I added one line in a configuration file, and VOIP works, WiFi works, dial-up works, PPPoE works, VPN's work, for Apple, Windows, and Linux". No fighting, no fuss.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Ok, I should really kick myself in the head for this one. First off, I would like to thank you for your assistance, sorry for being a little bit of a pest. Here is what happened: 1. I compiled OpenSER 1.2.1 with TLS support, while the IP phones that I used don't support TLS, this apparently caused various authorization issues. 2. I didn't edit the ACC module Makefile, which cause half of the configuration example not to work, which needs to be better documented. So, now I have the stations registering and authentication via Radius Digest to my OpenSER, which is good. Now, it's time to start thinking about the rlm_perl thingy ;-) Cheers, Z2L ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: freeradius@zap2link.com Cc: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Wednesday, July 18, 2007 11:24:19 AM (GMT+0200) Asia/Jerusalem Subject: Re: RLM_PERL Integration Issue FreeRadius-ML wrote:
Now, I'm basically re-learning everything, as the world of OpenSER + FreeRadius is a little new to me, and sometimes frustrates me. The amount of documentation in the configuration files is great, but the lack of updated examples is somewhat annoying. Even Asterisk, which is one of the most undocumented environments in the world, has more configuration examples available.
The majority of FreeRADIUS installations put users & password into SQL or LDAP, and then don't touch it ever again. For them, the existing examples are mostly OK. For *complex* scenarios, RADIUS quickly gets more complicated than DNS, DHCP, Web servers, and (I suspect) Asterisk. There just isn't enough space in the world to document every configuration that everyone needs.
In any case, lets go back to what we were discussing. If I understand you correctly, on the FreeRadius side, I only need to enable digest based authentication and authorization, define the user in the users file - and that should be working just fine?
Yes. The entire *point* of the default configuration is to have as many authentication protocols as possible work... just by defining a user and password. See: http://deployingradius.com/documents/configuration/pap.html When 2.0 is released, defining a username & password will cause the following authentication methods to work: * PAP * CHAP * MS-CHAP * Digest * EAP-MD5 * EAP-MSCHAPv2 * Cisco LEAP * PEAP-MSCHAPv2 * PEAP-GTC * EAP-TTLS with * PAP * CHAP * MS-CHAP * EAP-MD5 * EAP-MSCHAPv2 Try *that* with any other program: "I added one line in a configuration file, and VOIP works, WiFi works, dial-up works, PPPoE works, VPN's work, for Apple, Windows, and Linux". No fighting, no fuss. Alan DeKok.
participants (4)
-
Alan DeKok -
FreeRadius-ML -
Peter Nixon -
tnt@kalik.co.yu