2006/6/7, wekz <fbl.list@gmail.com>:

Thanks very much Phil. That works, I think it doesn't work in the hints file for the reasons you told me.

Now I've got a new problem. I use the radiusGroupName for making the users belong to VLAN1, VLAN2 or VLAN3. So I enable

         groupmembership_attribute = radiusGroupName

but I left groupname_attribute and groupmembership_filter commented ( in each ldap module ).

In other file called users-vlan I defined this:

   DEFAULT Ldap-Group == Local
                  stuff for assigning VLAN1
   .....
The file that determine the users procedence is users-procedence:

   DEFAULT NAS-IP-Address == 192.168.51.yy, Autz-Type=customer1
   .....

The file that proxies ( users-proxy ):
   DEFAULT proxy-to-realm:=CENTRAL

The authorization section:
....
users-procedence

autztype customer1{
                redundant {
                        group {
                                ldap1 {
          notfound = return
                                        fail = return
                                }
                                users-vlan

                                mschap
                                eap
                                notfound = 1
                                fail = 1
                        }
                        users-proxy
                }
        }
.....

The situation is: a user that must be authorized against ldap2 make a match in the users-procedence file and get customer2 autztype. So the user is looked for in ldap2.

          1.- If it fails in the logs I could see radius looking for ldap_groupcmp() in ldap3 when all I think it must do is proxy.
          2.- In case the user is found it make a search too for ldap group in ldap3.

I think in the first case there are two problems: it searches when it doesn't have to ( unnecessary search ), and it searches bad because it does in the last ldap instantiated ( that is ldap3 )

In the second case the problem is that it searches in the last ldap instantiated.

(( This configuration works fine when all you have is one ldap ))

Is that a bug ?? I found a similar bug in bug-list but it belongs to version 1.0.1 ( bug #163, about unnecessary searches ) and I think a read a bug about searching in the last ldap instantiated ( but I think this has to be with older versions and I can't find it )

I solved this problem yesterday but I don't know how to say... I solved it in a dirty-way ( I hope you understand ). So if you or anyone have an idea ...

2006/6/5, Phil Mayers < p.mayers@imperial.ac.uk>:
wekz wrote:
>
> I don't know if I have explain it correctly, if I haven't just tell me (
> I'm not an english speaker )

Your english is great.

> My hints file:

Nearly there. Try:

DEFAULT NAS-IP-Address == 192.168.xx.yy, Autz-Type := LDAPx

I'm not sure that'll work in a hints file - so you may need to use a
"users" file - hints puts items into the request pairs, Autz-Type needs
to go into the configure pairs.

Try this:

modules {
   # other stuff
   files filesFirst {
     usersfile = ${confdir}/usersFirst
   }
}

authorize {
   preprocess
   filesFirst
   Autz-Type LDAP1 {
     # stuff here
     ldap1
   }
   # other LDAP modules
}

And in ${confdir}/usersFirst:

DEFAULT NAS-IP-Address == 192.168.51.xx, Autz-Type := LDAP1

DEFAULT NAS-IP-Address == 192.168.51.yy, Autz-Type := LDAP2

...and so on.

The other slightly simpler way might be to use a "passwd" (badly named)
module, e.g.:

modules {
   passwd nas2autz {
     filename = ${confdir}/nas2autz
     format = "*NAS-IP-Address:Autz-Type"
     # set to 0 to read file on every request - slow
     # but instant-updates
     hashsize = 100
   }
}

authorize {
   preprocess
   nas2autz
   Autz-Type LDAP1 {
     ldap1
   }
   # other Autz
}

...and in ${confdir}/nas2autz

192.168.51.xx:LDAP1
192.168.51.yy:LDAP2

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