Re: Troube with matching LDAP group membership in authorize

30 Jan 2007

      Nevermind I found the problem. There's a limitation in ldap_groupcmp() such that only the last LDAP module instantiated is actually checked -- ignoring whatever you specify. I found this info from http://lists.cistron.nl/pipermail/freeradius-users/2004-June/033220.html. 

"In any case the ldap module which will be
instantiated last will be the one that will handle ldap-group comparisons. If we

add a check that will change to the first ldap module which is instantiated. I
think it's more or less a matter of personal taste, which module we 'd like to
handle ldap-group comparisons. Is it really worth the effort. Users can just
change the order in which the ldap modules are
instantiated in order to achieve
what they want."

Rather disappointing that this limitation still exists from 2 years ago. Does FR2.0 have some sort of object-based virtualization that would support this? Like, a "LDAP group" object which you could tie LDAP instances to and make the check there?

-richard

----- Original Message ----

From: Richard Hesse <rhesse@yahoo.com>

To: freeradius-users@lists.freeradius.org

Sent: Tuesday, January 30, 2007 12:40:36 PM

Subject: Troube with matching LDAP group membership in authorize

I'm trying to setup radius authentication for enable access on our networking gear and having a tough time getting a working config. I'd like to have FR check a group in LDAP for membership before authorizing. That is, I only want user's listed in the "uniquemember" attribute of the Operations group object to be granted access. Reading the FR docs this is possible -- I must be missing something. First, here are the relevant portions of my configs:

Hint file:

DEFAULT NAS-Port-Type == Virtual, Service-Type == NAS-Prompt-User, ldap_enable-Ldap-Group := "operations", Autz-Type := ldap_enable, Auth-Type := LDAP

radius.conf:

        ldap ldap_enable{

                server = "fds1.hq.powerset.com"

                basedn = "dc=powerset,dc=com"

                filter = "(uid=%{Stripped-User-Name:-%{User-Name}})"

                start_tls = yes

                tls_cacertfile  = /opt/fedora-ds/alias/starfield.pem

                tls_require_cert        = "demand"

                # Mapping of RADIUS dictionary attributes to LDAP

                # directory attributes.

                dictionary_mapping = ${raddbdir}/ldap.attrmap

                ldap_connections_number = 5

        #       ldap_debug = 1

        #        groupname_attribute = cn

                groupmembership_filter = "(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn}))"

                timeout = 4

                timelimit = 3

                net_timeout = 3

                # compare_check_items = yes

                # do_xlat = yes

                access_attr_used_for_allow = no

                set_auth_type = no

        }

I have several LDAP instances defined in radius.config, but this is the one I want to use. I instantiate it first in radius.config so that hints can use it:

instantiate {

        ldap_enable

        exec

        expr

}

And a corresponsing Autz-Type in radius.config:

authorize {

        preprocess

        suffix

        ntdomain

        eap

        autztype ldap{

                redundant {

                        fds1

                #        fds2

                }

        }

        autztype ldap_enable{

                ldap_enable

        }

        files

        pap

}

Here's the debug output from when I try and connect:

rad_recv: Access-Request packet from host 64.13.145.238:1024, id=96, length=71

        User-Name = "dick"

        User-Password = "$$$$$$$$"

        NAS-IP-Address = 64.13.145.238

        NAS-Identifier = "h2848-1"

        NAS-Port-Type = Virtual

        Service-Type = NAS-Prompt-User

  Processing the authorize section of radiusd.conf

modcall: entering group authorize for request 0

  hints: Matched DEFAULT at 35  <--- This is the correct entry

  modcall[authorize]: module "preprocess" returns ok for request 0

    rlm_realm: No '@' in User-Name = "dick", looking up realm NULL

    rlm_realm: No such realm "NULL"

  modcall[authorize]: module "suffix" returns noop for request 0

    rlm_realm: No '\' in User-Name = "dick", looking up realm NULL

    rlm_realm: No such realm "NULL"

  modcall[authorize]: module "ntdomain" returns noop for request 0

  rlm_eap: No EAP-Message, not doing EAP

  modcall[authorize]: module "eap" returns noop for request 0

  modcall[authorize]: module "files" returns notfound for request 0

rlm_pap: WARNING! No "known good" password found for the user.  Authentication may fail because of this.

  modcall[authorize]: module "pap" returns noop for request 0

modcall: leaving group authorize (returns ok) for request 0

It appears that FR is ignoring the Autz-Type I set in hints and just processes the entries in authorize in sequential order. This is the default behavior unless an Autz-Type is explicitly set (which I do in hints). How do I get the Autz-Type to kick-in and have FR send the request to the proper LDAP entry?

Thanks in advance,

-richard

____________________________________________________________________________________

Sucker-punch spam with award-winning protection. 

Try the free Yahoo! Mail Beta.

http://advision.webevents.yahoo.com/mailbeta/features_spam.html

____________________________________________________________________________________
Now that's room service!  Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097