[RADIATOR] Coovachilli with Radiator (Configuration files)
Respected Sir, Please guide on how to configure Coovachilli as a AAA client of Radiator. The communication between them should be via Radius protocol. I am new to the product Coovachilli and Radiator integration with the same. Kindly share with me previous records , knowledge base or any information you can kindly provide me with . Our Purpose : We need a captive portal to force our wifi users to access the internet wifi connection after authenticating via the captive portal login access page. Appreciate if you can provide me with configurations of Radiator and Coovachilli for this purpose. -- Thanks in Advance & Appreciate your positive reply, Thomas Kurian IT Security Engineer (B.Tech. – Electrical) Kuwaiti Canadian Consulting Group (www.kccg.com) T: +965 22435566 F: +965 22415149 E: tho...@kccg.com ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthAttrDef for multi-value Radius attribute check
Hi Heikki,
Put me down for this feature as well...
Thanks.
-Original Message-
From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On
Behalf Of Heikki Vatiainen
Sent: Tuesday, September 17, 2013 8:24 AM
To: radiator@open.com.au
Subject: Re: [RADIATOR] AuthAttrDef for multi-value Radius attribute check
On 09/16/2013 03:59 PM, Alexander Hartmaier wrote:
> I just tried to implement a check for group membership:
>
> AuthAttrDef memberOf,OSC-Group-Identifier-LDAP,check
>
> OSC-Group-Identifier-LDAP is a multi-value attribute derived from
> OSC-Group-Identifier with a PreAuthHook, basically just to transform
> the support groups of a device into the corresponding LDAP CNs.
> According to the trace 4 log the check runs twice but both times using
> the first OSC-Group-Identifier-LDAP value.
> Is this a bug?
I think this is the intended behaviour. The code always fetches a single value
for the named attribute. This means it always gets the first attribute's value.
It does not try to fetch all values of the named attribute.
Currently you could use a PostSearchHook to do something like this:
my @ldap_groups = $p->get_attr('OSC-Group-Identifier-LDAP');
Since @ldap_groups is an array, you will get all values of
OSC-Group-Identifier-LDAP, not just the first one.
Then you can try each LDAP memberOf attribute value with
OSC-Group-Identifer-LDAP attribute values to see if there's a match:
my $memberof = $entry->get_value('memberOf', asref => 1); foreach my $group
(@$memberof) {
return 1 if (map {lc $group eq lc $_} @ldap_groups); } return 0;
Also, we discussed here about adding support for RADIUS attributes that can be
present multiple times. This would mean that e.g., if there are 4
Framed-IP-Address attributes, you could have something like this (flat file
format):
mikem User-Password=fred, %{RequestOr:Framed-IP-Address}=1.2.3.4
This would pass if any of the 4 Framed-IP-Address attributes is 1.2.3.4.
Any comments about how useful you or the others would see this is appreciated.
Thanks,
Heikki
--
Heikki Vatiainen
Radiator: the most portable, flexible and configurable RADIUS server anywhere.
SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside,
TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX,
RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix,
Windows, MacOSX, Solaris, VMS, NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Could not load EAP module Radius::EAP_
On 09/16/2013 11:55 PM, Barry Ard wrote: > I am including my sanitized radius configuration so maybe you can see > something that I can't. I'd say the configuration is fine. Another cause might be an EAP fragment that was sent to the process by the proxy. If the EAP message looks like having EAP extended type 254 it may also try to load a non-existing EAP module. > This has worked well for years. There are 2 > radius servers with 10 radiusd processes behind a proxy. On Saturday one > process was repeately receiving the "Could not load EAP module > Radius::EAP_" messages. If you have the Trace 4 logs, I could take a look. The logs should show better what type of message was being (re?)sent by the proxy. > I am running 4.11 but am in the process of > scheduling a change to move to 4.12. I do occasionally get messages like > 'Could not load EAP module Radius::EAP_16'. EAP method 16 does not look line anything that is currently used. This may also be caused by a message that is not part of any existing session the process was handling. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthAttrDef for multi-value Radius attribute check
Hi Heikki,
On 2013-09-17 14:23, Heikki Vatiainen wrote:
> On 09/16/2013 03:59 PM, Alexander Hartmaier wrote:
>> I just tried to implement a check for group membership:
>>
>> AuthAttrDef memberOf,OSC-Group-Identifier-LDAP,check
>>
>> OSC-Group-Identifier-LDAP is a multi-value attribute derived from
>> OSC-Group-Identifier with a PreAuthHook, basically just to transform the
>> support groups of a device into the corresponding LDAP CNs.
>> According to the trace 4 log the check runs twice but both times using
>> the first OSC-Group-Identifier-LDAP value.
>> Is this a bug?
> I think this is the intended behaviour. The code always fetches a single
> value for the named attribute. This means it always gets the first
> attribute's value. It does not try to fetch all values of the named
> attribute.
>
> Currently you could use a PostSearchHook to do something like this:
> my @ldap_groups = $p->get_attr('OSC-Group-Identifier-LDAP');
I already use get_attr in my hook that generates
OSC-Group-Identifier-LDAP from OSC-Group-Identifier and found in the
comments that it returns a list in list context. Had to change my hook
to handle OSC-Group-Identifier in cases where it contains more than one
value.
>
> Since @ldap_groups is an array, you will get all values of
> OSC-Group-Identifier-LDAP, not just the first one.
>
> Then you can try each LDAP memberOf attribute value with
> OSC-Group-Identifer-LDAP attribute values to see if there's a match:
>
> my $memberof = $entry->get_value('memberOf', asref => 1);
> foreach my $group (@$memberof) {
>return 1 if (map {lc $group eq lc $_} @ldap_groups);
> }
> return 0;
5.38.21 PostSearchHook from the 4.12 reference doc doesn't describe how
the return value influences the request handling. Is this something
common to all hooks and described somewhere else?
>
>
>
> Also, we discussed here about adding support for RADIUS attributes that
> can be present multiple times. This would mean that e.g., if there are 4
> Framed-IP-Address attributes, you could have something like this (flat
> file format):
>
> mikem User-Password=fred, %{RequestOr:Framed-IP-Address}=1.2.3.4
>
> This would pass if any of the 4 Framed-IP-Address attributes is 1.2.3.4.
>
> Any comments about how useful you or the others would see this is
> appreciated.
A syntax to define if any value or all values has to match is highly
anticipated!
>
> Thanks,
> Heikki
>
--
Best regards, Alexander Hartmaier
T-Systems Austria GesmbH
TSS Security Services
Network Security & Monitoring Engineer
phone: +43(0)57057-4320
fax: +43(0)57057-954320
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthAttrDef for multi-value Radius attribute check
On 09/16/2013 03:59 PM, Alexander Hartmaier wrote:
> I just tried to implement a check for group membership:
>
> AuthAttrDef memberOf,OSC-Group-Identifier-LDAP,check
>
> OSC-Group-Identifier-LDAP is a multi-value attribute derived from
> OSC-Group-Identifier with a PreAuthHook, basically just to transform the
> support groups of a device into the corresponding LDAP CNs.
> According to the trace 4 log the check runs twice but both times using
> the first OSC-Group-Identifier-LDAP value.
> Is this a bug?
I think this is the intended behaviour. The code always fetches a single
value for the named attribute. This means it always gets the first
attribute's value. It does not try to fetch all values of the named
attribute.
Currently you could use a PostSearchHook to do something like this:
my @ldap_groups = $p->get_attr('OSC-Group-Identifier-LDAP');
Since @ldap_groups is an array, you will get all values of
OSC-Group-Identifier-LDAP, not just the first one.
Then you can try each LDAP memberOf attribute value with
OSC-Group-Identifer-LDAP attribute values to see if there's a match:
my $memberof = $entry->get_value('memberOf', asref => 1);
foreach my $group (@$memberof) {
return 1 if (map {lc $group eq lc $_} @ldap_groups);
}
return 0;
Also, we discussed here about adding support for RADIUS attributes that
can be present multiple times. This would mean that e.g., if there are 4
Framed-IP-Address attributes, you could have something like this (flat
file format):
mikem User-Password=fred, %{RequestOr:Framed-IP-Address}=1.2.3.4
This would pass if any of the 4 Framed-IP-Address attributes is 1.2.3.4.
Any comments about how useful you or the others would see this is
appreciated.
Thanks,
Heikki
--
Heikki Vatiainen
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] Radiator Version 4.12.1 released
We are pleased to announce the release of Radiator version 4.12.1 This version contains one bug fix and one enhancement. A bug in AuthBy SQL prevented it from loading with certain configurations. As usual, the new version is available to current licensees from: http://www.open.com.au/radiator/downloads/ and to current evaluators from: http://www.open.com.au/radiator/demo-downloads Licensees with expired access contracts can renew at: http://www.open.com.au/renewal.php An extract from the history file http://www.open.com.au/radiator/history.html is below: - Revision 4.12.1 (2013-09-17) Fixed a bug that prevented AuthBy SQL from loading when it was defined outside of Realm or Handler. Unknown Diameter attribute types are now logged with a warning when Diameter dictionaries are loaded. Diameter encoder and decoder now use Integer32 and Integer64 for signed 32 bit and 64 bit types instead of Signed32 and Signed64. -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
