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
[EMAIL PROTECTED]    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

Reply via email to