access and filters

["Rosser Schwarz" <rschwarz@totalcardinc.com>]

We're running OpenLDAP 2.1.25, back-ldbm, on a RH9 box and having
a problem with access control and searches.  The brief (-ish)
description:

I'm given a uid and password (by a replacement GINA library I'm
writing to pass Windows login credentials to a PHP/LDAP backend).
I know I can't bind as the uid (without using SASL, which, for
innumerable repeatedly-beating-skull-against-brick-walls sorts of
reasons, we aren't/can't) so I bind anonymously to search for the
cn corresponding with that uid, then, theoretically, I'd re-bind
as that cn with the supplied password.

Unfortunately, my search on uid returns no results unless I have
an overly permissive set of access controls.  The (global) access
portion of my slapd.conf is:

access to dn=".*,ou=people,dc=company,dc=com" attr=cn,uid
    by anonymous read break

access to dn=".*,ou=people,dc=company,dc=com"
    attr=userPassword,uniqueIdentifier
    by self write break
    by * auth break

access to *
    by self read break

access to *
    by dn="cn=Manager,dc=company,dc=com" write stop
    by dn=".*,ou=IT,ou=departments,dc=company,dc=com" write stop

access to *
    by * none stop

If I add an "access to * by * read" as the first ACL, my search
works. Else, it fails, and immediately after dumping the cn I'm
searching for, the debug log (with -d 5) says:

ldbm_search: candidate entry 705 does not match filter

The sole search criterion is "(uid=$uid)".  Wildcarding objectClass
and/or cn yields the same result, as, logically it should.  I also
have the same results whether my ACLs are global or backend-specific,
and with or without the "break" and "stop" keywords on the rules.
It's obviously finding the entry I want, both for its presence in
the logs and the fact that the search works with the less restrictive
permissions, but doesn't otherwise.

I'd like to avoid giving blanket read permissions to my directory
to the entire world if at all possible (the directory is behind a
firewall and DMZ, but still...).  To that end, I'd appreciate any
suggestions on how better to phrase my ACLs so my searches will
succeed while maintaining the desired level of security.

(As an aside, when run with the overly-permissive ACLs, I have a
similar issue searching for the bound user's attributes once I get
the cn and re-bind.  I think the issues are related, but I need to
get past the above-described problem before I can really work on
anything else.)

Cheers,

/rls

--
Rosser Schwarz
Total Card, Inc.