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: P<136><15><223>\|K<30><184>?<30><201><212><20>|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 = ~<152><183><5><253>~+Rc<25>+<137><196>><164>d
>> OSC-AVPAIR = "attrname1=value1"
>> OSC-AVPAIR = "attrname2=value2"
>>
>>
>>
>> With pipe you can match a request like this:
>>
>> Code: Access-Request
>> Identifier: 103
>> Authentic: P<136><15><223>\|K<30><184>?<30><201><212><20>|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 = ~<152><183><5><253>~+Rc<25>+<137><196>><164>d
>> 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
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
--
Christian Kratzer CK Software GmbH
Email: c...@cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer
_______________________________________________
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
