rml_perl question
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
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rml_perl question
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 = [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: [EMAIL PROTECTED], FreeRadius users mailing list freeradius-users@lists.freeradius.org Cc: Boian Jordanov [EMAIL PROTECTED] 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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 = [EMAIL PROTECTED] 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
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 = [EMAIL PROTECTED] 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 '[EMAIL PROTECTED]: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 = [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: [EMAIL PROTECTED], 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 = [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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 = [EMAIL PROTECTED] 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 '[EMAIL PROTECTED]: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 = [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: [EMAIL PROTECTED], 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 = [EMAIL PROTECTED] 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
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 '[EMAIL PROTECTED]: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
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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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 = [EMAIL PROTECTED]
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 '[EMAIL PROTECTED]: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 = [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
To: [EMAIL PROTECTED], 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
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 [EMAIL PROTECTED] 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 '[EMAIL PROTECTED]: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
Re: rml_perl question
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 [EMAIL PROTECTED]
To: [EMAIL PROTECTED], 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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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 = [EMAIL PROTECTED]
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 '[EMAIL PROTECTED]: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 = [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
To: [EMAIL PROTECTED], FreeRadius users mailing list
freeradius-users@lists.freeradius.org
Sent: Tuesday, July
Re: rml_perl question
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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rml_perl question
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 = [EMAIL PROTECTED]
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 = [EMAIL PROTECTED]
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 = [EMAIL PROTECTED]
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: [EMAIL PROTECTED]/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 [EMAIL PROTECTED]
To: [EMAIL PROTECTED], 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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RADIUS attributes: acctoutputoctects and acctinputoctect in mikrotik
Hi, Iam working with freeradius and mirkrotik routers since two years. However, I have never realized that the radius attributes acctoutputoctects and acctinputoctects are intechanged in mikrotik. Does anyone know ths mikrotik bug? SantiagoÉxitos, grandes clásicos y novedades. Un millón de canciones en MSN Music. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
multiple authorization modules
Hello, I am curious about the methodology for using one authorization module for one type of service and another for a different type of service. basically we have wireless and VPN that is being authorized and authenticated through our radius box. i would like to be able to control authorization to each of those independently though different ldap attributes. I currently have it working with one ldap module, so both service are authorized thru the same attribute i am using freeradius 1.1.6 Any thoughts? Joe - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rlm_sql bug in 64-bit architecture ?
Hi everyone : I've been searching for the possible causes of a problem, that appears when sqlcounter is enabled, and just in 64-bits plattforms (FreeBSD/Sparc64). The radius_xlat function performed by rlm_sql seems to not reading well some attributes like Expiration and always complains about Invalid Operator, not matter what operator is put [1]. Note the big difference between the responses obtained in the 64-bit and 32-bit arch, using radtest and running radiusd in debug mode: rlm_sql can't read neither the value nor the operator for Expiration attribute, despite the fact that in both cases, the database used is the same. (rlm_sql debug options enabled in rlm_sql.c). freeradius 1.1.6 / FreeBSD Sparc64 == radius_xlat: '[EMAIL PROTECTED]' rlm_sql (sql): [snip] radius_xlat: [snip] rlm_sql: check items User-Password := prueba Auth-Type := Local Simultaneous-Use := 1 Max-Daily-Session := 3600 Expiration INVALID-TOKEN Dec 31 1969 19:00:00 PET --- Notice this (where this value come from ?) rlm_sql: reply items Framed-Protocol = PPP Framed-IP-Address = 255.255.255.254 Framed-IP-Netmask = 255.255.255.255 Framed-MTU = 1500 Service-Type = Framed-User Idle-Timeout = 300 Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' rlm_sql (sql): No matching entry in the database for request from user [EMAIL PROTECTED] modcall[authorize]: module sql returns notfound for request 9 rlm_sqlcounter: Entering module authorize code rlm_sqlcounter: Could not find Check item value pair modcall[authorize]: module dailycounter returns noop for request 9 [snip] -- Got an Access-Reject response freeradius 1.1.6 / FreeBSD i386 === radius_xlat: '[EMAIL PROTECTED]' rlm_sql (sql): [snip] radius_xlat: [snip] rlm_sql: check items User-Password := prueba Auth-Type := Local Simultaneous-Use := 1 Max-Daily-Session := 3600 Expiration := Sep 24 2007 11:30:00 PET --- get the correct 'op' and 'value' rlm_sql: reply items Framed-Protocol = PPP Framed-IP-Address = 255.255.255.254 Framed-IP-Netmask = 255.255.255.255 Framed-MTU = 1500 Service-Type = Framed-User Idle-Timeout = 300 modcall[authorize]: module sql returns ok for request 0 rlm_sqlcounter: Entering module authorize code [snip] -- Got an Access-Accept response What could be going wrong with rlm_sql ? Is there any bug in freeradius code related to 64-bit architectures ? I'd appreciate any suggestion to solve this. Richard Cotrina [1]. http://archives.free.net.ph/message/20070517.165523.c7432a23.en.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RADIUS attributes: acctoutputoctects and acctinputoctect in mikrotik
I have RouterOSv2.9 and input is input and output is output. Ivan Kalik Kalik Informatika ISP Dana 24/7/2007, Santiago Balaguer García [EMAIL PROTECTED] piše: Hi, I am working with freeradius and mirkrotik routers since two years. However, I have never realized that the radius attributes acctoutputoctects and acctinputoctects are intechanged in mikrotik. Does anyone know ths mikrotik bug? SantiagoÉxitos, grandes clásicos y novedades. Un millón de canciones en MSN Music. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: multiple authorization modules
Nevermind, i figured it out. Joe Vieira wrote: Hello, I am curious about the methodology for using one authorization module for one type of service and another for a different type of service. basically we have wireless and VPN that is being authorized and authenticated through our radius box. i would like to be able to control authorization to each of those independently though different ldap attributes. I currently have it working with one ldap module, so both service are authorized thru the same attribute i am using freeradius 1.1.6 Any thoughts? Joe - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: TLS cant connect ldap+freeradius+novell
Hi Martin,
If you already do not have it working, here are the steps that got mine to work,
1) Login to Novell iManager and under Roles and Tasks - LDAP options
- View Ldap Servers - Click on server - Connections - make sure
SSL Certificate IP is the server cert and Client Certificate - Not Requested
2) Now if you click on Novell Certificate Access - Server
Certificates - Expand SSL Certificate IP , it shows that its signed
by Organizational CA
3) Click Novell Certificate Server - Configure Certificate Authority
- Click Certificates Tab - Select Organizational CA - Export and
follow steps and download the cert to a file say cert.pfx
4) Open cygwin (since i use edir on windoz) and do
openssl pkcs12 -in ~/Desktop/cert.pfx -nocerts -nodes -out
~/Desktop/edir_ca_key.pem
openssl pkcs12 -in ~/Desktop/cert.pfx -clcerts -nokeys -out
~/Desktop/edir_ca_cert.pem
cat ~/Desktop/edir_ca_cert.pem ~/Desktop/edir_ca_key.pem ~/Desktop/edir.pem
5) Copy edir.pem to the radius server under say /certs/edir/edir.pem
6) My module looks like:
#make sure the ip is the same ip as in the CN of the CA cert
ldap ldap1{
# edir
server = 192.168.1.40
port = 636
dictionary_mapping = ${raddbdir}/ldap.attrmap
basedn = o=engineering
identity = cn=admin,o=domain
password = *
password_attribute = nspmPassword
edir_account_policy_check = yes
filter = (cn=%{Stripped-User-Name:-%{User-Name}})
start_tls = no
tls_cacertfile = /certs/edir/edir.pem
tls_certfile = /certs/edir/client.pem
tls_keyfile =/certs/edir/client.pem
tls_require_cert = demand
#tls_mode = yes
ldap_connections_number = 5
timeout = 5
timelimit = 3
net_timeout =1
}
Good luck :)
Yogesh.
On 7/19/07, Martin G [EMAIL PROTECTED] wrote:
Hello!
Im new to both this mailinglist and to novell/linux/ldap/freeradius but iv
tried my best to install a radius/ldap linuxserver to pass on
radius-requests from a Aruba-controller to our novell-server.
IPs:
Novell 10.10.0.11
Aruba 10.10.0.28
Linux (freeradius+ldap) 10.10.0.132
Iv tried to change tls_mode, port and tls_start on and off a couple of times
without any good result and when i go use ldapsearch -vvv -h 10.10.0.11 -x
-Z -b ou=adm,ou=malmo,o=wifi cn=lotta
i recieve TLS: hostname does not match CN in peer certificate.
So i have some thoughts about the certificate, but iv exported the
selfsigned novell-certificate from the novellserver and verifyed it. But im
not sure how to use a client-certificate on the linux.
When i use freeradius -XXX -A on the linuxserver and i trie to do a
radius-request, the aruba gets a timeout and the linuxserver tells me the
following logg:
Tue Jul 10 11:32:28 2007 : Info: Starting - reading configuration files ...
Tue Jul 10 11:32:28 2007 : Debug: reread_config: reading radiusd.conf
Tue Jul 10 11:32:28 2007 : Debug: Config: including file:
/etc/freeradius/proxy.conf
Tue Jul 10 11:32:28 2007 : Debug: Config: including file:
/etc/freeradius/clients.conf
Tue Jul 10 11:32:28 2007 : Debug: Config: including file:
/etc/freeradius/snmp.conf
Tue Jul 10 11:32:28 2007 : Debug: Config: including file:
/etc/freeradius/eap.conf
Tue Jul 10 11:32:28 2007 : Debug: Config: including file:
/etc/freeradius/sql.conf
Tue Jul 10 11:32:28 2007 : Debug: main: prefix = /usr
Tue Jul 10 11:32:28 2007 : Debug: main: localstatedir = /var
Tue Jul 10 11:32:28 2007 : Debug: main: logdir = /var/log/freeradius
Tue Jul 10 11:32:28 2007 : Debug: main: libdir = /usr/lib/freeradius
Tue Jul 10 11:32:28 2007 : Debug: main: radacctdir =
/var/log/freeradius/radacct
Tue Jul 10 11:32:28 2007 : Debug: main: hostname_lookups = no
Tue Jul 10 11:32:28 2007 : Debug: main: max_request_time = 30
Tue Jul 10 11:32:28 2007 : Debug: main: cleanup_delay = 5
Tue Jul 10 11:32:28 2007 : Debug: main: max_requests = 1024
Tue Jul 10 11:32:28 2007 : Debug: main: delete_blocked_requests = 0
Tue Jul 10 11:32:28 2007 : Debug: main: port = 0
Tue Jul 10 11:32:28 2007 : Debug: main: allow_core_dumps = no
Tue Jul 10 11:32:28 2007 : Debug: main: log_stripped_names = yes
Tue Jul 10 11:32:28 2007 : Debug: main: log_file =
/var/log/freeradius/radius.log
Tue Jul 10 11:32:28 2007 : Debug: main: log_auth = yes
Tue Jul 10 11:32:28 2007 : Debug: main: log_auth_badpass = yes
Tue Jul 10 11:32:28 2007 : Debug: main: log_auth_goodpass = yes
Tue Jul 10 11:32:28 2007 : Debug: main: pidfile =
/var/run/freeradius/freeradius.pid
Tue Jul 10 11:32:28 2007 : Debug: main: user = freerad
Tue Jul 10 11:32:28 2007 : Debug: main: group = freerad
Tue Jul 10 11:32:28 2007 : Debug: main: usercollide = no
Tue Jul 10 11:32:28 2007 : Debug: main: lower_user = no
Tue Jul 10 11:32:28 2007 :
RE: rlm_sql bug in 64-bit architecture ?
I would love to know what the: Invalid operator for item Expiration: reverting to '==' I get them like so: Invalid operator for item User-name: reverting to '==' All three of my server logs are filled with them and I've been unable to find the reason why. All the username's listed in the huntgroup can successfully authenticate. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Richard Cotrina Sent: Tuesday, July 24, 2007 2:57 PM To: FreeRadius users mailing list Subject: rlm_sql bug in 64-bit architecture ? Hi everyone : I've been searching for the possible causes of a problem, that appears when sqlcounter is enabled, and just in 64-bits plattforms (FreeBSD/Sparc64). The radius_xlat function performed by rlm_sql seems to not reading well some attributes like Expiration and always complains about Invalid Operator, not matter what operator is put [1]. Note the big difference between the responses obtained in the 64-bit and 32-bit arch, using radtest and running radiusd in debug mode: rlm_sql can't read neither the value nor the operator for Expiration attribute, despite the fact that in both cases, the database used is the same. (rlm_sql debug options enabled in rlm_sql.c). freeradius 1.1.6 / FreeBSD Sparc64 == radius_xlat: '[EMAIL PROTECTED]' rlm_sql (sql): [snip] radius_xlat: [snip] rlm_sql: check items User-Password := prueba Auth-Type := Local Simultaneous-Use := 1 Max-Daily-Session := 3600 Expiration INVALID-TOKEN Dec 31 1969 19:00:00 PET --- Notice this (where this value come from ?) rlm_sql: reply items Framed-Protocol = PPP Framed-IP-Address = 255.255.255.254 Framed-IP-Netmask = 255.255.255.255 Framed-MTU = 1500 Service-Type = Framed-User Idle-Timeout = 300 Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' rlm_sql (sql): No matching entry in the database for request from user [EMAIL PROTECTED] modcall[authorize]: module sql returns notfound for request 9 rlm_sqlcounter: Entering module authorize code rlm_sqlcounter: Could not find Check item value pair modcall[authorize]: module dailycounter returns noop for request 9 [snip] -- Got an Access-Reject response freeradius 1.1.6 / FreeBSD i386 === radius_xlat: '[EMAIL PROTECTED]' rlm_sql (sql): [snip] radius_xlat: [snip] rlm_sql: check items User-Password := prueba Auth-Type := Local Simultaneous-Use := 1 Max-Daily-Session := 3600 Expiration := Sep 24 2007 11:30:00 PET --- get the correct 'op' and 'value' rlm_sql: reply items Framed-Protocol = PPP Framed-IP-Address = 255.255.255.254 Framed-IP-Netmask = 255.255.255.255 Framed-MTU = 1500 Service-Type = Framed-User Idle-Timeout = 300 modcall[authorize]: module sql returns ok for request 0 rlm_sqlcounter: Entering module authorize code [snip] -- Got an Access-Accept response What could be going wrong with rlm_sql ? Is there any bug in freeradius code related to 64-bit architectures ? I'd appreciate any suggestion to solve this. Richard Cotrina [1]. http://archives.free.net.ph/message/20070517.165523.c7432a23.en.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html CONFIDENTIAL NOTICE: This email including any attachments, contains confidential information belonging to the sender. It may also be privileged or otherwise protected by work product immunity or other legal rules. This information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this emailed information is strictly prohibited. If you have received this email in error, please immediately notify us by reply email of the error and then delete this email immediately. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: rlm_sql bug in 64-bit architecture ?
If you have: somegroup User-Name = whatever That is normal. Huntgroup check item should have operator == not = and server is clever enough to fix it. But it will grumble in the log so you can change incorrect entries. Ivan Kalik Kalik Informatika ISP Dana 24/7/2007, Chris Bell [EMAIL PROTECTED] piše: I would love to know what the: Invalid operator for item Expiration: reverting to '==' I get them like so: Invalid operator for item User-name: reverting to '==' All three of my server logs are filled with them and I've been unable to find the reason why. All the username's listed in the huntgroup can successfully authenticate. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Richard Cotrina Sent: Tuesday, July 24, 2007 2:57 PM To: FreeRadius users mailing list Subject: rlm_sql bug in 64-bit architecture ? Hi everyone : I've been searching for the possible causes of a problem, that appears when sqlcounter is enabled, and just in 64-bits plattforms (FreeBSD/Sparc64). The radius_xlat function performed by rlm_sql seems to not reading well some attributes like Expiration and always complains about Invalid Operator, not matter what operator is put [1]. Note the big difference between the responses obtained in the 64-bit and 32-bit arch, using radtest and running radiusd in debug mode: rlm_sql can't read neither the value nor the operator for Expiration attribute, despite the fact that in both cases, the database used is the same. (rlm_sql debug options enabled in rlm_sql.c). freeradius 1.1.6 / FreeBSD Sparc64 == radius_xlat: '[EMAIL PROTECTED]' rlm_sql (sql): [snip] radius_xlat: [snip] rlm_sql: check items User-Password := prueba Auth-Type := Local Simultaneous-Use := 1 Max-Daily-Session := 3600 Expiration INVALID-TOKEN Dec 31 1969 19:00:00 PET --- Notice this (where this value come from ?) rlm_sql: reply items Framed-Protocol = PPP Framed-IP-Address = 255.255.255.254 Framed-IP-Netmask = 255.255.255.255 Framed-MTU = 1500 Service-Type = Framed-User Idle-Timeout = 300 Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' rlm_sql (sql): No matching entry in the database for request from user [EMAIL PROTECTED] modcall[authorize]: module sql returns notfound for request 9 rlm_sqlcounter: Entering module authorize code rlm_sqlcounter: Could not find Check item value pair modcall[authorize]: module dailycounter returns noop for request 9 [snip] -- Got an Access-Reject response freeradius 1.1.6 / FreeBSD i386 === radius_xlat: '[EMAIL PROTECTED]' rlm_sql (sql): [snip] radius_xlat: [snip] rlm_sql: check items User-Password := prueba Auth-Type := Local Simultaneous-Use := 1 Max-Daily-Session := 3600 Expiration := Sep 24 2007 11:30:00 PET --- get the correct 'op' and 'value' rlm_sql: reply items Framed-Protocol = PPP Framed-IP-Address = 255.255.255.254 Framed-IP-Netmask = 255.255.255.255 Framed-MTU = 1500 Service-Type = Framed-User Idle-Timeout = 300 modcall[authorize]: module sql returns ok for request 0 rlm_sqlcounter: Entering module authorize code [snip] -- Got an Access-Accept response What could be going wrong with rlm_sql ? Is there any bug in freeradius code related to 64-bit architectures ? I'd appreciate any suggestion to solve this. Richard Cotrina [1]. http://archives.free.net.ph/message/20070517.165523.c7432a23.en.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html CONFIDENTIAL NOTICE: This email including any attachments, contains confidential information belonging to the sender. It may also be privileged or otherwise protected by work product immunity or other legal rules. This information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this emailed information is strictly prohibited. If you have received this email in error, please immediately notify us by reply email of the error and then delete this email immediately. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: rlm_sql bug in 64-bit architecture ?
Chris Bell said: : RE: rlm_sql bug in 64-bit architecture ? I would love to know what the: Invalid operator for item Expiration: reverting to '==' I get them like so: Invalid operator for item User-name: reverting to '==' All three of my server logs are filled with them and I've been unable to find the reason why. All the username's listed in the huntgroup can successfully authenticate. My bet is you have an = in a check attribute line in your users file, like: DEFAULT User-Name = foo Some-Attribute = bar For a check item (the first line) it should be an ==. DEFAULT User-Name == foo Some-Attribute = bar The = is an assignment operator (set Some-Attribute to have value bar). The == is a comparison operator (does User-Name have the value foo?). It is illegal to use the = on the check attribute line. -- hugh - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_sql bug in 64-bit architecture ?
Chris Bell wrote: Invalid operator for item User-name: reverting to '==' All three of my server logs are filled with them and I've been unable to find the reason why. All the username's listed in the huntgroup can successfully authenticate. Have you looked at all of your references to User-Name in the configurations? What operator are they using? Is the operator correct? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
How to capture wireless EAP packets on Windows XP?
I'm testing FreeRADIUS's PEAP-EAP-MSCHAPv2 functionality with a wireless USB adapter (D-Link AirPlus G DWL-G122) on Windows XP (SP2). I tried to capture the EAP packets using Wireshark 0.99.6a but I failed. Anyone can help? Thanks. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: multiple authorization modules
On 7/25/07, Joe Vieira [EMAIL PROTECTED] wrote: Nevermind, i figured it out. I have the same question. How did you figure it out? Joe Vieira wrote: Hello, I am curious about the methodology for using one authorization module for one type of service and another for a different type of service. basically we have wireless and VPN that is being authorized and authenticated through our radius box. i would like to be able to control authorization to each of those independently though different ldap attributes. I currently have it working with one ldap module, so both service are authorized thru the same attribute i am using freeradius 1.1.6 Any thoughts? Joe - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RADIUS Server Backend
Hi all, What are the different backend data stores supported by the RADIUS Server? Thanks Regards Gaurav - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RADIUS Server Backend
I believe http://wiki.freeradius.org/Modules#Available_Modules will give you an idea On 7/24/07, Gaurav Bandekar [EMAIL PROTECTED] wrote: Hi all, What are the different backend data stores supported by the RADIUS Server? Thanks Regards Gaurav - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Nicholas Hall [EMAIL PROTECTED] 262.208.6271 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
