Re: [RADIATOR] AuthAttrDef for multi-value Radius attribute check
On 09/18/2013 06:03 PM, Alexander Hartmaier wrote: I just saw in the 4.12 ref.pdf that 5.38.16 mentions the type 'request' but 5.43.4 doesn't. You might want to sync the two sections or replace one with a pointer to the other. I updated AuthBy ADSI doc and added a note about GENERIC attributes too. Thanks for spotting this. Heikki -- Heikki Vatiainen h...@open.com.au 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
On 09/17/2013 03:48 PM, Alexander Hartmaier wrote:
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?
You are correct, PostSearchHook does not check return value. Some hooks
use it, such as RequestHook in AuthBy INTERNAL, but it depends on the
hook. I tried to be brief with the example and the return values were
just for illustrative purposes.
The way to reject a user from e.g., PostSearchHook is something like this:
$user-get_check-add_attr('Auth-Type', 'Reject:Not a member of at least
one user group');
return;
See goodies/lookupauthgroup.pl for a full example.
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, noted. Also noted Garry's message. Something like
%{RequestOr:attributename} should be quite straight forward to do and
understand. However, %{RequestAnd:attributename} requires a bit more.
Synatax like this might be a possibility:
mikem User-Password=fred, %{RequestOr:Framed-IP-Address}=1.2.3.4|2.3.4.5
Here the request would be accepted if:
User-Password = fred, and
Framed-IP-Address = 1.2.3.4, and
Framed-IP-Address = 2.3.4.5
As another example, the required values (e.g., 1.2.3.4 and 2.3.4.5)
could come from a multivalued LDAP attribute.
If there are examples how the above would be put in use, please let us know.
Thanks,
Heikki
--
Heikki Vatiainen h...@open.com.au
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
On 09/18/2013 01:14 PM, Heikki Vatiainen wrote:
Thanks, noted. Also noted Garry's message. Something like
%{RequestOr:attributename} should be quite straight forward to do and
understand. However, %{RequestAnd:attributename} requires a bit more.
Synatax like this might be a possibility:
mikem User-Password=fred, %{RequestOr:Framed-IP-Address}=1.2.3.4|2.3.4.5
The above should be RequestAnd like this.
mikem User-Password=fred, %{RequestAnd:Framed-IP-Address}=1.2.3.4|2.3.4.5
Here the request would be accepted if:
User-Password = fred, and
Framed-IP-Address = 1.2.3.4, and
Framed-IP-Address = 2.3.4.5
As another example, the required values (e.g., 1.2.3.4 and 2.3.4.5)
could come from a multivalued LDAP attribute.
If there are examples how the above would be put in use, please let us know.
--
Heikki Vatiainen h...@open.com.au
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
Heikki,
I was under the impression that RquestOr is already supported if one lists
values separated by a space. Are you proposing to change the separator
character to pipe and offering explicit method?
Thanks.
Sent with Good (www.good.com)
-Original Message-
From: Heikki Vatiainen [h...@open.com.aumailto:h...@open.com.au]
Sent: Wednesday, September 18, 2013 10:31 AM Coordinated Universal Time
To: radiator@open.com.au
Subject: Re: [RADIATOR] AuthAttrDef for multi-value Radius attribute check
On 09/18/2013 01:14 PM, Heikki Vatiainen wrote:
Thanks, noted. Also noted Garry's message. Something like
%{RequestOr:attributename} should be quite straight forward to do and
understand. However, %{RequestAnd:attributename} requires a bit more.
Synatax like this might be a possibility:
mikem User-Password=fred, %{RequestOr:Framed-IP-Address}=1.2.3.4|2.3.4.5
The above should be RequestAnd like this.
mikem User-Password=fred, %{RequestAnd:Framed-IP-Address}=1.2.3.4|2.3.4.5
Here the request would be accepted if:
User-Password = fred, and
Framed-IP-Address = 1.2.3.4, and
Framed-IP-Address = 2.3.4.5
As another example, the required values (e.g., 1.2.3.4 and 2.3.4.5)
could come from a multivalued LDAP attribute.
If there are examples how the above would be put in use, please let us know.
--
Heikki Vatiainen h...@open.com.au
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] AuthAttrDef for multi-value Radius attribute check
On 2013-09-18 12:30, Heikki Vatiainen wrote:
On 09/18/2013 01:14 PM, Heikki Vatiainen wrote:
Thanks, noted. Also noted Garry's message. Something like
%{RequestOr:attributename} should be quite straight forward to do and
understand. However, %{RequestAnd:attributename} requires a bit more.
Synatax like this might be a possibility:
mikem User-Password=fred, %{RequestOr:Framed-IP-Address}=1.2.3.4|2.3.4.5
The above should be RequestAnd like this.
mikem User-Password=fred, %{RequestAnd:Framed-IP-Address}=1.2.3.4|2.3.4.5
That makes sense and should be understandable as the syntax follows the
Handler syntax.
Here the request would be accepted if:
User-Password = fred, and
Framed-IP-Address = 1.2.3.4, and
Framed-IP-Address = 2.3.4.5
As another example, the required values (e.g., 1.2.3.4 and 2.3.4.5)
could come from a multivalued LDAP attribute.
If there are examples how the above would be put in use, please let us know.
***
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/18/2013 02:51 PM, Garry Shtern wrote: I was under the impression that RquestOr is already supported if one lists values separated by a space. Are you proposing to change the separator character to pipe and offering explicit method? I was thinking the case below. Here the request has two OSC-AVPAIR attributes. If you have a check item OSC-AVPAIR=attrname1=value1, it will match since Radiator currently takes just the first named attribute. However, if you need to check that OSC-AVPAIR=attrname2=value2, then it fails since the check is once again done against the first attribute. For example, with flat user file syntax, this will match: mikem User-Password=fred, OSC-AVPAIR=attrname1=value1 but this will not match: mikem User-Password=fred, OSC-AVPAIR=attrname2=value2 I think this would be useful for customisation, such as private attributes added for policy checks, cisco-avpair and other attributes that may be present multiple times in a request. Code: Access-Request Identifier: 103 Authentic: P13615223\|K30184?3020121220|4 Attributes: User-Name = mikem Service-Type = Framed-User NAS-IP-Address = 203.63.154.1 NAS-Identifier = 203.63.154.1 NAS-Port = 1234 Called-Station-Id = 123456789 Calling-Station-Id = 987654321 NAS-Port-Type = Async User-Password = ~1521835253~+Rc25+137196164d OSC-AVPAIR = attrname1=value1 OSC-AVPAIR = attrname2=value2 With pipe you can match a request like this: Code: Access-Request Identifier: 103 Authentic: P13615223\|K30184?3020121220|4 Attributes: User-Name = mikem Service-Type = Framed-User NAS-IP-Address = 203.63.154.1 NAS-Identifier = 203.63.154.1 NAS-Port = 1234 Called-Station-Id = 123456789 Calling-Station-Id = 987654321 NAS-Port-Type = Async User-Password = ~1521835253~+Rc25+137196164d OSC-AVPAIR = attrname1=value1 with a user file like this: mikem User-Password=fred, OSC-AVPAIR=attrname1=value1|attrname2=value2 This will allow OSC-AVPAIR to be either attrname1=value1 or attrname2=value2 If you still think space can be used, please provide an example. I'm interested to see if I have missed something :) Thanks, Heikki -- Heikki Vatiainen h...@open.com.au 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
Ah, I was a bit confused. That makes sense now.
This begs a necessity for a method that retrieves all groups a user belongs to
into a multi-value attribute that is checked against with
%{RequestOr:attribute}=Group1|Group2. At least for LDAP.
Thanks.
-Original Message-
From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On
Behalf Of Heikki Vatiainen
Sent: Wednesday, September 18, 2013 9:33 AM
To: 'radiator@open.com.au'
Subject: Re: [RADIATOR] AuthAttrDef for multi-value Radius attribute check
On 09/18/2013 02:51 PM, Garry Shtern wrote:
I was under the impression that RquestOr is already supported if one
lists values separated by a space. Are you proposing to change the
separator character to pipe and offering explicit method?
I was thinking the case below. Here the request has two OSC-AVPAIR attributes.
If you have a check item OSC-AVPAIR=attrname1=value1, it will match since
Radiator currently takes just the first named attribute. However, if you need
to check that OSC-AVPAIR=attrname2=value2, then it fails since the check is
once again done against the first attribute.
For example, with flat user file syntax, this will match:
mikem User-Password=fred, OSC-AVPAIR=attrname1=value1
but this will not match:
mikem User-Password=fred, OSC-AVPAIR=attrname2=value2
I think this would be useful for customisation, such as private attributes
added for policy checks, cisco-avpair and other attributes that may be present
multiple times in a request.
Code: Access-Request
Identifier: 103
Authentic: P13615223\|K30184?3020121220|4
Attributes:
User-Name = mikem
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Identifier = 203.63.154.1
NAS-Port = 1234
Called-Station-Id = 123456789
Calling-Station-Id = 987654321
NAS-Port-Type = Async
User-Password = ~1521835253~+Rc25+137196164d
OSC-AVPAIR = attrname1=value1
OSC-AVPAIR = attrname2=value2
With pipe you can match a request like this:
Code: Access-Request
Identifier: 103
Authentic: P13615223\|K30184?3020121220|4
Attributes:
User-Name = mikem
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Identifier = 203.63.154.1
NAS-Port = 1234
Called-Station-Id = 123456789
Calling-Station-Id = 987654321
NAS-Port-Type = Async
User-Password = ~1521835253~+Rc25+137196164d
OSC-AVPAIR = attrname1=value1
with a user file like this:
mikem User-Password=fred, OSC-AVPAIR=attrname1=value1|attrname2=value2
This will allow OSC-AVPAIR to be either attrname1=value1 or attrname2=value2
If you still think space can be used, please provide an example. I'm interested
to see if I have missed something :)
Thanks,
Heikki
--
Heikki Vatiainen h...@open.com.au
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] AuthAttrDef for multi-value Radius attribute check
On 2013-09-18 16:53, Garry Shtern wrote:
Ah, I was a bit confused. That makes sense now.
This begs a necessity for a method that retrieves all groups a user belongs
to into a multi-value attribute that is checked against with
%{RequestOr:attribute}=Group1|Group2. At least for LDAP.
That's already possible:
AuthAttrDef memberOf, OSC-Group-Identifier-LDAP,request
I just saw in the 4.12 ref.pdf that 5.38.16 mentions the type 'request'
but 5.43.4 doesn't. You might want to sync the two sections or replace
one with a pointer to the other.
Thanks.
-Original Message-
From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On
Behalf Of Heikki Vatiainen
Sent: Wednesday, September 18, 2013 9:33 AM
To: 'radiator@open.com.au'
Subject: Re: [RADIATOR] AuthAttrDef for multi-value Radius attribute check
On 09/18/2013 02:51 PM, Garry Shtern wrote:
I was under the impression that RquestOr is already supported if one
lists values separated by a space. Are you proposing to change the
separator character to pipe and offering explicit method?
I was thinking the case below. Here the request has two OSC-AVPAIR
attributes. If you have a check item OSC-AVPAIR=attrname1=value1, it will
match since Radiator currently takes just the first named attribute. However,
if you need to check that OSC-AVPAIR=attrname2=value2, then it fails since
the check is once again done against the first attribute.
For example, with flat user file syntax, this will match:
mikem User-Password=fred, OSC-AVPAIR=attrname1=value1
but this will not match:
mikem User-Password=fred, OSC-AVPAIR=attrname2=value2
I think this would be useful for customisation, such as private attributes
added for policy checks, cisco-avpair and other attributes that may be
present multiple times in a request.
Code: Access-Request
Identifier: 103
Authentic: P13615223\|K30184?3020121220|4
Attributes:
User-Name = mikem
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Identifier = 203.63.154.1
NAS-Port = 1234
Called-Station-Id = 123456789
Calling-Station-Id = 987654321
NAS-Port-Type = Async
User-Password = ~1521835253~+Rc25+137196164d
OSC-AVPAIR = attrname1=value1
OSC-AVPAIR = attrname2=value2
With pipe you can match a request like this:
Code: Access-Request
Identifier: 103
Authentic: P13615223\|K30184?3020121220|4
Attributes:
User-Name = mikem
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Identifier = 203.63.154.1
NAS-Port = 1234
Called-Station-Id = 123456789
Calling-Station-Id = 987654321
NAS-Port-Type = Async
User-Password = ~1521835253~+Rc25+137196164d
OSC-AVPAIR = attrname1=value1
with a user file like this:
mikem User-Password=fred, OSC-AVPAIR=attrname1=value1|attrname2=value2
This will allow OSC-AVPAIR to be either attrname1=value1 or attrname2=value2
If you still think space can be used, please provide an example. I'm
interested to see if I have missed something :)
Thanks,
Heikki
--
Heikki Vatiainen h...@open.com.au
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
***
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
Hi,
On Wed, 18 Sep 2013, Garry Shtern wrote:
That's not good enough. MemberOf doesn't contain nested groups. In order to
retrieve all the groups a user belongs to, one has to run additional query
against AD:
((objectClass=group)(sAMAccountType=268435456)(member:1.2.840.113556.1.4.1941:=%{user-dn})).
I usually fetch nested groups in a PostSearchHook to AuthLDAP2 and then use a
PostAuthHook to change the result of authentication to whatever I like.
I'll post an example when I get back from on the road.
Greetings
Christian
-Original Message-
From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On
Behalf Of Alexander Hartmaier
Sent: Wednesday, September 18, 2013 11:04 AM
To: radiator@open.com.au
Subject: Re: [RADIATOR] AuthAttrDef for multi-value Radius attribute check
On 2013-09-18 16:53, Garry Shtern wrote:
Ah, I was a bit confused. That makes sense now.
This begs a necessity for a method that retrieves all groups a user belongs
to into a multi-value attribute that is checked against with
%{RequestOr:attribute}=Group1|Group2. At least for LDAP.
That's already possible:
AuthAttrDef memberOf, OSC-Group-Identifier-LDAP,request
I just saw in the 4.12 ref.pdf that 5.38.16 mentions the type 'request'
but 5.43.4 doesn't. You might want to sync the two sections or replace one
with a pointer to the other.
Thanks.
-Original Message-
From: radiator-boun...@open.com.au
[mailto:radiator-boun...@open.com.au] On Behalf Of Heikki Vatiainen
Sent: Wednesday, September 18, 2013 9:33 AM
To: 'radiator@open.com.au'
Subject: Re: [RADIATOR] AuthAttrDef for multi-value Radius attribute
check
On 09/18/2013 02:51 PM, Garry Shtern wrote:
I was under the impression that RquestOr is already supported if one
lists values separated by a space. Are you proposing to change the
separator character to pipe and offering explicit method?
I was thinking the case below. Here the request has two OSC-AVPAIR
attributes. If you have a check item OSC-AVPAIR=attrname1=value1, it will
match since Radiator currently takes just the first named attribute.
However, if you need to check that OSC-AVPAIR=attrname2=value2, then it
fails since the check is once again done against the first attribute.
For example, with flat user file syntax, this will match:
mikem User-Password=fred, OSC-AVPAIR=attrname1=value1
but this will not match:
mikem User-Password=fred, OSC-AVPAIR=attrname2=value2
I think this would be useful for customisation, such as private attributes
added for policy checks, cisco-avpair and other attributes that may be
present multiple times in a request.
Code: Access-Request
Identifier: 103
Authentic: P13615223\|K30184?3020121220|4
Attributes:
User-Name = mikem
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Identifier = 203.63.154.1
NAS-Port = 1234
Called-Station-Id = 123456789
Calling-Station-Id = 987654321
NAS-Port-Type = Async
User-Password = ~1521835253~+Rc25+137196164d
OSC-AVPAIR = attrname1=value1
OSC-AVPAIR = attrname2=value2
With pipe you can match a request like this:
Code: Access-Request
Identifier: 103
Authentic: P13615223\|K30184?3020121220|4
Attributes:
User-Name = mikem
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Identifier = 203.63.154.1
NAS-Port = 1234
Called-Station-Id = 123456789
Calling-Station-Id = 987654321
NAS-Port-Type = Async
User-Password = ~1521835253~+Rc25+137196164d
OSC-AVPAIR = attrname1=value1
with a user file like this:
mikem User-Password=fred, OSC-AVPAIR=attrname1=value1|attrname2=value2
This will allow OSC-AVPAIR to be either attrname1=value1 or
attrname2=value2
If you still think space can be used, please provide an example. I'm
interested to see if I have missed something :)
Thanks,
Heikki
--
Heikki Vatiainen h...@open.com.au
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
***
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
Re: [RADIATOR] AuthAttrDef for multi-value Radius attribute check
I do the same thing. I was simply pointing out that if the multi-value
matching is going to be available, it would help to introduce another method
for group searching into AuthLDAP2 rather than having to rely on
PostSearcHooks...
-Original Message-
From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On
Behalf Of Christian Kratzer
Sent: Wednesday, September 18, 2013 11:26 AM
To: Garry Shtern
Cc: radiator@open.com.au
Subject: Re: [RADIATOR] AuthAttrDef for multi-value Radius attribute check
Hi,
On Wed, 18 Sep 2013, Garry Shtern wrote:
That's not good enough. MemberOf doesn't contain nested groups. In order to
retrieve all the groups a user belongs to, one has to run additional query
against AD:
((objectClass=group)(sAMAccountType=268435456)(member:1.2.840.113556.1.4.1941:=%{user-dn})).
I usually fetch nested groups in a PostSearchHook to AuthLDAP2 and then use a
PostAuthHook to change the result of authentication to whatever I like.
I'll post an example when I get back from on the road.
Greetings
Christian
-Original Message-
From: radiator-boun...@open.com.au
[mailto:radiator-boun...@open.com.au] On Behalf Of Alexander Hartmaier
Sent: Wednesday, September 18, 2013 11:04 AM
To: radiator@open.com.au
Subject: Re: [RADIATOR] AuthAttrDef for multi-value Radius attribute
check
On 2013-09-18 16:53, Garry Shtern wrote:
Ah, I was a bit confused. That makes sense now.
This begs a necessity for a method that retrieves all groups a user belongs
to into a multi-value attribute that is checked against with
%{RequestOr:attribute}=Group1|Group2. At least for LDAP.
That's already possible:
AuthAttrDef memberOf, OSC-Group-Identifier-LDAP,request
I just saw in the 4.12 ref.pdf that 5.38.16 mentions the type 'request'
but 5.43.4 doesn't. You might want to sync the two sections or replace one
with a pointer to the other.
Thanks.
-Original Message-
From: radiator-boun...@open.com.au
[mailto:radiator-boun...@open.com.au] On Behalf Of Heikki Vatiainen
Sent: Wednesday, September 18, 2013 9:33 AM
To: 'radiator@open.com.au'
Subject: Re: [RADIATOR] AuthAttrDef for multi-value Radius attribute
check
On 09/18/2013 02:51 PM, Garry Shtern wrote:
I was under the impression that RquestOr is already supported if one
lists values separated by a space. Are you proposing to change the
separator character to pipe and offering explicit method?
I was thinking the case below. Here the request has two OSC-AVPAIR
attributes. If you have a check item OSC-AVPAIR=attrname1=value1, it will
match since Radiator currently takes just the first named attribute.
However, if you need to check that OSC-AVPAIR=attrname2=value2, then it
fails since the check is once again done against the first attribute.
For example, with flat user file syntax, this will match:
mikem User-Password=fred, OSC-AVPAIR=attrname1=value1
but this will not match:
mikem User-Password=fred, OSC-AVPAIR=attrname2=value2
I think this would be useful for customisation, such as private attributes
added for policy checks, cisco-avpair and other attributes that may be
present multiple times in a request.
Code: Access-Request
Identifier: 103
Authentic: P13615223\|K30184?3020121220|4
Attributes:
User-Name = mikem
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Identifier = 203.63.154.1
NAS-Port = 1234
Called-Station-Id = 123456789
Calling-Station-Id = 987654321
NAS-Port-Type = Async
User-Password = ~1521835253~+Rc25+137196164d
OSC-AVPAIR = attrname1=value1
OSC-AVPAIR = attrname2=value2
With pipe you can match a request like this:
Code: Access-Request
Identifier: 103
Authentic: P13615223\|K30184?3020121220|4
Attributes:
User-Name = mikem
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Identifier = 203.63.154.1
NAS-Port = 1234
Called-Station-Id = 123456789
Calling-Station-Id = 987654321
NAS-Port-Type = Async
User-Password = ~1521835253~+Rc25+137196164d
OSC-AVPAIR = attrname1=value1
with a user file like this:
mikem User-Password=fred, OSC-AVPAIR=attrname1=value1|attrname2=value2
This will allow OSC-AVPAIR to be either attrname1=value1 or
attrname2=value2
If you still think space can be used, please provide an example. I'm
interested to see if I have missed something :)
Thanks,
Heikki
--
Heikki Vatiainen h...@open.com.au
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
Re: [RADIATOR] AuthAttrDef for multi-value Radius attribute check
That's not good enough. MemberOf doesn't contain nested groups. In order to
retrieve all the groups a user belongs to, one has to run additional query
against AD:
((objectClass=group)(sAMAccountType=268435456)(member:1.2.840.113556.1.4.1941:=%{user-dn})).
-Original Message-
From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On
Behalf Of Alexander Hartmaier
Sent: Wednesday, September 18, 2013 11:04 AM
To: radiator@open.com.au
Subject: Re: [RADIATOR] AuthAttrDef for multi-value Radius attribute check
On 2013-09-18 16:53, Garry Shtern wrote:
Ah, I was a bit confused. That makes sense now.
This begs a necessity for a method that retrieves all groups a user belongs
to into a multi-value attribute that is checked against with
%{RequestOr:attribute}=Group1|Group2. At least for LDAP.
That's already possible:
AuthAttrDef memberOf, OSC-Group-Identifier-LDAP,request
I just saw in the 4.12 ref.pdf that 5.38.16 mentions the type 'request'
but 5.43.4 doesn't. You might want to sync the two sections or replace one with
a pointer to the other.
Thanks.
-Original Message-
From: radiator-boun...@open.com.au
[mailto:radiator-boun...@open.com.au] On Behalf Of Heikki Vatiainen
Sent: Wednesday, September 18, 2013 9:33 AM
To: 'radiator@open.com.au'
Subject: Re: [RADIATOR] AuthAttrDef for multi-value Radius attribute
check
On 09/18/2013 02:51 PM, Garry Shtern wrote:
I was under the impression that RquestOr is already supported if one
lists values separated by a space. Are you proposing to change the
separator character to pipe and offering explicit method?
I was thinking the case below. Here the request has two OSC-AVPAIR
attributes. If you have a check item OSC-AVPAIR=attrname1=value1, it will
match since Radiator currently takes just the first named attribute. However,
if you need to check that OSC-AVPAIR=attrname2=value2, then it fails since
the check is once again done against the first attribute.
For example, with flat user file syntax, this will match:
mikem User-Password=fred, OSC-AVPAIR=attrname1=value1
but this will not match:
mikem User-Password=fred, OSC-AVPAIR=attrname2=value2
I think this would be useful for customisation, such as private attributes
added for policy checks, cisco-avpair and other attributes that may be
present multiple times in a request.
Code: Access-Request
Identifier: 103
Authentic: P13615223\|K30184?3020121220|4
Attributes:
User-Name = mikem
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Identifier = 203.63.154.1
NAS-Port = 1234
Called-Station-Id = 123456789
Calling-Station-Id = 987654321
NAS-Port-Type = Async
User-Password = ~1521835253~+Rc25+137196164d
OSC-AVPAIR = attrname1=value1
OSC-AVPAIR = attrname2=value2
With pipe you can match a request like this:
Code: Access-Request
Identifier: 103
Authentic: P13615223\|K30184?3020121220|4
Attributes:
User-Name = mikem
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Identifier = 203.63.154.1
NAS-Port = 1234
Called-Station-Id = 123456789
Calling-Station-Id = 987654321
NAS-Port-Type = Async
User-Password = ~1521835253~+Rc25+137196164d
OSC-AVPAIR = attrname1=value1
with a user file like this:
mikem User-Password=fred, OSC-AVPAIR=attrname1=value1|attrname2=value2
This will allow OSC-AVPAIR to be either attrname1=value1 or
attrname2=value2
If you still think space can be used, please provide an example. I'm
interested to see if I have missed something :)
Thanks,
Heikki
--
Heikki Vatiainen h...@open.com.au
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
***
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
___
radiator mailing list
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 h...@open.com.au
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
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 h...@open.com.au
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
