LDAP related questions

[Kostas Zorbadelos]

Hello to everyone.

I have a question regarding a configuration I am trying to achieve. I
have users stored in an ldap database. An example user entry looks
like this:

dn: uid=kzorba,ou=people,dc=company,dc=gr
cn: ZORBADELOS KONSTANTINOS
uid: kzorba
clearTextPwd: mypassword
radiusProfile: PSTN_STATIC
radiusAccountStatus: activated
radiusMaxLogins: 1
radiusExpDate: 2030/12/31 00:00:00
Framed-IP-Address: 62.103.176.39
objectClass: account
objectClass: MyRadiusAccount
objectClass: top

Tha attribute radiusProfile groups the users. For each group we have a
corresponding profile

# PSTN_STATIC, radiusProfiles, company.gr
dn: cn=PSTN_STATIC,ou=radiusProfiles,dc=company,dc=gr
cn: PSTN_STATIC
objectClass: freeradiusProfile
objectClass: top
radiusNASPortType: Async
radiusFramedProtocol: PPP
radiusCisco-AVPair: lcp:interface-config#1=ip vrf forwarding STATIC_USER
radiusCisco-AVPair: lcp:interface-config#2=ip unnumbered Loopback1001
radiusServiceType: Framed

Now, I want to authorize the user according to this information. I
have read and tried the configuration described in ldap_howto.txt
shipped in the freeradius distribution. It uses the Ldap-Group
attribute and the users file. This configuration is sub-optimal
because it generates many ldap queries trying to figure out in which
group a user belongs. If we have many entries in the users file, one
for each group, each entry will generate a couple of queries until the
matching entry is found. So if we have, for example, a hundred groups
and the last one in the users file matches, we will have generated ~200
ldap queries, just to find the group the user belongs to.

I try the following alternative approach:

#ldap.attrmap
checkItem       Group                           radiusProfile

#users file
...
DEFAULT Group == PSTN_STATIC, User-Profile := "cn=PSTN_DYNAMIC,ou=radiusProfiles,dc=company,dc=gr"
        Fall-Through = no
DEFAULT Auth-Type := Reject
        Reply-Message = "Unauthorized access."


#radiusd.conf

authorize {
        preprocess
        chap
        mschap
        suffix
        ldap
        files
        ldap
}


In the first pass through the ldap module I want to set the Group
attribute, then in users file set the User-Profile and I use one more
pass through the ldap module to get the profile attributes. However
this is what I get when testing with radclient:

rad_recv: Access-Request packet from host 127.0.0.1:41392, id=167, length=52
        User-Name = "kzorba"
        User-Password = "XXXXXX"
        NAS-IP-Address = 62.103.0.99
  Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 0
  modcall[authorize]: module "preprocess" returns ok for request 0
  modcall[authorize]: module "chap" returns noop for request 0
  modcall[authorize]: module "mschap" returns noop for request 0
    rlm_realm: No '@' in User-Name = "kzorba", looking up realm NULL
    rlm_realm: Found realm "NULL"
    rlm_realm: Adding Stripped-User-Name = "kzorba"
    rlm_realm: Proxying request from user kzorba to realm NULL
    rlm_realm: Adding Realm = "NULL"
    rlm_realm: Authentication realm is LOCAL.
  modcall[authorize]: module "suffix" returns noop for request 0
rlm_ldap: - authorize
rlm_ldap: performing user authorization for kzorba
radius_xlat:  '(&(uid=kzorba)(objectClass=MyRadiusAccount)(radiusAccountStatus=activated))'
radius_xlat:  'ou=people,dc=company,dc=gr'
rlm_ldap: ldap_get_conn: Checking Id: 0
rlm_ldap: ldap_get_conn: Got Id: 0
rlm_ldap: attempting LDAP reconnection
rlm_ldap: (re)connect to ldapserver.company.gr:489, authentication 0
rlm_ldap: bind as cn=Directory Manager/XXXXXX to ldapserver.company.gr:489
rlm_ldap: waiting for bind result ...
rlm_ldap: Bind was successful
rlm_ldap: performing search in ou=people,dc=company,dc=gr, with filter (&(uid=kzorba)(objectClass=MyRadiusAccount)(radiusAccountStatus=activated))
rlm_ldap: Added password XXXXXX in check items
rlm_ldap: looking for check items in directory...
rlm_ldap: Adding radiusProfile as Group, value PSTN_STATIC & op=21
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
rlm_ldap: Adding radiusMaxLogins as Simultaneous-Use, value 1 & op=21
rlm_ldap: looking for reply items in directory...
rlm_ldap: Adding Framed-IP-Address as Framed-IP-Address, value 62.103.176.39 & op=11
rlm_ldap: user kzorba authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
  modcall[authorize]: module "ldap" returns ok for request 0
    users: Matched entry DEFAULT at line 82
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^(?)
Here, the files module does not match the line with the Group == PSTN_STATIC 
condition, but the last DEFAULT line that rejects the user

  modcall[authorize]: module "files" returns ok for request 0
rlm_ldap: - authorize
rlm_ldap: performing user authorization for kzorba
radius_xlat:  '(&(uid=kzorba)(objectClass=MyRadiusAccount)(radiusAccountStatus=activated))'
radius_xlat:  'ou=people,dc=company,dc=gr'
rlm_ldap: ldap_get_conn: Checking Id: 0
rlm_ldap: ldap_get_conn: Got Id: 0
rlm_ldap: performing search in ou=people,dc=company,dc=gr, with filter (&(uid=kzorba)(objectClass=MyRadiusAccount)(radiusAccountStatus=activated))
rlm_ldap: looking for check items in directory...
rlm_ldap: Adding radiusProfile as Group, value PSTN_STATIC & op=21
rlm_ldap: Adding radiusMaxLogins as Simultaneous-Use, value 1 & op=21
rlm_ldap: looking for reply items in directory...
rlm_ldap: Adding Framed-IP-Address as Framed-IP-Address, value 62.103.176.39 & op=11
rlm_ldap: user kzorba authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
  modcall[authorize]: module "ldap" returns ok for request 0
modcall: leaving group authorize (returns ok) for request 0
  rad_check_password:  Found Auth-Type Reject
  rad_check_password: Auth-Type = Reject, rejecting user
auth: Failed to validate the user.
Delaying request 0 for 1 seconds
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Sending Access-Reject of id 167 to 127.0.0.1 port 41392
        Reply-Message = "Unauthorized access."
Nothing to do.  Sleeping until we see a request.


My questions are:

- Does this approach have a meaning?
- Why the Group attribute returned through LDAP does not match the
  correct entry in users file? 
- Are there any alternative ideas to achieve the setup I want (users +
  profiles stored in LDAP with the form of the user entry as I
  described)    

Thanks in advance for any answers. 

Kostas

-- 
  Kostas Zorbadelos
  m at il contact: kzorba (at) otenet.gr
  
  Out there in the darkness, out there in the night
  out there in the starlight, one soul burns brighter
  than a thousand suns.