Hi All, I've been tinkering with rlm_perl for a few days now, and found it to be fairly simple and straight forward. However, there is something that I'm a little unsure about it's possibility, so I would like to address the list about it. My aim is to have my rlm_perl script connect to a platform of mine, via a proprietary socket protocol. I've noticed that the rlm_perl example is just made of functions, without a main program. My question is this, if I include a main program loop, will that be executed upon the loading of the rlm_perl module, and the execution of the functions by FreeRadius will be performed in accordance to the main program loop? For example, I will open a socket in the main loop, make sure it stays open, and the various functions will utilize the socket that was opened in the main loop - is that possible, or am I misunderstanding something here? Regards, Z2L
Hello, first you have to check if your perl is thread safe. perl -V | grep THREAD will show. And based on that info you can have 2 choices: 1) perl threads present In this case you should use special subroutine called CLONE and initialize socket here. This sub is called when rlm_perl is loaded from freeradius and new threads are created regarding the settings in your perl section. So in-fact doing it in this way you will have socket per thread. 2) perl without threads In this case you should put your socket initialization code inside the main body of your script. Best Regards, Boian Jordanov SNE Orbitel - Next Generation Telecom tel. +359 2 4004 723 tel. +359 2 4004 002 On Jul 24, 2007, at 10:17 AM, FreeRadius-ML wrote:
Hi All,
I've been tinkering with rlm_perl for a few days now, and found it to be fairly simple and straight forward. However, there is something that I'm a little unsure about it's possibility, so I would like to address the list about it.
My aim is to have my rlm_perl script connect to a platform of mine, via a proprietary socket protocol. I've noticed that the rlm_perl example is just made of functions, without a main program. My question is this, if I include a main program loop, will that be executed upon the loading of the rlm_perl module, and the execution of the functions by FreeRadius will be performed in accordance to the main program loop? For example, I will open a socket in the main loop, make sure it stays open, and the various functions will utilize the socket that was opened in the main loop - is that possible, or am I misunderstanding something here?
Regards, Z2L - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ users.html
Thanks, that helps a bunch. Another question, may be non related. Anyone has an idea how does OpenSER and FreeRadius calculate the Digest response for rlm_digest? According to the output of my rlm_perl RAD_REQUEST, I'm getting the following request from the OpenSER server: rlm_perl: RAD_REQUEST: Client-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: Digest-Response = 80d23e66bd4d667eb445c89b74ff7a6b rlm_perl: RAD_REQUEST: User-Name = 101@192.168.2.80 rlm_perl: RAD_REQUEST: Service-Type = IAPP-Register rlm_perl: RAD_REQUEST: NAS-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: NAS-Port = 5060 rlm_perl: RAD_REQUEST: Sip-Uri-User = 101 rlm_perl: RAD_REQUEST: Digest-Attributes = ARRAY(0x84e7a90) rlm_perl: Added pair Auth-Type = perl If I understand correctly, I need to calculate the digest response, according to the information I hold in my AAA database, which should match the Digest-Response request. My question is, what is the actual string format that is required for the calculation of the Digest-Response? Regards, Z2L ----- Original Message ----- From: "Boian Jordanov" <bjordanov@orbitel.bg> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Cc: "Boian Jordanov" <bjordanov@orbitel.bg> Sent: Tuesday, July 24, 2007 11:06:09 AM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question Hello, first you have to check if your perl is thread safe. perl -V | grep THREAD will show. And based on that info you can have 2 choices: 1) perl threads present In this case you should use special subroutine called CLONE and initialize socket here. This sub is called when rlm_perl is loaded from freeradius and new threads are created regarding the settings in your perl section. So in-fact doing it in this way you will have socket per thread. 2) perl without threads In this case you should put your socket initialization code inside the main body of your script. Best Regards, Boian Jordanov SNE Orbitel - Next Generation Telecom tel. +359 2 4004 723 tel. +359 2 4004 002 On Jul 24, 2007, at 10:17 AM, FreeRadius-ML wrote:
Hi All,
I've been tinkering with rlm_perl for a few days now, and found it to be fairly simple and straight forward. However, there is something that I'm a little unsure about it's possibility, so I would like to address the list about it.
My aim is to have my rlm_perl script connect to a platform of mine, via a proprietary socket protocol. I've noticed that the rlm_perl example is just made of functions, without a main program. My question is this, if I include a main program loop, will that be executed upon the loading of the rlm_perl module, and the execution of the functions by FreeRadius will be performed in accordance to the main program loop? For example, I will open a socket in the main loop, make sure it stays open, and the various functions will utilize the socket that was opened in the main loop - is that possible, or am I misunderstanding something here?
Regards, Z2L - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ users.html
On Tue 24 Jul 2007, FreeRadius-ML wrote:
Thanks, that helps a bunch.
Another question, may be non related. Anyone has an idea how does OpenSER and FreeRadius calculate the Digest response for rlm_digest?
According to the output of my rlm_perl RAD_REQUEST, I'm getting the following request from the OpenSER server:
rlm_perl: RAD_REQUEST: Client-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: Digest-Response = 80d23e66bd4d667eb445c89b74ff7a6b rlm_perl: RAD_REQUEST: User-Name = 101@192.168.2.80 rlm_perl: RAD_REQUEST: Service-Type = IAPP-Register rlm_perl: RAD_REQUEST: NAS-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: NAS-Port = 5060 rlm_perl: RAD_REQUEST: Sip-Uri-User = 101 rlm_perl: RAD_REQUEST: Digest-Attributes = ARRAY(0x84e7a90) rlm_perl: Added pair Auth-Type = perl
If I understand correctly, I need to calculate the digest response, according to the information I hold in my AAA database, which should match the Digest-Response request. My question is, what is the actual string format that is required for the calculation of the Digest-Response?
Read RFC 2617 -- Peter Nixon http://peternixon.net/
Hi Peter, Well, according to the RFC, the string should be: username:realm:password and then into the md5sum. Now, according to my logs, I can see the following: Packet-Type = Access-Request Thu Jul 19 09:37:23 2007 User-Name = "101@192.168.2.80" Digest-Attributes = 0x0a05313031 Digest-Attributes = 0x010e3139322e3136382e322e3830 Digest-Attributes = 0x022a34363966313930646437336461386462323964356231306236373262646532633262623030353733 Digest-Attributes = 0x04127369703a3139322e3136382e322e3830 Digest-Attributes = 0x030a5245474953544552 Digest-Response = "80d23e66bd4d667eb445c89b74ff7a6b" Service-Type = IAPP-Register Sip-Uri-User = "101" NAS-Port = 5060 NAS-IP-Address = 192.168.2.80 Client-IP-Address = 192.168.2.80 Now, the password for that user is 101. So, I did the following: echo '101@192.168.2.80:192.168.2.80:101' | md5sum, which generated the following output: ec6cec8f0b5904ba56401b1e305638b5. Now, examining the log file shows that a few minutes before that, the Access-Request looks like this: Packet-Type = Access-Request Thu Jul 19 09:29:54 2007 User-Name = "101@192.168.2.80" Digest-Attributes = 0x0a05313031 Digest-Attributes = 0x010e3139322e3136382e322e3830 Digest-Attributes = 0x022a34363966313734623339623735663735363137326635613334646135666437393766353563353632 Digest-Attributes = 0x04127369703a3139322e3136382e322e3830 Digest-Attributes = 0x030a5245474953544552 Digest-Response = "a15ff7de436bada1093be663290f8ad8" Service-Type = IAPP-Register Sip-Uri-User = "101" NAS-Port = 5060 NAS-IP-Address = 192.168.2.80 Client-IP-Address = 192.168.2.80 As you can see, the Digest here is different, so I'm surely missing something here. Regards, Z2L ----- Original Message ----- From: "Peter Nixon" <listuser@peternixon.net> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, July 24, 2007 11:30:25 AM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question On Tue 24 Jul 2007, FreeRadius-ML wrote:
Thanks, that helps a bunch.
Another question, may be non related. Anyone has an idea how does OpenSER and FreeRadius calculate the Digest response for rlm_digest?
According to the output of my rlm_perl RAD_REQUEST, I'm getting the following request from the OpenSER server:
rlm_perl: RAD_REQUEST: Client-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: Digest-Response = 80d23e66bd4d667eb445c89b74ff7a6b rlm_perl: RAD_REQUEST: User-Name = 101@192.168.2.80 rlm_perl: RAD_REQUEST: Service-Type = IAPP-Register rlm_perl: RAD_REQUEST: NAS-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: NAS-Port = 5060 rlm_perl: RAD_REQUEST: Sip-Uri-User = 101 rlm_perl: RAD_REQUEST: Digest-Attributes = ARRAY(0x84e7a90) rlm_perl: Added pair Auth-Type = perl
If I understand correctly, I need to calculate the digest response, according to the information I hold in my AAA database, which should match the Digest-Response request. My question is, what is the actual string format that is required for the calculation of the Digest-Response?
Read RFC 2617 -- Peter Nixon http://peternixon.net/
Ok, I think I'm getting somewhere on this. After running wireshark and capturing the traffic, I actually realized that the Authentication/Authorization headers consists of a random hash that is identified by the nonce number. Following is an example: Authorization: Digest username="101", realm="192.168.2.80", algorithm=MD5, uri="sip:192.168.2.80", nonce="469f2996b4bb829917c6d5d7c3c50bed9da77682", response="1efb1851e1e96ce6855bf406735af4b6" Now, if I understand correctly, the digest will be calculated from the combination of the username, uri and nonce. Problem is, it would appear that I'm unable to access the nonce field from rlm_perl, unless, I'm missing something. Regards, Z2L ----- Original Message ----- From: "FreeRadius-ML" <freeradius@zap2link.com> To: "freeradius-users" <freeradius-users@lists.freeradius.org> Sent: Tuesday, July 24, 2007 11:43:19 AM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question Hi Peter, Well, according to the RFC, the string should be: username:realm:password and then into the md5sum. Now, according to my logs, I can see the following: Packet-Type = Access-Request Thu Jul 19 09:37:23 2007 User-Name = "101@192.168.2.80" Digest-Attributes = 0x0a05313031 Digest-Attributes = 0x010e3139322e3136382e322e3830 Digest-Attributes = 0x022a34363966313930646437336461386462323964356231306236373262646532633262623030353733 Digest-Attributes = 0x04127369703a3139322e3136382e322e3830 Digest-Attributes = 0x030a5245474953544552 Digest-Response = "80d23e66bd4d667eb445c89b74ff7a6b" Service-Type = IAPP-Register Sip-Uri-User = "101" NAS-Port = 5060 NAS-IP-Address = 192.168.2.80 Client-IP-Address = 192.168.2.80 Now, the password for that user is 101. So, I did the following: echo '101@192.168.2.80:192.168.2.80:101' | md5sum, which generated the following output: ec6cec8f0b5904ba56401b1e305638b5. Now, examining the log file shows that a few minutes before that, the Access-Request looks like this: Packet-Type = Access-Request Thu Jul 19 09:29:54 2007 User-Name = "101@192.168.2.80" Digest-Attributes = 0x0a05313031 Digest-Attributes = 0x010e3139322e3136382e322e3830 Digest-Attributes = 0x022a34363966313734623339623735663735363137326635613334646135666437393766353563353632 Digest-Attributes = 0x04127369703a3139322e3136382e322e3830 Digest-Attributes = 0x030a5245474953544552 Digest-Response = "a15ff7de436bada1093be663290f8ad8" Service-Type = IAPP-Register Sip-Uri-User = "101" NAS-Port = 5060 NAS-IP-Address = 192.168.2.80 Client-IP-Address = 192.168.2.80 As you can see, the Digest here is different, so I'm surely missing something here. Regards, Z2L ----- Original Message ----- From: "Peter Nixon" <listuser@peternixon.net> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, July 24, 2007 11:30:25 AM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question On Tue 24 Jul 2007, FreeRadius-ML wrote:
Thanks, that helps a bunch.
Another question, may be non related. Anyone has an idea how does OpenSER and FreeRadius calculate the Digest response for rlm_digest?
According to the output of my rlm_perl RAD_REQUEST, I'm getting the following request from the OpenSER server:
rlm_perl: RAD_REQUEST: Client-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: Digest-Response = 80d23e66bd4d667eb445c89b74ff7a6b rlm_perl: RAD_REQUEST: User-Name = 101@192.168.2.80 rlm_perl: RAD_REQUEST: Service-Type = IAPP-Register rlm_perl: RAD_REQUEST: NAS-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: NAS-Port = 5060 rlm_perl: RAD_REQUEST: Sip-Uri-User = 101 rlm_perl: RAD_REQUEST: Digest-Attributes = ARRAY(0x84e7a90) rlm_perl: Added pair Auth-Type = perl
If I understand correctly, I need to calculate the digest response, according to the information I hold in my AAA database, which should match the Digest-Response request. My question is, what is the actual string format that is required for the calculation of the Digest-Response?
Read RFC 2617 -- Peter Nixon http://peternixon.net/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Ok, It would appear that I'm a little silly, due to the way FreeRadius logs the information on the console. I've been debugging the information that I get, and I can see that the Digest-Attributes actually contain the information, in accordance to the following: The first Digest Attribute is the User-Name, The second Digest Attribute is the Realm, The third Digest Attribute is the nonce, The fourth Digest Attribute is the uri, The fifth Digest Attribute is the SIP-METHOD request. I didn't realize this in the begining, as it was all HEX dumped, so I couldn't see that I'm actually looking at the information. Now, my question is this, what is the formula to calculate the digest from all of the above information? I've tried backtracking the code, but ended up with a slight headache. If anyone has information, that would be highly appreciated. Regards, Z2L ----- Original Message ----- From: "FreeRadius-ML" <freeradius@zap2link.com> To: "freeradius-users" <freeradius-users@lists.freeradius.org> Sent: Tuesday, July 24, 2007 1:07:01 PM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question Ok, I think I'm getting somewhere on this. After running wireshark and capturing the traffic, I actually realized that the Authentication/Authorization headers consists of a random hash that is identified by the nonce number. Following is an example: Authorization: Digest username="101", realm="192.168.2.80", algorithm=MD5, uri="sip:192.168.2.80", nonce="469f2996b4bb829917c6d5d7c3c50bed9da77682", response="1efb1851e1e96ce6855bf406735af4b6" Now, if I understand correctly, the digest will be calculated from the combination of the username, uri and nonce. Problem is, it would appear that I'm unable to access the nonce field from rlm_perl, unless, I'm missing something. Regards, Z2L ----- Original Message ----- From: "FreeRadius-ML" <freeradius@zap2link.com> To: "freeradius-users" <freeradius-users@lists.freeradius.org> Sent: Tuesday, July 24, 2007 11:43:19 AM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question Hi Peter, Well, according to the RFC, the string should be: username:realm:password and then into the md5sum. Now, according to my logs, I can see the following: Packet-Type = Access-Request Thu Jul 19 09:37:23 2007 User-Name = "101@192.168.2.80" Digest-Attributes = 0x0a05313031 Digest-Attributes = 0x010e3139322e3136382e322e3830 Digest-Attributes = 0x022a34363966313930646437336461386462323964356231306236373262646532633262623030353733 Digest-Attributes = 0x04127369703a3139322e3136382e322e3830 Digest-Attributes = 0x030a5245474953544552 Digest-Response = "80d23e66bd4d667eb445c89b74ff7a6b" Service-Type = IAPP-Register Sip-Uri-User = "101" NAS-Port = 5060 NAS-IP-Address = 192.168.2.80 Client-IP-Address = 192.168.2.80 Now, the password for that user is 101. So, I did the following: echo '101@192.168.2.80:192.168.2.80:101' | md5sum, which generated the following output: ec6cec8f0b5904ba56401b1e305638b5. Now, examining the log file shows that a few minutes before that, the Access-Request looks like this: Packet-Type = Access-Request Thu Jul 19 09:29:54 2007 User-Name = "101@192.168.2.80" Digest-Attributes = 0x0a05313031 Digest-Attributes = 0x010e3139322e3136382e322e3830 Digest-Attributes = 0x022a34363966313734623339623735663735363137326635613334646135666437393766353563353632 Digest-Attributes = 0x04127369703a3139322e3136382e322e3830 Digest-Attributes = 0x030a5245474953544552 Digest-Response = "a15ff7de436bada1093be663290f8ad8" Service-Type = IAPP-Register Sip-Uri-User = "101" NAS-Port = 5060 NAS-IP-Address = 192.168.2.80 Client-IP-Address = 192.168.2.80 As you can see, the Digest here is different, so I'm surely missing something here. Regards, Z2L ----- Original Message ----- From: "Peter Nixon" <listuser@peternixon.net> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, July 24, 2007 11:30:25 AM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question On Tue 24 Jul 2007, FreeRadius-ML wrote:
Thanks, that helps a bunch.
Another question, may be non related. Anyone has an idea how does OpenSER and FreeRadius calculate the Digest response for rlm_digest?
According to the output of my rlm_perl RAD_REQUEST, I'm getting the following request from the OpenSER server:
rlm_perl: RAD_REQUEST: Client-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: Digest-Response = 80d23e66bd4d667eb445c89b74ff7a6b rlm_perl: RAD_REQUEST: User-Name = 101@192.168.2.80 rlm_perl: RAD_REQUEST: Service-Type = IAPP-Register rlm_perl: RAD_REQUEST: NAS-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: NAS-Port = 5060 rlm_perl: RAD_REQUEST: Sip-Uri-User = 101 rlm_perl: RAD_REQUEST: Digest-Attributes = ARRAY(0x84e7a90) rlm_perl: Added pair Auth-Type = perl
If I understand correctly, I need to calculate the digest response, according to the information I hold in my AAA database, which should match the Digest-Response request. My question is, what is the actual string format that is required for the calculation of the Digest-Response?
Read RFC 2617 -- Peter Nixon http://peternixon.net/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Tue, 2007-07-24 at 13:54 +0300, FreeRadius-ML wrote:
Ok,
It would appear that I'm a little silly, due to the way FreeRadius logs the information on the console. I've been debugging the information that I get, and I can see that the Digest-Attributes actually contain the information, in accordance to the following:
The first Digest Attribute is the User-Name, The second Digest Attribute is the Realm, The third Digest Attribute is the nonce, The fourth Digest Attribute is the uri, The fifth Digest Attribute is the SIP-METHOD request.
I didn't realize this in the begining, as it was all HEX dumped, so I couldn't see that I'm actually looking at the information.
Now, my question is this, what is the formula to calculate the digest from all of the above information? I've tried backtracking the code, but ended up with a slight headache. If anyone has information, that would be highly appreciated.
The "formula" is to do this: authorize { preprocess digest files } authenticate { Auth-Type DIGEST { digest } } HA1="0x`echo -n user:example.com:foobar | md5sum | cut -d ' ' -f 1`" in users: foo Digest-HA1 := 0xd07911de2b6cfea295166b56e8cecfa2 or better yet: foo Cleartext-Password := "foobar" ...and FreeRadius should just work.
Regards, Z2L
----- Original Message ----- From: "FreeRadius-ML" <freeradius@zap2link.com> To: "freeradius-users" <freeradius-users@lists.freeradius.org> Sent: Tuesday, July 24, 2007 1:07:01 PM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question
Ok,
I think I'm getting somewhere on this. After running wireshark and capturing the traffic, I actually realized that the Authentication/Authorization headers consists of a random hash that is identified by the nonce number. Following is an example:
Authorization: Digest username="101", realm="192.168.2.80", algorithm=MD5, uri="sip:192.168.2.80", nonce="469f2996b4bb829917c6d5d7c3c50bed9da77682", response="1efb1851e1e96ce6855bf406735af4b6"
Now, if I understand correctly, the digest will be calculated from the combination of the username, uri and nonce. Problem is, it would appear that I'm unable to access the nonce field from rlm_perl, unless, I'm missing something.
Regards, Z2L
----- Original Message ----- From: "FreeRadius-ML" <freeradius@zap2link.com> To: "freeradius-users" <freeradius-users@lists.freeradius.org> Sent: Tuesday, July 24, 2007 11:43:19 AM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question
Hi Peter,
Well, according to the RFC, the string should be: username:realm:password and then into the md5sum.
Now, according to my logs, I can see the following:
Packet-Type = Access-Request Thu Jul 19 09:37:23 2007 User-Name = "101@192.168.2.80" Digest-Attributes = 0x0a05313031 Digest-Attributes = 0x010e3139322e3136382e322e3830 Digest-Attributes = 0x022a34363966313930646437336461386462323964356231306236373262646532633262623030353733 Digest-Attributes = 0x04127369703a3139322e3136382e322e3830 Digest-Attributes = 0x030a5245474953544552 Digest-Response = "80d23e66bd4d667eb445c89b74ff7a6b" Service-Type = IAPP-Register Sip-Uri-User = "101" NAS-Port = 5060 NAS-IP-Address = 192.168.2.80 Client-IP-Address = 192.168.2.80
Now, the password for that user is 101.
So, I did the following: echo '101@192.168.2.80:192.168.2.80:101' | md5sum, which generated the following output: ec6cec8f0b5904ba56401b1e305638b5.
Now, examining the log file shows that a few minutes before that, the Access-Request looks like this:
Packet-Type = Access-Request Thu Jul 19 09:29:54 2007 User-Name = "101@192.168.2.80" Digest-Attributes = 0x0a05313031 Digest-Attributes = 0x010e3139322e3136382e322e3830 Digest-Attributes = 0x022a34363966313734623339623735663735363137326635613334646135666437393766353563353632 Digest-Attributes = 0x04127369703a3139322e3136382e322e3830 Digest-Attributes = 0x030a5245474953544552 Digest-Response = "a15ff7de436bada1093be663290f8ad8" Service-Type = IAPP-Register Sip-Uri-User = "101" NAS-Port = 5060 NAS-IP-Address = 192.168.2.80 Client-IP-Address = 192.168.2.80
As you can see, the Digest here is different, so I'm surely missing something here.
Regards, Z2L
----- Original Message ----- From: "Peter Nixon" <listuser@peternixon.net> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, July 24, 2007 11:30:25 AM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question
On Tue 24 Jul 2007, FreeRadius-ML wrote:
Thanks, that helps a bunch.
Another question, may be non related. Anyone has an idea how does OpenSER and FreeRadius calculate the Digest response for rlm_digest?
According to the output of my rlm_perl RAD_REQUEST, I'm getting the following request from the OpenSER server:
rlm_perl: RAD_REQUEST: Client-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: Digest-Response = 80d23e66bd4d667eb445c89b74ff7a6b rlm_perl: RAD_REQUEST: User-Name = 101@192.168.2.80 rlm_perl: RAD_REQUEST: Service-Type = IAPP-Register rlm_perl: RAD_REQUEST: NAS-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: NAS-Port = 5060 rlm_perl: RAD_REQUEST: Sip-Uri-User = 101 rlm_perl: RAD_REQUEST: Digest-Attributes = ARRAY(0x84e7a90) rlm_perl: Added pair Auth-Type = perl
If I understand correctly, I need to calculate the digest response, according to the information I hold in my AAA database, which should match the Digest-Response request. My question is, what is the actual string format that is required for the calculation of the Digest-Response?
Read RFC 2617
Hi Phil, I would agree, however, it kind of negates the purpose of using rlm_perl, doesn't it? Z2L ----- Original Message ----- From: "Phil Mayers" <p.mayers@imperial.ac.uk> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, July 24, 2007 2:07:11 PM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question On Tue, 2007-07-24 at 13:54 +0300, FreeRadius-ML wrote:
Ok,
It would appear that I'm a little silly, due to the way FreeRadius logs the information on the console. I've been debugging the information that I get, and I can see that the Digest-Attributes actually contain the information, in accordance to the following:
The first Digest Attribute is the User-Name, The second Digest Attribute is the Realm, The third Digest Attribute is the nonce, The fourth Digest Attribute is the uri, The fifth Digest Attribute is the SIP-METHOD request.
I didn't realize this in the begining, as it was all HEX dumped, so I couldn't see that I'm actually looking at the information.
Now, my question is this, what is the formula to calculate the digest from all of the above information? I've tried backtracking the code, but ended up with a slight headache. If anyone has information, that would be highly appreciated.
The "formula" is to do this: authorize { preprocess digest files } authenticate { Auth-Type DIGEST { digest } } HA1="0x`echo -n user:example.com:foobar | md5sum | cut -d ' ' -f 1`" in users: foo Digest-HA1 := 0xd07911de2b6cfea295166b56e8cecfa2 or better yet: foo Cleartext-Password := "foobar" ...and FreeRadius should just work.
Regards, Z2L
----- Original Message ----- From: "FreeRadius-ML" <freeradius@zap2link.com> To: "freeradius-users" <freeradius-users@lists.freeradius.org> Sent: Tuesday, July 24, 2007 1:07:01 PM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question
Ok,
I think I'm getting somewhere on this. After running wireshark and capturing the traffic, I actually realized that the Authentication/Authorization headers consists of a random hash that is identified by the nonce number. Following is an example:
Authorization: Digest username="101", realm="192.168.2.80", algorithm=MD5, uri="sip:192.168.2.80", nonce="469f2996b4bb829917c6d5d7c3c50bed9da77682", response="1efb1851e1e96ce6855bf406735af4b6"
Now, if I understand correctly, the digest will be calculated from the combination of the username, uri and nonce. Problem is, it would appear that I'm unable to access the nonce field from rlm_perl, unless, I'm missing something.
Regards, Z2L
----- Original Message ----- From: "FreeRadius-ML" <freeradius@zap2link.com> To: "freeradius-users" <freeradius-users@lists.freeradius.org> Sent: Tuesday, July 24, 2007 11:43:19 AM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question
Hi Peter,
Well, according to the RFC, the string should be: username:realm:password and then into the md5sum.
Now, according to my logs, I can see the following:
Packet-Type = Access-Request Thu Jul 19 09:37:23 2007 User-Name = "101@192.168.2.80" Digest-Attributes = 0x0a05313031 Digest-Attributes = 0x010e3139322e3136382e322e3830 Digest-Attributes = 0x022a34363966313930646437336461386462323964356231306236373262646532633262623030353733 Digest-Attributes = 0x04127369703a3139322e3136382e322e3830 Digest-Attributes = 0x030a5245474953544552 Digest-Response = "80d23e66bd4d667eb445c89b74ff7a6b" Service-Type = IAPP-Register Sip-Uri-User = "101" NAS-Port = 5060 NAS-IP-Address = 192.168.2.80 Client-IP-Address = 192.168.2.80
Now, the password for that user is 101.
So, I did the following: echo '101@192.168.2.80:192.168.2.80:101' | md5sum, which generated the following output: ec6cec8f0b5904ba56401b1e305638b5.
Now, examining the log file shows that a few minutes before that, the Access-Request looks like this:
Packet-Type = Access-Request Thu Jul 19 09:29:54 2007 User-Name = "101@192.168.2.80" Digest-Attributes = 0x0a05313031 Digest-Attributes = 0x010e3139322e3136382e322e3830 Digest-Attributes = 0x022a34363966313734623339623735663735363137326635613334646135666437393766353563353632 Digest-Attributes = 0x04127369703a3139322e3136382e322e3830 Digest-Attributes = 0x030a5245474953544552 Digest-Response = "a15ff7de436bada1093be663290f8ad8" Service-Type = IAPP-Register Sip-Uri-User = "101" NAS-Port = 5060 NAS-IP-Address = 192.168.2.80 Client-IP-Address = 192.168.2.80
As you can see, the Digest here is different, so I'm surely missing something here.
Regards, Z2L
----- Original Message ----- From: "Peter Nixon" <listuser@peternixon.net> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, July 24, 2007 11:30:25 AM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question
On Tue 24 Jul 2007, FreeRadius-ML wrote:
Thanks, that helps a bunch.
Another question, may be non related. Anyone has an idea how does OpenSER and FreeRadius calculate the Digest response for rlm_digest?
According to the output of my rlm_perl RAD_REQUEST, I'm getting the following request from the OpenSER server:
rlm_perl: RAD_REQUEST: Client-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: Digest-Response = 80d23e66bd4d667eb445c89b74ff7a6b rlm_perl: RAD_REQUEST: User-Name = 101@192.168.2.80 rlm_perl: RAD_REQUEST: Service-Type = IAPP-Register rlm_perl: RAD_REQUEST: NAS-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: NAS-Port = 5060 rlm_perl: RAD_REQUEST: Sip-Uri-User = 101 rlm_perl: RAD_REQUEST: Digest-Attributes = ARRAY(0x84e7a90) rlm_perl: Added pair Auth-Type = perl
If I understand correctly, I need to calculate the digest response, according to the information I hold in my AAA database, which should match the Digest-Response request. My question is, what is the actual string format that is required for the calculation of the Digest-Response?
Read RFC 2617
FreeRadius-ML wrote:
Now, my question is this, what is the formula to calculate the digest from all of the above information? I've tried backtracking the code, but ended up with a slight headache. If anyone has information, that would be highly appreciated.
I don't understand. The "digest" module does all this. See the code. The "radiusd.conf" file has multiple references to "digest". One of which is: # See 'doc/rfc/draft-sterman-aaa-sip-00.txt' for details FreeRADIUS already implements digest authentication. Why would you re-implement it elsewhere? And if you're going to re-implement it elsewhere, why not just use the code in rlm_digest? Alan DeKok.
On Tue, 2007-07-24 at 11:43 +0300, FreeRadius-ML wrote:
Hi Peter,
Well, according to the RFC, the string should be: username:realm:password and then into the md5sum.
No, the digest response is: md5 ( concat ( md5 ( user:realm:passwd ) nonce:nc-val:cnonce:qop:md5(method:uri[:entity-body]) ) )
So, I did the following: echo '101@192.168.2.80:192.168.2.80:101' | md5sum, which generated the following output: ec6cec8f0b5904ba56401b1e305638b5.
*Even* if that were how it worked, you've md5'ed the "\n" that echo will echo. In any event, you're going about this totally wrong. FreeRadius has a digest auth module; you should be extracting the credentials from your database and letting FreeRadius do the auth algorithm.
Ok, That makes more sense, do you have an example I can look at? In any case, let me see if I understand the below: I see that we perform 3 MD5 sums, each time on a different concatenated string. The fields that I'm not recognizing are nc-val and entiry-body. Can you please add information about these, as I would like to get more information on this, as there may be a possibility that I would be required to calculate this externally. Regards, Z2L ----- Original Message ----- From: "Phil Mayers" <p.mayers@imperial.ac.uk> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, July 24, 2007 2:00:33 PM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question On Tue, 2007-07-24 at 11:43 +0300, FreeRadius-ML wrote:
Hi Peter,
Well, according to the RFC, the string should be: username:realm:password and then into the md5sum.
No, the digest response is: md5 ( concat ( md5 ( user:realm:passwd ) nonce:nc-val:cnonce:qop:md5(method:uri[:entity-body]) ) )
So, I did the following: echo '101@192.168.2.80:192.168.2.80:101' | md5sum, which generated the following output: ec6cec8f0b5904ba56401b1e305638b5.
*Even* if that were how it worked, you've md5'ed the "\n" that echo will echo. In any event, you're going about this totally wrong. FreeRadius has a digest auth module; you should be extracting the credentials from your database and letting FreeRadius do the auth algorithm. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Ok, I think there is a misunderstanding here. Here's my target: OpenSER -> FreeRadius -- rlm_perl --> TCP Server Now, if I understand correctly, in order to validate that a SIP register coming in from the OpenSER is a valid username/password combo, I'm required to calculate the Digest on the TCP Server, and verify it against the digest that is calculated at the OpenSER, and that is being done using the AVP information that is passwed to the FreeRadius server, and the password that is stored at the remote TCP Server. Tell me if I have something backwards here? Z2L ----- Original Message ----- From: "FreeRadius-ML" <freeradius@zap2link.com> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, July 24, 2007 2:10:49 PM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question Ok, That makes more sense, do you have an example I can look at? In any case, let me see if I understand the below: I see that we perform 3 MD5 sums, each time on a different concatenated string. The fields that I'm not recognizing are nc-val and entiry-body. Can you please add information about these, as I would like to get more information on this, as there may be a possibility that I would be required to calculate this externally. Regards, Z2L ----- Original Message ----- From: "Phil Mayers" <p.mayers@imperial.ac.uk> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, July 24, 2007 2:00:33 PM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question On Tue, 2007-07-24 at 11:43 +0300, FreeRadius-ML wrote:
Hi Peter,
Well, according to the RFC, the string should be: username:realm:password and then into the md5sum.
No, the digest response is: md5 ( concat ( md5 ( user:realm:passwd ) nonce:nc-val:cnonce:qop:md5(method:uri[:entity-body]) ) )
So, I did the following: echo '101@192.168.2.80:192.168.2.80:101' | md5sum, which generated the following output: ec6cec8f0b5904ba56401b1e305638b5.
*Even* if that were how it worked, you've md5'ed the "\n" that echo will echo. In any event, you're going about this totally wrong. FreeRadius has a digest auth module; you should be extracting the credentials from your database and letting FreeRadius do the auth algorithm. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Tue, 2007-07-24 at 14:29 +0300, FreeRadius-ML wrote:
Ok,
I think there is a misunderstanding here. Here's my target:
OpenSER -> FreeRadius -- rlm_perl --> TCP Server
Now, if I understand correctly, in order to validate that a SIP register coming in from the OpenSER is a valid username/password combo, I'm required to calculate the Digest on the TCP Server, and verify it against the digest
No, I understand what you're trying to do. I'm telling you you're doing it the wrong way. You are welcome to disagree with my opinion, but there it is.
that is calculated at the OpenSER, and that is being done using the AVP information that is passwed to the FreeRadius server, and the password that is stored at the remote TCP Server.
Why can't you just have the TCP server pass the HA1 value back to the Radius server on request, and have the Radius server (which already has a proven, tested, high-performance digest implementation) do it? In any event - if you are adamant that the entire digest auth needs to take place inside the TCP server, then you will need to re-implement the digest authentication algorithm, and that's not a Radius question. You should re-read the RFC, and possibly look at the source for rlm_digest, but this isn't really an appropriate forum to learn how the digest algo works.
Ok, Now I understand you better, and I agree, that would constitute a much more scalable method. In that case, I return to my previous question, do you have a working rlm_perl script that does this, as I would like to see how this works. You'll have to excuse me, this is still a little new to me. Regards, Z2L ----- Original Message ----- From: "Phil Mayers" <p.mayers@imperial.ac.uk> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, July 24, 2007 4:49:23 PM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question On Tue, 2007-07-24 at 14:29 +0300, FreeRadius-ML wrote:
Ok,
I think there is a misunderstanding here. Here's my target:
OpenSER -> FreeRadius -- rlm_perl --> TCP Server
Now, if I understand correctly, in order to validate that a SIP register coming in from the OpenSER is a valid username/password combo, I'm required to calculate the Digest on the TCP Server, and verify it against the digest
No, I understand what you're trying to do. I'm telling you you're doing it the wrong way. You are welcome to disagree with my opinion, but there it is.
that is calculated at the OpenSER, and that is being done using the AVP information that is passwed to the FreeRadius server, and the password that is stored at the remote TCP Server.
Why can't you just have the TCP server pass the HA1 value back to the Radius server on request, and have the Radius server (which already has a proven, tested, high-performance digest implementation) do it? In any event - if you are adamant that the entire digest auth needs to take place inside the TCP server, then you will need to re-implement the digest authentication algorithm, and that's not a Radius question. You should re-read the RFC, and possibly look at the source for rlm_digest, but this isn't really an appropriate forum to learn how the digest algo works. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
FreeRadius-ML wrote:
Now I understand you better, and I agree, that would constitute a much more scalable method. In that case, I return to my previous question, do you have a working rlm_perl script that does this, as I would like to see how this works.
If you can write Perl code to get the clear-text password from the TCP server, then it's trivial. 1) get the password from the TCP server 2) $RAD_CHECK{User-Password} = "password" The whole *point* of the server design is to make everything as trivial as possible. As I've said before, tell the server what the clear text password is, and the server will figure out the rest. Re-implementing any authentication protocol that is already in FreeRADIUS is pointless and a waste of time. Alan DeKok.
Hi Alan, Yes, that was the initial idea. However, $RAD_CHECK{User-Password}, at least according to my log file doesn't exist: rad_recv: Access-Request packet from host 192.168.2.80:36905, id=35, length=194 User-Name = "101@192.168.2.80" Digest-Attributes = 0x0a05313031 Digest-Attributes = 0x010e3139322e3136382e322e3830 Digest-Attributes = 0x022a34363966346236616264653232346338613638653136613561373935323739366466303763633861 Digest-Attributes = 0x04127369703a3139322e3136382e322e3830 Digest-Attributes = 0x030a5245474953544552 Digest-Response = "08c1ee69ba91e6c3ef604a6173e2dfa2" Service-Type = IAPP-Register Sip-Uri-User = "101" NAS-Port = 5060 NAS-IP-Address = 192.168.2.80 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 3 modcall[authorize]: module "preprocess" returns ok for request 3 radius_xlat: '/usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070719' 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-20070719 modcall[authorize]: module "auth_log" returns ok for request 3 users: Matched entry DEFAULT at line 51 modcall[authorize]: module "files" returns ok for request 3 modcall[authorize]: module "digest" returns ok for request 3 perl_pool: item 0x94fefb0 asigned new request. Handled so far: 1 found interpetator at address 0x94fefb0 rlm_perl: RAD_REQUEST: Client-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: Digest-Response = 08c1ee69ba91e6c3ef604a6173e2dfa2 rlm_perl: RAD_REQUEST: User-Name = 101@192.168.2.80 rlm_perl: RAD_REQUEST: Service-Type = IAPP-Register rlm_perl: RAD_REQUEST: NAS-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: NAS-Port = 5060 rlm_perl: RAD_REQUEST: Sip-Uri-User = 101 rlm_perl: RAD_REQUEST: Digest-Attributes = ARRAY(0x95bd5c0) rlm_perl: RAD_CHECK: Auth-Type = perl rlm_perl: Added pair Auth-Type = perl perl_pool total/active/spare [32/0/32] Unreserve perl at address 0x94fefb0 modcall[authorize]: module "perl" returns ok for request 3 modcall: leaving group authorize (returns ok) for request 3 rad_check_password: Found Auth-Type Perl auth: type "perl" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 3 perl_pool: item 0x95fede0 asigned new request. Handled so far: 1 found interpetator at address 0x95fede0 rlm_perl: RAD_REQUEST: Client-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: Digest-Response = 08c1ee69ba91e6c3ef604a6173e2dfa2 rlm_perl: RAD_REQUEST: User-Name = 101@192.168.2.80 rlm_perl: RAD_REQUEST: Service-Type = IAPP-Register rlm_perl: RAD_REQUEST: NAS-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: NAS-Port = 5060 rlm_perl: RAD_REQUEST: Sip-Uri-User = 101 rlm_perl: RAD_REQUEST: Digest-Attributes = ARRAY(0x96bd3f0) rlm_perl: RAD_CHECK: Auth-Type = perl rlm_perl: Added pair Auth-Type = perl perl_pool total/active/spare [32/0/32] Unreserve perl at address 0x95fede0 modcall[authenticate]: module "perl" returns ok for request 3 modcall: leaving group authenticate (returns ok) for request 3 Login OK: [101@192.168.2.80/<no User-Password attribute>] (from client 192.168.2.80 port 5060) Sending Access-Accept of id 35 to 192.168.2.80 port 36905 Finished request 3 Going to the next request Aparently, the only thing that RAD_CHECK contains has inside is Auth-Type. Regards, Z2L ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, July 24, 2007 5:47:36 PM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question FreeRadius-ML wrote:
Now I understand you better, and I agree, that would constitute a much more scalable method. In that case, I return to my previous question, do you have a working rlm_perl script that does this, as I would like to see how this works.
If you can write Perl code to get the clear-text password from the TCP server, then it's trivial. 1) get the password from the TCP server 2) $RAD_CHECK{User-Password} = "password" The whole *point* of the server design is to make everything as trivial as possible. As I've said before, tell the server what the clear text password is, and the server will figure out the rest. Re-implementing any authentication protocol that is already in FreeRADIUS is pointless and a waste of time. Alan DeKok.
FreeRadius-ML wrote:
Yes, that was the initial idea. However, $RAD_CHECK{User-Password}, at least according to my log file doesn't exist:
I don't understand. Did you update the Perl script to set that? Or are you just looking at the debug output, and expecting to see $RAD_CHECK{User-Password} somehow magically appear? So... what Perl script are you using? Post it.
rlm_perl: RAD_CHECK: Auth-Type = perl
I'm about ready to stop answering your messages. Every single thing in the documentation, and what you've been told here has said DO NOT SET AUTH-TYPE. Yet... there you go setting it. Honestly, I just don't understand why you're so insistent on ignoring the advice you're given here. Damn near all of the problems you're running into are because you're working hard to break things. If you're not going to follow the advice given here, stop asking questions. Alan DeKok.
Hi Alan, Of course I updated the PERL script. I simply modified the debug function to be: sub log_request_attributes { # This shouldn't be done in production environments! # This is only meant for debugging! for (keys %RAD_REQUEST) { &radiusd::radlog(1, "RAD_REQUEST: $_ = $RAD_REQUEST{$_}"); } for (keys %RAD_CHECK) { &radiusd::radlog(1, "RAD_CHECK: $_ = $RAD_CHECK{$_}"); } for (keys %RAD_REPLY) { &radiusd::radlog(1, "RAD_REPLY: $_ = $RAD_REPLY{$_}"); } } I hadn't set Auth-Type in radiusd.conf, according to references I've recieved, the only Auth-Type directive I've added in the users.conf file. Just for checking, I've removed the directive from the users.conf file, and now I'm getting the following in the debug: rad_recv: Access-Request packet from host 192.168.2.80:43824, id=122, length=194 User-Name = "101@192.168.2.80" Digest-Attributes = 0x0a05313031 Digest-Attributes = 0x010e3139322e3136382e322e3830 Digest-Attributes = 0x022a34366130353033393832656466366336633065373730373531633335383536346266646632346562 Digest-Attributes = 0x04127369703a3139322e3136382e322e3830 Digest-Attributes = 0x030a5245474953544552 Digest-Response = "897c22eebf92577a23d3d2e91a360d67" Service-Type = IAPP-Register Sip-Uri-User = "101" NAS-Port = 5060 NAS-IP-Address = 192.168.2.80 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 8 modcall[authorize]: module "preprocess" returns ok for request 8 radius_xlat: '/usr/local/freeradius/var/log/radius/radacct/192.168.2.80/auth-detail-20070720' 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-20070720 modcall[authorize]: module "auth_log" returns ok for request 8 rlm_digest: Adding Auth-Type = DIGEST modcall[authorize]: module "digest" returns ok for request 8 perl_pool: item 0xa587328 asigned new request. Handled so far: 1 found interpetator at address 0xa587328 rlm_perl: RAD_REQUEST: Client-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: Digest-Response = 897c22eebf92577a23d3d2e91a360d67 rlm_perl: RAD_REQUEST: User-Name = 101@192.168.2.80 rlm_perl: RAD_REQUEST: Service-Type = IAPP-Register rlm_perl: RAD_REQUEST: NAS-IP-Address = 192.168.2.80 rlm_perl: RAD_REQUEST: NAS-Port = 5060 rlm_perl: RAD_REQUEST: Sip-Uri-User = 101 rlm_perl: RAD_REQUEST: Digest-Attributes = ARRAY(0xa64592c) perl_pool total/active/spare [32/0/32] Unreserve perl at address 0xa587328 modcall[authorize]: module "perl" returns ok for request 8 modcall: leaving group authorize (returns ok) for request 8 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 192.168.2.80 port 5060) Delaying request 8 for 1 seconds Finished request 8 Going to the next request Cleaning up request 7 ID 121 with timestamp 46a03e12 As a reference, I'm uploading my configuration files to pastebin.com, according to the following: radiusd.conf - http://pastebin.com/f31b5226b rlm_perl.pl - http://pastebin.com/f15f198ca users.conf - Everything is commented in, which means basically an empty file Alan, i'm asking these questions as I want to understand the possibilities and the various options that exist. I'm fully aware of the configuration of Digest and how to make digest work with a MySQL backend, that worked without a problem and I was able to understand how to start playing around with it to make do what I want it to do. My only problem here is that I'm now playing around with rlm_perl, which appears to be a bit more complex in the way it does things. For example, I've looked into the documentation, I hadn't seen any document explaining the information transfer between the rlm_perl script and the digest mechanism. The documentation describes how to work with rlm_perl, how to write your own script and so on. But that little piece of information is missing from it. The general information in the documentation is much better than in most OSS projects I know, however, the lack of examples and the fact that most people tend to work with some form of SQL/LDAP backend, makes any other usage beyond that a bit more complicated for the novice FreeRadius user. Alan, just to make something clear, I think FreeRadius is a wonderful tool. I've used it in conjunction with GnuGK to build a multi-million minute H323 routing switch back in 2003, which is still working till today (switching over 25 million minutes a month). I've used in conjunction with Cisco Access Servers to create various Dial-IN PPP access routers, and I've used it as a backend for Cisco L2TP/PPTP services, which were all working off of MySQL, and work to this day - in other words, I know my way around FreeRadius fairly well. The first time I ran into a situation I actually needed to talk to someone on the list is now. I'm currently in the process of writing a document explaining my findings, and maybe also help others use rlm_perl, but you have to understand that while I may seem a little nagging, it is purely due to my Israeli nature that tends to get the better of me - and my general desire to understand what I'm doing. Regards, Z2L ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, July 24, 2007 6:22:27 PM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question FreeRadius-ML wrote:
Yes, that was the initial idea. However, $RAD_CHECK{User-Password}, at least according to my log file doesn't exist:
I don't understand. Did you update the Perl script to set that? Or are you just looking at the debug output, and expecting to see $RAD_CHECK{User-Password} somehow magically appear? So... what Perl script are you using? Post it.
rlm_perl: RAD_CHECK: Auth-Type = perl
I'm about ready to stop answering your messages. Every single thing in the documentation, and what you've been told here has said DO NOT SET AUTH-TYPE. Yet... there you go setting it. Honestly, I just don't understand why you're so insistent on ignoring the advice you're given here. Damn near all of the problems you're running into are because you're working hard to break things. If you're not going to follow the advice given here, stop asking questions. Alan DeKok.
Hi, you dont have perl enabled in the authorise section of your config...you dont have digest enabled in your authorise or authenticate sections either. what are you trying to acheive? alan
Ok, What I'm trying to do is have FreeRadius perform its AAA functions again a PERL based backend, which reads the user information from a proprietary system - via a TCP interface. The authorization section and the authenticate section both have PERL enabled in them. (I removed the remarks for easier reading) - the first digest is commented, but right after perl there is another one. ---------- SNIP ------------ authorize { preprocess auth_log # attr_filter # chap # mschap # digest # IPASS # suffix # ntdomain # eap # files digest perl # sql # etc_smbpasswd # ldap # daily # checkval # pap } --------------------------- You are correct in regards to the authentication section (see below), I missed that one: --------- SNIP ------------ authenticate { # Auth-Type PAP { # # pap # # } # Auth-Type CHAP { # # chap # # } # Auth-Type MS-CHAP { # # mschap # # } # digest # pam unix # Auth-Type LDAP { # # ldap # # } # eap perl } --------------------------- I may be going about it all wrong, which I'm not ruling out. If you have something specific to point me at, please do. Regards, Z2L ----- Original Message ----- From: "A L M Buxey" <A.L.M.Buxey@lboro.ac.uk> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Wednesday, July 25, 2007 2:12:55 PM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question Hi, you dont have perl enabled in the authorise section of your config...you dont have digest enabled in your authorise or authenticate sections either. what are you trying to acheive? alan
Several people have already told you this, but I am going to have another go at it. You want to do Digest Authentication. That great. FreeRADIUS knows how to do it. All you have to do is supply the Cleartext-Password. You tell us that you have some propriatary system which holds your passwords that you need to access over a TCP socket. Great. Feel free to do so. Basically you need to: a) Have the digest module enabled in the _authorize_ AND _authenticate_ sections of radiusd.conf b) Get the password from your backend using perl and return it to FreeRADIUS in the _authorize_ section as: Cleartext-Password := "yoursupersecretpassword" This is ALL you should have to do! Do not do anything else! Please. Just dont! Cheers Peter On Wed 25 Jul 2007, FreeRadius-ML wrote:
Ok,
What I'm trying to do is have FreeRadius perform its AAA functions again a PERL based backend, which reads the user information from a proprietary system - via a TCP interface.
The authorization section and the authenticate section both have PERL enabled in them.
(I removed the remarks for easier reading) - the first digest is commented, but right after perl there is another one. ---------- SNIP ------------ authorize { preprocess auth_log # attr_filter # chap # mschap # digest # IPASS # suffix # ntdomain # eap # files digest perl # sql # etc_smbpasswd # ldap # daily # checkval # pap } --------------------------- You are correct in regards to the authentication section (see below), I missed that one: --------- SNIP ------------ authenticate { # Auth-Type PAP { # # pap # # } # Auth-Type CHAP { # # chap # # } # Auth-Type MS-CHAP { # # mschap # # } # digest # pam unix # Auth-Type LDAP { # # ldap # # } # eap perl } ---------------------------
I may be going about it all wrong, which I'm not ruling out. If you have something specific to point me at, please do.
Regards, Z2L ----- Original Message ----- From: "A L M Buxey" <A.L.M.Buxey@lboro.ac.uk> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Wednesday, July 25, 2007 2:12:55 PM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question
Hi,
you dont have perl enabled in the authorise section of your config...you dont have digest enabled in your authorise or authenticate sections either. what are you trying to acheive?
-- Peter Nixon http://peternixon.net/
Hi Peter, Thanks, that was the missing part for me - I think. Just let me verify that I got you correctly: 1. My OpenSER will send a request to FreeRadius including the full digest information. 2. Once the request in intercepted by FreeRadius, my rlm_perl will simply need to ask the TCP server for the password of the user. 3. Once that password had been retrieved, I'll simply set the RAD_REPLY{'Cleartext-ssword'} to the password that was retrieved from the TCP server. 4. Once the rlm_perl script returns with the OK setting, the rest will be handled by the digest module. Have I got it right this time? sorry for being a bit of a pain. Z2L ----- Original Message ----- From: "Peter Nixon" <listuser@peternixon.net> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Wednesday, July 25, 2007 5:05:02 PM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question Several people have already told you this, but I am going to have another go at it. You want to do Digest Authentication. That great. FreeRADIUS knows how to do it. All you have to do is supply the Cleartext-Password. You tell us that you have some propriatary system which holds your passwords that you need to access over a TCP socket. Great. Feel free to do so. Basically you need to: a) Have the digest module enabled in the _authorize_ AND _authenticate_ sections of radiusd.conf b) Get the password from your backend using perl and return it to FreeRADIUS in the _authorize_ section as: PaCleartext-ssword := "yoursupersecretpassword" This is ALL you should have to do! Do not do anything else! Please. Just dont! Cheers Peter On Wed 25 Jul 2007, FreeRadius-ML wrote:
Ok,
What I'm trying to do is have FreeRadius perform its AAA functions again a PERL based backend, which reads the user information from a proprietary system - via a TCP interface.
The authorization section and the authenticate section both have PERL enabled in them.
(I removed the remarks for easier reading) - the first digest is commented, but right after perl there is another one. ---------- SNIP ------------ authorize { preprocess auth_log # attr_filter # chap # mschap # digest # IPASS # suffix # ntdomain # eap # files digest perl # sql # etc_smbpasswd # ldap # daily # checkval # pap } --------------------------- You are correct in regards to the authentication section (see below), I missed that one: --------- SNIP ------------ authenticate { # Auth-Type PAP { # # pap # # } # Auth-Type CHAP { # # chap # # } # Auth-Type MS-CHAP { # # mschap # # } # digest # pam unix # Auth-Type LDAP { # # ldap # # } # eap perl } ---------------------------
I may be going about it all wrong, which I'm not ruling out. If you have something specific to point me at, please do.
Regards, Z2L ----- Original Message ----- From: "A L M Buxey" <A.L.M.Buxey@lboro.ac.uk> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Wednesday, July 25, 2007 2:12:55 PM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question
Hi,
you dont have perl enabled in the authorise section of your config...you dont have digest enabled in your authorise or authenticate sections either. what are you trying to acheive?
-- Peter Nixon http://peternixon.net/
On Wed 25 Jul 2007, FreeRadius-ML wrote:
Hi Peter,
Thanks, that was the missing part for me - I think. Just let me verify that I got you correctly:
1. My OpenSER will send a request to FreeRadius including the full digest information. 2. Once the request in intercepted by FreeRadius, my rlm_perl will simply need to ask the TCP server for the password of the user.
yes.
3. Once that password had been retrieved, I'll simply set the RAD_REPLY{'Cleartext-ssword'} to the password that was retrieved from the TCP server.
No. It needs to be RAD_CHECK{'Cleartext-Password'}
4. Once the rlm_perl script returns with the OK setting, the rest will be handled by the digest module.
Yes. Thats what we have been telling you :-)
Have I got it right this time? sorry for being a bit of a pain.
With the exception of Cleartext-Password being a CHECK item and not a REPLY item, yes, you are correct. -- Peter Nixon http://peternixon.net/
Thanks, that makes everything much clearer now :-) Cheers, Z2L ----- Original Message ----- From: "Peter Nixon" <listuser@peternixon.net> To: freeradius@zap2link.com, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Wednesday, July 25, 2007 6:17:14 PM (GMT+0200) Asia/Jerusalem Subject: Re: rml_perl question On Wed 25 Jul 2007, FreeRadius-ML wrote:
Hi Peter,
Thanks, that was the missing part for me - I think. Just let me verify that I got you correctly:
1. My OpenSER will send a request to FreeRadius including the full digest information. 2. Once the request in intercepted by FreeRadius, my rlm_perl will simply need to ask the TCP server for the password of the user.
yes.
3. Once that password had been retrieved, I'll simply set the RAD_REPLY{'Cleartext-ssword'} to the password that was retrieved from the TCP server.
No. It needs to be RAD_CHECK{'Cleartext-Password'}
4. Once the rlm_perl script returns with the OK setting, the rest will be handled by the digest module.
Yes. Thats what we have been telling you :-)
Have I got it right this time? sorry for being a bit of a pain.
With the exception of Cleartext-Password being a CHECK item and not a REPLY item, yes, you are correct. -- Peter Nixon http://peternixon.net/
FreeRadius-ML wrote:
Of course I updated the PERL script. I simply modified the debug function to be:
And you did NOT add $RAD_CHECK{Cleartext-Password} = "..." as you were instructed to do.
I hadn't set Auth-Type in radiusd.conf, according to references I've recieved, the only Auth-Type directive I've added in the users.conf file.
Which you were instructed to NOT do. ...
rlm_digest: Adding Auth-Type = DIGEST ... auth: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user
You did NOT configure the "digest" module in the "authenticate" section, as you were instructed to do.
Alan, i'm asking these questions as I want to understand the possibilities and the various options that exist.
No. If you wanted to understand, you would follow instructions, and observe that the instructions worked.
My only problem here is that I'm now playing around with rlm_perl, which appears to be a bit more complex in the way it does things.
No, it's not. You set the value of an attribute via the method you were instructed to use.. That's the *only* complex thing in rlm_perl.
For example, I've looked into the documentation, I hadn't seen any document explaining the information transfer between the rlm_perl script and the digest mechanism.
I explained this. You seem to have ignored it. You set the value of the attribute in rlm_perl as you were instructed. The server takes care of the rest.
The documentation describes how to work with rlm_perl, how to write your own script and so on. But that little piece of information is missing from it.
doc/aaa.txt explains it. I have told you on this list how it works.
The general information in the documentation is much better than in most OSS projects I know, however, the lack of examples and the fact that most people tend to work with some form of SQL/LDAP backend, makes any other usage beyond that a bit more complicated for the novice FreeRadius user.
You are making it difficult for yourself by not following the instructions on this list.
Alan, just to make something clear, I think FreeRadius is a wonderful tool. I've used it in conjunction with GnuGK to build a multi-million minute H323 routing switch back in 2003, which is still working till today (switching over 25 million minutes a month). I've used in conjunction with Cisco Access Servers to create various Dial-IN PPP access routers, and I've used it as a backend for Cisco L2TP/PPTP services, which were all working off of MySQL, and work to this day - in other words, I know my way around FreeRadius fairly well.
Then I don't understand why it's so difficult to get this working.
The first time I ran into a situation I actually needed to talk to someone on the list is now. I'm currently in the process of writing a document explaining my findings, and maybe also help others use rlm_perl, but you have to understand that while I may seem a little nagging, it is purely due to my Israeli nature that tends to get the better of me - and my general desire to understand what I'm doing.
I've seen that before. You think there's some secret magical complex sauce that makes it all work. There isn't. The explanation is simple, and you've been given it multiple times. Because you think there's some secret magic sauce, you find it impossible to believe the simple explanations. Therefore, you don't follow the instructions on this list, because they cannot possibly be correct. I have told you multiple times how to get this to work. It is abundantly clear that you have great difficulty following instructions. The Perl script you posted contains *zero* references to Cleartext-Password, despite the explicit instructions to set it. The radiusd.conf file will not do digest authentication, despite instructions here *and* in the comments in radiusd.conf saying how to get it to work. Good luck solving your problem. Alan DeKok.
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Boian Jordanov -
FreeRadius-ML -
Peter Nixon -
Phil Mayers