Quoting Michael Ströder michael@stroeder.com:
uid=([^,]*) looks strange to me. How about trying uid=([^,]+) instead?
That would only help to avoid matching an empty uid. Anyway, we've already established that the problem is not the search pattern, but the authz-regexp replacement pattern. Howard has suggested an interesting LDAP search URL/URI; it may not work, but it looks like the right idea.
Also, I'm still bothered by the note at the very end of section 15.2.6 of the OpenLDAP admin manual. There's a similar note on the man page for slapd.conf:
"The protocol portion of the URI must be strictly ldap. Note that this search is subject to access controls. Specifically, the authentication identity must have "auth" access in the subject."Perhaps Howard's URL is correct, but that this issue is keeping it from working. This is even what my question was originally about: What does this mean? Who is supposed to have auth access to what in order for this to work?
The "protocol" note means that you can only use a "ldap://" URL type, not a "ldaps://" or so. This is to make sure one does not incorrectly assume that requests can be directed to another server or so.
The "access" note means that an internal search will be performed. This implies that a searchBase object will be unvealed, the values of attrs used in the filter will be compared to the asserted ones, and the DNs of the resulting objects will be used for the mapping. Access to all this information will be required. If the mapping is part of an authentication, the request itself is anonymous until the bind succeeds. As a consequence, access to data required by the mapping will need to be granted to anonymous. For this reason, any "read" or "search" access required by the internal lookup is relaxed to "auth", so you don't need to endanger data confidentiality in order to allow identity mapping.
All of this is (partially) discussed in Section "OPERATION REQUIREMENTS" of slapd.access(5).
Hope this helps.
p.