Re: ldap attribute, checkItem, and the users file

classic Classic list List threaded Threaded
5 messages Options
| Threaded
Open this post in threaded view
|

Re: ldap attribute, checkItem, and the users file

Alexei Chetroi
On Mon, May 23, 2005 at 03:29:33PM -0400, Chris Carver wrote:
> Date: Mon, 23 May 2005 15:29:33 -0400
> From: Chris Carver <[hidden email]>
> Subject: ldap attribute, checkItem, and the users file
>
> I'm still struggling with a problem I wrote in about in the past.  I
> will explain what I am trying to do as well as possible.
 [snip]

> The definition is in the "netsweeper" file, along with other attributes
> of ours, and its contents are as follows:
>
> VENDOR          SlipStream              7000
>
> ATTRIBUTE       SlipStream-Enabled      1       string  SlipStream
> ATTRIBUTE       NetSweeper-Enabled      2       string  SlipStream
> ATTRIBUTE       redirectPort80          3       string  SlipStream
>
> After ensuring that the attribute was defined on the ldap side and the
> radius side, I understood that I needed to modify ldap.attrmap and add a
> checkItem.  Here is that change in etc/raddb/ldap.attrmap:
>
> checkItem       redirectPort80                  radiusRedirectPort80
>
> I did not add a reply item, because I'm not replying with the value of
> that attribute.  I'm performing logic in the users file on that value
> and THEN passing back attribute/value pairs specified in the users file.
>
> My next step was to finally modify the users file.  Here is a change to
> the users file:
>
> DEFAULT redirectPort80 == true
>        Framed-Route = "0.0.0.0/0 205.247.236.1/32 1",
>        Fall-Through = yes
>        <other irrelevant lines removed>
>
> To my knowledge, at this point if the user has the ldap attribute
> "radiusRedirectPort80: true" then Framed-Route attribute/value should be
> in the access-accept.  I do a radtest with a user who has the ldap
> attribute radiusRedirectPort80 set to true, and it is not matched.  I
> see exactly the same behavior as with a user who does not have the
> attribute.

  Have you ran freeradius with debug switches to see with which operator
ldap module adds redirectPort80 pair?
  Have you tried to make ldap attribute radiusRedirectPort80 with
":=true" value?

  Best wishes

--
Alexei Chetroi

Smile... Tomorrow will be worse. (c) Murphy's Law

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: ldap attribute, checkItem, and the users file

Kostas Kalevras
On Mon, 23 May 2005, Chris Carver wrote:

> Hello,
>
> I'm still struggling with a problem I wrote in about in the past.  I will
> explain what I am trying to do as well as possible.
>
> We have customers authenticating through our radius server which uses an
> openldap backend.  Each user has an entry in our ldap database and it is the
> only means of authentication.  We want to be able to check for the existance
> of an ldap attribute in the users file for the user who is currently trying
> to authenticate.  If the attribute is found, we add a radius attribute to the
> reply and fall-through.  If it is not found, those lines are bypassed and
> logic will continue down the users file.
>
> This ldap attribute is our own creation and we modified the schema calling
> the attribute "radiusRedirectPort80" on the ldap backend.  Its tested and it
> works perfectly on the ldap end.  I modified the dictionary file and it is
> called "redirectPort80" on the radius side.  Following is
> etc/raddb/dictionary:
>
> $INCLUDE /usr/local/pw/freeradius-1.0.2/share/freeradius/dictionary
> $INCLUDE /usr/local/pw/freeradius-1.0.2/etc/raddb/netsweeper
>
> The definition is in the "netsweeper" file, along with other attributes of
> ours, and its contents are as follows:
>
> VENDOR          SlipStream              7000
>
> ATTRIBUTE       SlipStream-Enabled      1       string  SlipStream
> ATTRIBUTE       NetSweeper-Enabled      2       string  SlipStream
> ATTRIBUTE       redirectPort80          3       string  SlipStream
>
> After ensuring that the attribute was defined on the ldap side and the radius
> side, I understood that I needed to modify ldap.attrmap and add a checkItem.
> Here is that change in etc/raddb/ldap.attrmap:
>
> checkItem       redirectPort80                  radiusRedirectPort80
>
> I did not add a reply item, because I'm not replying with the value of that
> attribute.  I'm performing logic in the users file on that value and THEN
> passing back attribute/value pairs specified in the users file.
>
> My next step was to finally modify the users file.  Here is a change to the
> users file:
>
> DEFAULT redirectPort80 == true
>       Framed-Route = "0.0.0.0/0 205.247.236.1/32 1",
>       Fall-Through = yes
>       <other irrelevant lines removed>
>
> To my knowledge, at this point if the user has the ldap attribute
> "radiusRedirectPort80: true" then Framed-Route attribute/value should be in
> the access-accept.  I do a radtest with a user who has the ldap attribute
> radiusRedirectPort80 set to true, and it is not matched.  I see exactly the
> same behavior as with a user who does not have the attribute.
> Am I doing something fundamentally wrong?  If not, might there be any common
> mistakes I could be making?  I would be grateful for any pointers.  Thanks in
> advance.


The users file will only check attributes in the request, not in the check item
list. So the above won't work. You can try using the policy module:

if ("%{check:redirectPort80}" == "true") {
  reply .= {
  Framed-Route = "0.0.0.0/0 205.247.236.1/32 1"
  }
}

>
> Chris Carver
>
> - List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>

--
Kostas Kalevras Network Operations Center
[hidden email] National Technical University of Athens, Greece
Work Phone: +30 210 7721861
'Go back to the shadow' Gandalf

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: ldap attribute, checkItem, and the users file

Christopher Carver
Kostas Kalevras wrote:

> On Mon, 23 May 2005, Chris Carver wrote:
>
>> Hello,
>>
>> I'm still struggling with a problem I wrote in about in the past.  I
>> will explain what I am trying to do as well as possible.
>>
>> We have customers authenticating through our radius server which uses
>> an openldap backend.  Each user has an entry in our ldap database and
>> it is the only means of authentication.  We want to be able to check
>> for the existance of an ldap attribute in the users file for the user
>> who is currently trying to authenticate.  If the attribute is found,
>> we add a radius attribute to the reply and fall-through.  If it is
>> not found, those lines are bypassed and logic will continue down the
>> users file.
>>
>> This ldap attribute is our own creation and we modified the schema
>> calling the attribute "radiusRedirectPort80" on the ldap backend.  
>> Its tested and it works perfectly on the ldap end.  I modified the
>> dictionary file and it is called "redirectPort80" on the radius
>> side.  Following is etc/raddb/dictionary:
>>
>> $INCLUDE /usr/local/pw/freeradius-1.0.2/share/freeradius/dictionary
>> $INCLUDE /usr/local/pw/freeradius-1.0.2/etc/raddb/netsweeper
>>
>> The definition is in the "netsweeper" file, along with other
>> attributes of ours, and its contents are as follows:
>>
>> VENDOR          SlipStream              7000
>>
>> ATTRIBUTE       SlipStream-Enabled      1       string  SlipStream
>> ATTRIBUTE       NetSweeper-Enabled      2       string  SlipStream
>> ATTRIBUTE       redirectPort80          3       string  SlipStream
>>
>> After ensuring that the attribute was defined on the ldap side and
>> the radius side, I understood that I needed to modify ldap.attrmap
>> and add a checkItem. Here is that change in etc/raddb/ldap.attrmap:
>>
>> checkItem       redirectPort80                  radiusRedirectPort80
>>
>> I did not add a reply item, because I'm not replying with the value
>> of that attribute.  I'm performing logic in the users file on that
>> value and THEN passing back attribute/value pairs specified in the
>> users file.
>>
>> My next step was to finally modify the users file.  Here is a change
>> to the users file:
>>
>> DEFAULT redirectPort80 == true
>>       Framed-Route = "0.0.0.0/0 205.247.236.1/32 1",
>>       Fall-Through = yes
>>       <other irrelevant lines removed>
>>
>> To my knowledge, at this point if the user has the ldap attribute
>> "radiusRedirectPort80: true" then Framed-Route attribute/value should
>> be in the access-accept.  I do a radtest with a user who has the ldap
>> attribute radiusRedirectPort80 set to true, and it is not matched.  I
>> see exactly the same behavior as with a user who does not have the
>> attribute. Am I doing something fundamentally wrong?  If not, might
>> there be any common mistakes I could be making?  I would be grateful
>> for any pointers.  Thanks in advance.
>
>
>
> The users file will only check attributes in the request, not in the
> check item list. So the above won't work. You can try using the policy
> module:
>
> if ("%{check:redirectPort80}" == "true") {
>     reply .= {
>         Framed-Route = "0.0.0.0/0 205.247.236.1/32 1"
>     }
> }


Thank you for the reply!  The logic I see there should definitely work,
but I'm still a bit confused.  I did some research and I'm having any
trouble finding mention of the policy module you mention.  Although
doc/variables.txt was very helpful, it doesn't show any use of an if
statement and I'm not sure in what configuration file(s) such a piece of
code would be acceptable.  Where would I put the lines you mentioned
above?  Sorry if I'm making a silly mistake or overlooking something.

>
>>
>> Chris Carver
>>
>> - List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>>
>
> --
> Kostas Kalevras        Network Operations Center
> [hidden email]    National Technical University of Athens, Greece
> Work Phone:        +30 210 7721861
> 'Go back to the shadow'    Gandalf
>
> - List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: ldap attribute, checkItem, and the users file

Alexei Chetroi
On Tue, May 24, 2005 at 02:00:28PM -0400, Chris Carver wrote:
> Date: Tue, 24 May 2005 14:00:28 -0400
> From: Chris Carver <[hidden email]>
> Subject: Re: ldap attribute, checkItem, and the users file
>
> Kostas Kalevras wrote:
 [snip]

> >The users file will only check attributes in the request, not in the
> >check item list. So the above won't work. You can try using the policy
> >module:
> >
> >if ("%{check:redirectPort80}" == "true") {
> >    reply .= {
> >        Framed-Route = "0.0.0.0/0 205.247.236.1/32 1"
> >    }
> >}
>
>
> Thank you for the reply!  The logic I see there should definitely work,
> but I'm still a bit confused.  I did some research and I'm having any
> trouble finding mention of the policy module you mention.  Although
> doc/variables.txt was very helpful, it doesn't show any use of an if
> statement and I'm not sure in what configuration file(s) such a piece of
> code would be acceptable.  Where would I put the lines you mentioned
> above?  Sorry if I'm making a silly mistake or overlooking something.

  I see there no policy module in freeradius version 1.0.2, but there's
one in CVS HEAD.

  Although I wouldn't mind to have a list of "check items" in addition
to request items, config items and reply items. So authorization modules
puts items to be checked into "check items" list and after proccessing
all modules, radius compares "check items" with "request items". What do
you think about this?

  Best wishes

--
Alexei Chetroi

Smile... Tomorrow will be worse. (c) Murphy's Law

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: ldap attribute, checkItem, and the users file

Alan DeKok
Alexei Chetroi <[hidden email]> wrote:
>   Although I wouldn't mind to have a list of "check items" in addition
> to request items, config items and reply items. So authorization modules
> puts items to be checked into "check items" list and after proccessing
> all modules, radius compares "check items" with "request items". What do
> you think about this?

  No.  Each module implements it's own version of "check items". The
reason that it doesn't work for the "users" file is that the "users"
file gets it wrong.

  The policy module doesn't.  The "check items" you're asking for are
the policy scripts you write, to update config/request/reply items.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html