[Auth_ldap] Group authentication

[Richard Ellerbrock]

>"Richard Ellerbrock" <richarde at eskom.co.za> writes:
>
>> The way that I thought it would work was to just hit the
>> group and scan each member for a match and then authenticate. From my
>> understanding of LDAP and trees, the group will already give you all
>> the info you need without having to do a search. A group cannot
>> contain an object that does not exist in the tree - this is the way
>> the Novell implementation works! If the object is deleted, the object
>> will vanish from the group.
>
>No, auth_ldap doesn't work this way. Plus, you still have to
>authenticate at some point. So, you would have to match up a DN in the
>group with the user name that the HTTP client provided and then attempt
>a bind with that DN and the password provided by the HTTP client.
>
>But this approach would not work at all for many sites. Consider the
>following directory:
>
> dn: cn=Dave Carrigan, ou=People, dc=rudedog, dc=org
> uid: dave
> cn: Dave Carrigan
>
> dn: cn=Joe Smith, ou=People, dc=rudedog, dc=org
> uid: joe
> cn: Joe Smith
>
> dn: cn=Valid Users, ou=Groups, dc=rudedog, dc=org
> cn: Valid Users
> uniqueMember: cn=Dave Carrigan, ou=People, dc=rudedog, dc=org
> uniqueMember: cn=Joe Smith, ou=People, dc=rudedog, dc=org
>
>If I use the following auth_ldap directives:
>
>  AuthLDAPURL ldap://ldap.rudedog.org/dc=rudedog, dc=org?uid
>  require group cn=Valid Users, ou=Groups, dc=rudedog, dc=org
>
>There is no way that auth_ldap can possibly match the DN's listed in the
>group with the uid passed by the HTTP client. So if it were to take the
>"iterate the group" approach, it would have to try each entry in turn,
>fetch that entry to ensure that its uid was correct, and then attempt to
>bind using that entry and the password from the client. This would be
>even slower than the current implementation.

Yes, I see the problem. It would only work if the search was only on the cn and nothing else. Kinda defeats the object of being able to authenticate against any attribute.

>Unfortunately, I don't know a lot about NDS installations, so I don't
>know if there's a good solution for you. Would it be possible to have a
>central NDS server that consists of nothing but referrals to entries on
>the real servers? Then, you could point auth_ldap at that server for
>fast searches, but still keep your distributed servers for the
>authentication part.

In NDS speak that is referred to as a replica of part of the tree. We do have some of our tree replicated centrally, but the tax on the network and resources required on the central servers would be way to much to accomodate all the info. As it is, we have two pretty huge servers (PIII 800's with 30gigs disk and 1gig mem) to accomodate our current needs.

>If that's not possible, you could look at modifying auth_ldap so that it
>performs the way you would like. If the patches are clean and preserves
>existing behavior, I will consider them for inclusion into the 1.5.x
>version.

I have looked at the source, but could only figure out where the match is done for the group in the .htaccess file. After that I got lost! Maybe I should spend some more time on it.

I have compiled 1.5 on a test box a while ago and it worked. Trying to compile 1.5 on my production machine fails for some or other reason. Here is the error:

gcc -c -o auth_ldap_cache.o -O2 -DLINUX=2 -DNO_DBM_REWRITEMAP -DWITH_OPENLDAP -f
pic -DSHARED_MODULE -I/usr/include/apache -I/usr/local/include auth_ldap_cache.c
auth_ldap_cache.c: In function `auth_ldap_display_info':
auth_ldap_cache.c:409: `DOCTYPE_HTML_3_2' undeclared (first use in this function
)
auth_ldap_cache.c:409: (Each undeclared identifier is reported only once
auth_ldap_cache.c:409: for each function it appears in.)
auth_ldap_cache.c:409: parse error before string constant
make: *** [auth_ldap_cache.o] Error 1

Any ideas?

--
Richard Ellerbrock
richarde at eskom.co.za