Re: Multiple instances of attribute in tunnelled reply
Hi Alan DeKok: Are you sure it is the PEAP module,not the TTLS module? why? And when will the 2.1.9 be released? thank you very much! sunhualing On Wed, Apr 14, 2010 at 10:59 AM, Alan DeKok al...@deployingradius.comwrote: sunhualing wrote: Hello everyone: I am using a freeradius-2.1.8, with eap-ttls mschap v2. I happen to get a problem that some attribute missing in the Access-Accept message, while it appears in the first Access-Challenge message. I still find that those attributes appear tunneled reply , i use the debug mode. Search the mail list , i find that similiar problem appears two years ago, here is the mail. Any suggestion is welcome, thanks a log Hmm... the fix is likely to edit the source code of the PEAP module. I'll take a look at it for 2.1.9. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of attribute in tunnelled reply
sunhualing wrote: Hi Alan DeKok: Are you sure it is the PEAP module,not the TTLS module? why? And when will the 2.1.9 be released? thank you very much! They both have the same code, and they both should be fixed. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of attribute in tunnelled reply
Thanks very much, I wish that the version 2.1.9 will be released soon. Sunhualing On Wed, Apr 14, 2010 at 3:02 PM, Alan DeKok al...@deployingradius.comwrote: sunhualing wrote: Hi Alan DeKok: Are you sure it is the PEAP module,not the TTLS module? why? And when will the 2.1.9 be released? thank you very much! They both have the same code, and they both should be fixed. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Multiple instances of attribute in tunnelled reply
Hello everyone:
I am using a freeradius-2.1.8, with eap-ttls mschap v2. I happen to get
a problem that some attribute missing in the
Access-Accept message, while it appears in the first Access-Challenge
message. I still find that those attributes appear
tunneled reply , i use the debug mode.
Search the mail list , i find that similiar problem appears two years
ago, here is the mail.
Any suggestion is welcome, thanks a log
sunhualing
Hi,
We formulate our reply inside of the virtual server dealing with EAP and send
it back to the outer server. This is the only way I could think of to insert
the Inner identity into the Access-Accept. It all works fine... however it
seems there's a bug when dealing with multiple instances of the same
attribute.
For example:
users / sql
DEFAULT Service-Type == Framed-User, Realm == 'local', SS-Flags =~
^.1$
Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-ID = 603,
Reply-Message = User %{%{Stripped-User-Name}:-%{User-Name}} authenticated
for ResNet access on NAS:%{%{NAS-Identifier}:-Uknown NAS}
SSID:%{%{Called-Station-SSID}:-none}.,
HP-IP-FILTER-RAW = 'deny in 41 from any to any',
HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.1',
HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.2',
HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.3',
HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.4',
HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.5',
Fall-Through = no
Ends up being sent as the response:
# server default-inner
PEAP: Got tunneled reply RADIUS code 2
Service-Type = Framed-User
Framed-MTU = 1480
Framed-Routing = None
Framed-Protocol = PPP
Framed-Compression = Van-Jacobson-TCP-IP
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = 603
Reply-Message = User ac221 authenticated for ResNet access on
NAS:hp-e-engg1-1-dev-8021x-sw1
SSID:none.
HP-Ip-Filter-Raw = deny in 41 from any to any
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.1
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.2
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.3
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.4
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.5
EAP-Message = 0x03490004
Message-Authenticator = 0x
User-Name = ac221
PEAP: Processing from tunneled session code 0x845cb10 2
Service-Type = Framed-User
Framed-MTU = 1480
Framed-Routing = None
Framed-Protocol = PPP
Framed-Compression = Van-Jacobson-TCP-IP
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = 603
Reply-Message = User ac221 authenticated for ResNet access on
NAS:hp-e-engg1-1-dev-8021x-sw1
SSID:none.
HP-Ip-Filter-Raw = deny in 41 from any to any
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.1
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.2
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.3
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.4
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.5
EAP-Message = 0x03490004
Message-Authenticator = 0x
User-Name = ac221
PEAP: Tunneled authentication was successful.
rlm_eap_peap: SUCCESS
Saving tunneled attributes for later
So when it's actually used in the Access-Accept packet it appears as:
Sending Access-Accept of id 173 to 139.184.8.16 port 1024
Service-Type = Framed-User
Framed-MTU = 1480
Framed-Routing = None
Framed-Protocol = PPP
Framed-Compression = Van-Jacobson-TCP-IP
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = 603
HP-Ip-Filter-Raw = deny in 41 from any to any
User-Name = ac...@sussex.ac.uk
MS-MPPE-Recv-Key =
0xdec383f4a269cb3d8fcf59cd9e351971c3a9a3683a7c245144a0b852634c7a03
MS-MPPE-Send-Key =
0xb9f49bba9f9020deaa745c6ea0e8f5b92e72e2fc5b6465aed4a9231f10edd696
EAP-Message = 0x034a0004
Message-Authenticator = 0x
Finished request 9.
What's really weird is in the previous rounds of EAP, the attributes
retain the += operator, it's only in the one where the EAP-Success
message is returned where all the operators are stripped out.
Relevant EAP bits:
eap {
...
ttls {
...
copy_request_to_tunnel = yes
use_tunneled_reply = yes
virtual_server = default-inner
}
}
Thanks,
Arran
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of attribute in tunnelled reply
sunhualing wrote: Hello everyone: I am using a freeradius-2.1.8, with eap-ttls mschap v2. I happen to get a problem that some attribute missing in the Access-Accept message, while it appears in the first Access-Challenge message. I still find that those attributes appear tunneled reply , i use the debug mode. Search the mail list , i find that similiar problem appears two years ago, here is the mail. Any suggestion is welcome, thanks a log Hmm... the fix is likely to edit the source code of the PEAP module. I'll take a look at it for 2.1.9. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Lost entries from reply with multiple instances of the same attribute
Konstantin KABASSANOV wrote: Some months ago I mentioned a problem observed while sending Access-Accept with multiple Cisco-AVPair=ssid=... entries. Even if fields are correctly retrieved from the LDAP server, only the first occurrence of the attribute is sent in the packet. Can you tell me if recent developments have solved this issue? This issue has been solved for almost 4 years now. Read ldap.attrmap. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Lost entries from reply with multiple instances of the same attribute
Konstantin KABASSANOV wrote: Some months ago I mentioned a problem observed while sending Access- Accept with multiple Cisco-AVPair=ssid=... entries. Even if fields are correctly retrieved from the LDAP server, only the first occurrence of the attribute is sent in the packet. Can you tell me if recent developments have solved this issue? This issue has been solved for almost 4 years now. Read ldap.attrmap. Alan, I'd be very happy if it was true, but: Even if my radius server gets the following from the rlm_ldap: rlm_ldap: looking for reply items in directory... rlm_ldap: LDAP attribute wireless as RADIUS attribute Cisco-AVPair = ssid=mywifi1 rlm_ldap: LDAP attribute wireless as RADIUS attribute Cisco-AVPair = ssid=mywifi2 the outgoing access-accept packet contains only the first entry: rlm_ldap: LDAP attribute wireless as RADIUS attribute Cisco-AVPair = ssid=mywifi1 FYI the version I use for radius is 2.0.4 so I don't think it is more than 4 years old. In an email sent in April 2008, I saw somebody with a similar problem with another attribute and there was an information that the bug was corrected only in unlang. Am I wrong? Konstantin smime.p7s Description: S/MIME cryptographic signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Lost entries from reply with multiple instances of the same attribute
Konstantin KABASSANOV wrote: Konstantin KABASSANOV wrote: Some months ago I mentioned a problem observed while sending Access- Accept with multiple Cisco-AVPair=ssid=... entries. Even if fields are correctly retrieved from the LDAP server, only the first occurrence of the attribute is sent in the packet. Can you tell me if recent developments have solved this issue? This issue has been solved for almost 4 years now. Read ldap.attrmap. Alan, I'd be very happy if it was true, but: Even if my radius server gets the following from the rlm_ldap: rlm_ldap: looking for reply items in directory... rlm_ldap: LDAP attribute wireless as RADIUS attribute Cisco-AVPair = ssid=mywifi1 rlm_ldap: LDAP attribute wireless as RADIUS attribute Cisco-AVPair = ssid=mywifi2 Read the comments in ldap.attrmap. Specifically you're going to want: replyItem Cisco-AVPair wireless += i.e. you need to use the operator field - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Lost entries from reply with multiple instances of the same attribute
Hi, Some months ago I mentioned a problem observed while sending Access-Accept with multiple Cisco-AVPair=ssid=... entries. Even if fields are correctly retrieved from the LDAP server, only the first occurrence of the attribute is sent in the packet. Can you tell me if recent developments have solved this issue? Thanks. Konstantin _ Konstantin KABASSANOV LIP6/CNRS 104, avenue du Président Kennedy, 75016 Paris, France Phone: +33 (0) 1 44 27 71 26 Fax: +33 (0) 1 44 27 74 95 E-mail: [EMAIL PROTECTED] Web: http://www.kabassanov.com Certificate: http://igc.services.cnrs.fr/CNRS-Standard/recherche.html _ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Multiple instances of attribute in tunnelled reply
Hi, I think that I have a similar problem when freeradius has to send Access-Accept with multiple Cisco-AVPair=ssid=... entries. Do you think it will be fixed in the near future ? Thanks. Konstantin _ Konstantin KABASSANOV LIP6/CNRS 104, avenue du Président Kennedy, 75016 Paris, France Phone: +33 (0) 1 44 27 71 26 Fax: +33 (0) 1 44 27 74 95 E-mail: [EMAIL PROTECTED] Web: http://www.kabassanov.com Certificate: http://igc.services.cnrs.fr/CNRS-Standard/recherche.html _ smime.p7s Description: S/MIME cryptographic signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of attribute in tunnelled reply
Arran Cudbard-Bell wrote:
Hi,
We formulate our reply inside of the virtual server dealing with EAP and
send it back to the outer server. This is the only way I could think of
to insert the Inner identity into the Access-Accept.
...
update outer.reply {
User-Name := foo
}
...
It all works
fine... however it seems there's a bug when dealing with multiple
instances of the same attribute.
Ah the code in unlang was fixed to correct this problem. The
basic API used in the basic RADIUS library wasn't fixed.
Ok... I'll take a look at it when I get back from my current trip.
What's really weird is in the previous rounds of EAP, the attributes
retain the += operator, it's only in the one where the EAP-Success
message is returned where all the operators are stripped out.
Yes. copy everything, versus merge via operators.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of attribute in tunnelled reply
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Hi,
We formulate our reply inside of the virtual server dealing with EAP and
send it back to the outer server. This is the only way I could think of
to insert the Inner identity into the Access-Accept.
...
update outer.reply {
User-Name := foo
}
...
Hmm, it's complicated... there are authorisation issues too.
It all works
fine... however it seems there's a bug when dealing with multiple
instances of the same attribute.
Ah the code in unlang was fixed to correct this problem. The
basic API used in the basic RADIUS library wasn't fixed.
Ok... I'll take a look at it when I get back from my current trip.
Ok that helps, didn't realise it was fixed in unlang; least I can get
some dynamic ACL testing done.
What's really weird is in the previous rounds of EAP, the attributes
retain the += operator, it's only in the one where the EAP-Success
message is returned where all the operators are stripped out.
Yes. copy everything, versus merge via operators.
Yep.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thanks,
Arran
--
Arran Cudbard-Bell ([EMAIL PROTECTED])
Authentication, Authorisation and Accounting Officer
Infrastructure Services | ENG1 E1-1-08
University Of Sussex, Brighton
EXT:01273 873900 | INT: 3900
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of attribute in tunnelled reply
Erg,
Still no closer to fixing this / finding a work around. Is anyone else
using a similar configuration and finding this issue?
Arran
Arran Cudbard-Bell wrote:
Hi,
We formulate our reply inside of the virtual server dealing with EAP and
send it back to the outer server. This is the only way I could think of
to insert the Inner identity into the Access-Accept. It all works
fine... however it seems there's a bug when dealing with multiple
instances of the same attribute.
For example:
users / sql
DEFAULT Service-Type == Framed-User, Realm == 'local', SS-Flags =~
^.1$
Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-ID = 603,
Reply-Message = User
%{%{Stripped-User-Name}:-%{User-Name}} authenticated for ResNet access
on NAS:%{%{NAS-Identifier}:-Uknown NAS}
SSID:%{%{Called-Station-SSID}:-none}.,
HP-IP-FILTER-RAW = 'deny in 41 from any to any',
HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.1',
HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.2',
HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.3',
HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.4',
HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.5',
Fall-Through = no
Ends up being sent as the response:
# server default-inner
PEAP: Got tunneled reply RADIUS code 2
Service-Type = Framed-User
Framed-MTU = 1480
Framed-Routing = None
Framed-Protocol = PPP
Framed-Compression = Van-Jacobson-TCP-IP
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = 603
Reply-Message = User ac221 authenticated for ResNet access on
NAS:hp-e-engg1-1-dev-8021x-sw1 SSID:none.
HP-Ip-Filter-Raw = deny in 41 from any to any
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.1
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.2
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.3
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.4
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.5
EAP-Message = 0x03490004
Message-Authenticator = 0x
User-Name = ac221
PEAP: Processing from tunneled session code 0x845cb10 2
Service-Type = Framed-User
Framed-MTU = 1480
Framed-Routing = None
Framed-Protocol = PPP
Framed-Compression = Van-Jacobson-TCP-IP
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = 603
Reply-Message = User ac221 authenticated for ResNet access on
NAS:hp-e-engg1-1-dev-8021x-sw1 SSID:none.
HP-Ip-Filter-Raw = deny in 41 from any to any
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.1
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.2
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.3
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.4
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.5
EAP-Message = 0x03490004
Message-Authenticator = 0x
User-Name = ac221
PEAP: Tunneled authentication was successful.
rlm_eap_peap: SUCCESS
Saving tunneled attributes for later
So when it's actually used in the Access-Accept packet it appears as:
Sending Access-Accept of id 173 to 139.184.8.16 port 1024
Service-Type = Framed-User
Framed-MTU = 1480
Framed-Routing = None
Framed-Protocol = PPP
Framed-Compression = Van-Jacobson-TCP-IP
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = 603
HP-Ip-Filter-Raw = deny in 41 from any to any
User-Name = [EMAIL PROTECTED]
MS-MPPE-Recv-Key =
0xdec383f4a269cb3d8fcf59cd9e351971c3a9a3683a7c245144a0b852634c7a03
MS-MPPE-Send-Key =
0xb9f49bba9f9020deaa745c6ea0e8f5b92e72e2fc5b6465aed4a9231f10edd696
EAP-Message = 0x034a0004
Message-Authenticator = 0x
Finished request 9.
What's really weird is in the previous rounds of EAP, the attributes
retain the += operator, it's only in the one where the EAP-Success
message is returned where all the operators are stripped out.
Relevant EAP bits:
eap {
...
ttls {
...
copy_request_to_tunnel = yes
use_tunneled_reply = yes
virtual_server = default-inner
}
}
Thanks,
Arran
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Multiple instances of attribute in tunnelled reply
Hi,
We formulate our reply inside of the virtual server dealing with EAP and
send it back to the outer server. This is the only way I could think of
to insert the Inner identity into the Access-Accept. It all works
fine... however it seems there's a bug when dealing with multiple
instances of the same attribute.
For example:
users / sql
DEFAULT Service-Type == Framed-User, Realm == 'local', SS-Flags =~
^.1$
Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-ID = 603,
Reply-Message = User
%{%{Stripped-User-Name}:-%{User-Name}} authenticated for ResNet access
on NAS:%{%{NAS-Identifier}:-Uknown NAS}
SSID:%{%{Called-Station-SSID}:-none}.,
HP-IP-FILTER-RAW = 'deny in 41 from any to any',
HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.1',
HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.2',
HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.3',
HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.4',
HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.5',
Fall-Through = no
Ends up being sent as the response:
# server default-inner
PEAP: Got tunneled reply RADIUS code 2
Service-Type = Framed-User
Framed-MTU = 1480
Framed-Routing = None
Framed-Protocol = PPP
Framed-Compression = Van-Jacobson-TCP-IP
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = 603
Reply-Message = User ac221 authenticated for ResNet access on
NAS:hp-e-engg1-1-dev-8021x-sw1 SSID:none.
HP-Ip-Filter-Raw = deny in 41 from any to any
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.1
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.2
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.3
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.4
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.5
EAP-Message = 0x03490004
Message-Authenticator = 0x
User-Name = ac221
PEAP: Processing from tunneled session code 0x845cb10 2
Service-Type = Framed-User
Framed-MTU = 1480
Framed-Routing = None
Framed-Protocol = PPP
Framed-Compression = Van-Jacobson-TCP-IP
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = 603
Reply-Message = User ac221 authenticated for ResNet access on
NAS:hp-e-engg1-1-dev-8021x-sw1 SSID:none.
HP-Ip-Filter-Raw = deny in 41 from any to any
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.1
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.2
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.3
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.4
HP-Ip-Filter-Raw = permit in ip from any to 10.0.8.5
EAP-Message = 0x03490004
Message-Authenticator = 0x
User-Name = ac221
PEAP: Tunneled authentication was successful.
rlm_eap_peap: SUCCESS
Saving tunneled attributes for later
So when it's actually used in the Access-Accept packet it appears as:
Sending Access-Accept of id 173 to 139.184.8.16 port 1024
Service-Type = Framed-User
Framed-MTU = 1480
Framed-Routing = None
Framed-Protocol = PPP
Framed-Compression = Van-Jacobson-TCP-IP
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = 603
HP-Ip-Filter-Raw = deny in 41 from any to any
User-Name = [EMAIL PROTECTED]
MS-MPPE-Recv-Key =
0xdec383f4a269cb3d8fcf59cd9e351971c3a9a3683a7c245144a0b852634c7a03
MS-MPPE-Send-Key =
0xb9f49bba9f9020deaa745c6ea0e8f5b92e72e2fc5b6465aed4a9231f10edd696
EAP-Message = 0x034a0004
Message-Authenticator = 0x
Finished request 9.
What's really weird is in the previous rounds of EAP, the attributes retain the
+= operator, it's only in the one where the EAP-Success message is returned
where all the operators are stripped out.
Relevant EAP bits:
eap {
...
ttls {
...
copy_request_to_tunnel = yes
use_tunneled_reply = yes
virtual_server = default-inner
}
}
Thanks,
Arran
--
Arran Cudbard-Bell ([EMAIL PROTECTED])
Authentication, Authorisation and Accounting Officer
Infrastructure Services | ENG1 E1-1-08
University Of Sussex, Brighton
EXT:01273 873900 | INT: 3900
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rlm_sql multiple instances handling of
Hi, I have a problem where I need a lot of threads to catch accounting data, a lot of threads means a lot of DB handles. Alas this means more than 256 db handles which is the limit for rlm_sql. My thoughts therefore was to instantiate multiple rlm_sql modules to increase the number of db handles availible.However I am wondering on how to now use this. This system is purely for accounting. If I say put in the accounting stanza:sql1sql2sqlnWill the accounting packet be sent to all sql instanses in turn, or just the 1st one that succeeds ? and then not any further ? Will a "no free db handles" error from sql1 lead to sql2 being attempted ?Thanks in advance - Graeme Hinchliffe (BSc) Core Systems Designer Zen Internet (http://www.zen.co.uk/) Direct: 0845 058 9074 Main : 0845 058 9000 Fax : 0845 058 9005 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Multiple instances of the exec module
Hi All, I am new to FreeRadius and in fact Radius. Having spent some time playing with FreeRadius (Windows ver) I need to call an external program in the preacct, authorize authenticate sections. While the code comment in the piece prior to the exec module states the following: # If you wish to execute an external program in more than # one section (e.g. 'authorize', 'pre_proxy', etc), then it # is probably best to define a different instance of the # 'exec' module for every section. I am lost as to where or maybe how this definition is done. If I duplicate the exec module in the actual section, RadiusD complains about 'wait' not being defined. Can anyone provide guidance? Many thanks Les Brinkworth - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of the exec module
On 10/13/06, Les Brinkworth [EMAIL PROTECTED] wrote: I am lost as to where or maybe how this definition is done. If I duplicate the exec module in the actual section, RadiusD complains about 'wait' not being defined. Just a guess (as you didn't provide any output): The error (more of a warning) is something like ...Wait=yes but no output defined...? So check for the subsequent comment in the definition of an exec instance called echo. Which should also serve as an example how to define different instances, which would then be called in the actual section by their name. regards K. Hoercher - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Multiple instances of the exec module
rlm_eap: Loaded and initialized type ttls peap: default_eap_type = mschapv2 peap: copy_request_to_tunnel = no peap: use_tunneled_reply = no peap: proxy_tunneled_request_as_eap = yes rlm_eap: Loaded and initialized type peap mschapv2: with_ntdomain_hack = no rlm_eap: Loaded and initialized type mschapv2 Module: Instantiated eap (eap) Module: Loaded preprocess preprocess: huntgroups = ../etc/raddb/huntgroups preprocess: hints = ../etc/raddb/hints preprocess: with_ascend_hack = no preprocess: ascend_channels_per_line = 23 preprocess: with_ntdomain_hack = no preprocess: with_specialix_jetstream_hack = no preprocess: with_cisco_vsa_hack = yes Module: Instantiated preprocess (preprocess) radiusd.conf[1527] Unknown module rcode 'wait'. radiusd.conf[1513] Failed to parse authorize section. C:\Program Files\FreeRADIUS.net-1.1.1-r0.0.1\bin Thanks Les -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] rg] On Behalf Of K. Hoercher Sent: 13 October 2006 11:21 AM To: FreeRadius users mailing list Subject: Re: Multiple instances of the exec module On 10/13/06, Les Brinkworth [EMAIL PROTECTED] wrote: I am lost as to where or maybe how this definition is done. If I duplicate the exec module in the actual section, RadiusD complains about 'wait' not being defined. Just a guess (as you didn't provide any output): The error (more of a warning) is something like ...Wait=yes but no output defined...? So check for the subsequent comment in the definition of an exec instance called echo. Which should also serve as an example how to define different instances, which would then be called in the actual section by their name. regards K. Hoercher - 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: Multiple instances of the exec module
On 10/13/06, Les Brinkworth [EMAIL PROTECTED] wrote:
How does one define two instances of exec with different names that can
be called from other sections?
Aaah, now it gets a bit more clear to me. You should take into account
the comments at the beginning of the modules{} section. That would
lead to something like:
Code snippet from Modules section of radiusd.conf...
exec doacctfoo {
wait = yes
program = handlebillingrequests.exe ACCR:%Z
input_pairs = request
output_pairs = reply
packet_type = Accounting-Request
}
...This executes for an accounting request
If I then add the same code to the authorize section...
ah no, that won't work. you just put it into the modules{} too with
analogous change:
exec dorequestfoo {
wait = yes
program = handlebillingrequests.exe AUTR:%Z
input_pairs = request
output_pairs = reply
packet_type = Access-Request
}
...it results in the following when I run debug
radiusd.conf[1527] Unknown module rcode 'wait'.
radiusd.conf[1513] Failed to parse authorize section.
Ok, that confuses freeradius way to much, as that is not the place to
define module instances (see above), especially when another one (the
unnamed one) already is present.
But you can now put the named defined ones in the appropriate section e.g.
authorize {
...
dorequestfoo
...
}
accounting {
...
doacctfoo
...
}
There might be other ways of doing it, (using the same module, but
changing the called program, so it can cope with both tasks
accordingly) but keeping it simple at first and following the
recommendations in the comments looks preferable, at least until you
get some working config.
regards
K. Hoercher
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Multiple instances of the exec module
K. Many thanks for clarifying...
Les
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg] On Behalf Of K. Hoercher
Sent: 13 October 2006 14:44 PM
To: FreeRadius users mailing list
Subject: Re: Multiple instances of the exec module
On 10/13/06, Les Brinkworth [EMAIL PROTECTED] wrote:
How does one define two instances of exec with different names that
can be called from other sections?
Aaah, now it gets a bit more clear to me. You should take into account
the comments at the beginning of the modules{} section. That would lead
to something like:
Code snippet from Modules section of radiusd.conf...
exec doacctfoo {
wait = yes
program = handlebillingrequests.exe ACCR:%Z
input_pairs = request
output_pairs = reply
packet_type = Accounting-Request
}
...This executes for an accounting request
If I then add the same code to the authorize section...
ah no, that won't work. you just put it into the modules{} too with
analogous change:
exec dorequestfoo {
wait = yes
program = handlebillingrequests.exe AUTR:%Z
input_pairs = request
output_pairs = reply
packet_type = Access-Request
}
...it results in the following when I run debug
radiusd.conf[1527] Unknown module rcode 'wait'.
radiusd.conf[1513] Failed to parse authorize section.
Ok, that confuses freeradius way to much, as that is not the place to
define module instances (see above), especially when another one (the
unnamed one) already is present.
But you can now put the named defined ones in the appropriate section
e.g.
authorize {
...
dorequestfoo
...
}
accounting {
...
doacctfoo
...
}
There might be other ways of doing it, (using the same module, but
changing the called program, so it can cope with both tasks
accordingly) but keeping it simple at first and following the
recommendations in the comments looks preferable, at least until you get
some working config.
regards
K. Hoercher
-
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: Multiple instances
Mike Chamberlain [EMAIL PROTECTED] wrote: which specify ports 1812 and 1813 respectively, so I thought I'd be able to issue the following commands: radiusd -d /usr/local/etc/raddb radiusd -d /usr/local/etc/raddb2 This doesn't seem to work however, as the second command seems to have no effect, ie. I see the first radiusd process running but never the second. Can anyone help please? Have you tried running the server in debugging mode to see the message it produces? It WILL tell you what's going wrong, and why. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances
Hello there. This is probably a stupid question, but how do I run multiple instances of radiusd on the same machine, listening on different ports? I have two configuration directories: /usr/local/etc/raddb /usr/local/etc/raddb2 which specify ports 1812 and 1813 respectively, so I thought I'd be able to issue the following commands: 1812 is for authentication and 1813 for accounting. So, if you used the port configuration in radiusd.conf and set raddb to 1812, it will automatically use 1813 for accounting. radiusd -d /usr/local/etc/raddb radiusd -d /usr/local/etc/raddb2 That is the correct way to do that part. This doesn't seem to work however, as the second command seems to have no effect, ie. I see the first radiusd process running but never the second. Can anyone help please? Probably because you are trying to set port = 1813 on raddb2, which would make it listen to 1813 and 1814 - but 1813 is already taken on raddb. Easiest way to do it is to set raddb with port = 1812 and raddb2 with port = 1645 (1645 and 1646 are the old traditional radius ports. Those are pretty safe to use since a lot of people still run radius on those ports - you'll probably still see it commented out in /etc/services) -Dusty Doris - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Multiple instances of ldap module
Hello:
I have been asked to mantain a recently installed freeradius server, but
I am not the person who installed it and I am quite new to radius, and
don't want to mess it up.
This radius server makes use of the ldap module to make queries to an
ldap server that we already have.
Now, we have a new client, which needs a different configuration for the
ldap module. It needs a different query than the rest of the clients.
I've read the Autz-Type document which is in the distribution, and it
seems that there is a way to select between multiple instances of a
module (ldap) which have been configured differently (literally copied
from that doc). Next in that document, there is an very simple example
of what the radius.conf and users files should look like, here it is:
radiusd.conf-
authenticate{
Auth-Type customer1{
ldap1
}
Auth-Type customer2{
ldap2
}
}
authorize{
preprocess
suffix
Autz-Type customer1{
ldap1
}
Autz-Type customer2{
ldap2
}
files
}
-
users file---
DEFAULT Realm == customer1, Autz-Type := customer1, Auth-Type := customer1
DEFAULT Realm == customer2, Autz-Type := customer2, Auth-Type := customer2
If i have not missed anything, this examples decides whether the user
should use the first or the second ldap instance looking at the user's
realm. But, is there a way to choose the first instance for all but one
of the radius clients and the second instance for the remaining client?
In other words, how do you discriminate which ldap instance to use in
basis of the client that uses the radius server?
Thank you.
--
Teo Romera [EMAIL PROTECTED]
--
Teo Romera [EMAIL PROTECTED]
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of ldap module
Teo Romera [EMAIL PROTECTED] wrote: In other words, how do you discriminate which ldap instance to use in basis of the client that uses the radius server? Key off of the Client-IP-Address attribute. It contains the IP address of the client. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
