multiple Autz-Type

wekz fbl.list at gmail.com
Wed Jun 7 09:34:06 CEST 2006


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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20060607/def4d4d1/attachment.html>


More information about the Freeradius-Users mailing list