Searching Subcontexts in eDir

[Mearl Danner]

Check the filter statement in the ldap portion of radiusd.conf. It's searching on "uid" which in eDirectory is an integer field and isn't populated by default.

Change the filter to filter = "(cn=%{Stripped-User-Name:-%{User-Name}})" and try it. That will get you past the "object not found" message. It will then be able to return the fully qualified DN of the user.

You can search on "cn" or any other ldap field that contains a unique ID. We're probably going to use uniqueID - the newer user creation API's populate it by default - in our environment because iPrint requires it.

Mearl

>>> jp at joshmp.com 7/19/2005 1:10:08 PM >>>
I am running FreeRADIUS 1.0.4 on FreeBSD 4.11 authenticate/authorize users via
LDAP on a NetWare 6.5 server/tree.

I can successfully authenticate and authorize users if they reside in the root
context (o=<rootcontext>), but authorize fails if the user is in an ou in the
root context.  The "identity" user in the ldap modules section is an admin
equivalent.

Also, if I change the basedn to the subcontext
(ou=<subcontext>,o=<rootcontext>), it still fails.

Relevant info from radtest:

-----snip-----
radtest gwaccesspo1 <password> localhost 10 testing123
-----snip-----

The gwaccesspo1 user's context is as follows:
cn=gwacesspo1,ou=gw,o=services


Relevant info from radiusd.conf:

-----snip-----
server = "10.254.8.25"
identity = "cn=raduser,o=services"
password = "<password>"
basedn = "o=services"
filter = "(uid=%{Stripped-User-Name:-%{User-Name}})"
-----snip-----

raduser.services is an admin equivalent.


Relevant info from debug:

-----snip-----
rlm_ldap: - authorize
rlm_ldap: performing user authorization for gwaccesspo1
radius_xlat:  '(uid=gwaccesspo1)'
radius_xlat:  'o=services'
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 10.254.8.25:389, authentication 0
rlm_ldap: bind as cn=raduser,o=services/<password> to 10.254.8.25:389
rlm_ldap: waiting for bind result ...
rlm_ldap: Bind was successful
rlm_ldap: performing search in o=services, with filter (uid=gwaccesspo1)
rlm_ldap: object not found or got ambiguous search result
rlm_ldap: search failed
-----snip-----

The "gwaccesspo1" user above resides in ou=gw,o=services.  As mentioned above,
even if I set the basedn to ou=gw,o=services, I still get the "object not found"
error.

Thanks in advance for any suggestions.

Josh
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html