Hi folks,
Today I've been using my OpenLDAP v2.4.11 lab setup, the config for which includes MIT Kerberos V, SASL and GSSAPI, to experiment with this feature:
15.2.6. Search-based mappings http://www.openldap.org/doc/admin24/sasl.html#Search-based mappings
It doesn't seem to difficult, but it's not really working for me either. In particular, I can't get slapd to search beyond the first of several authz-regexp statements, as shown in the "more complex site" example. Then I noticed this statement at the very end of the section:
"Note as well that authz-regexp internal search are subject to access controls. Specifically, the authentication identity must have auth access."
It sounds important, but I'm not sure what to do with it. Does it mean all users need auth access to the entire DIT? I tried that, but to no avail.
Can someone please explain?
Thanks,
Jaap
Hi all,
My OpenLDAP 2.4 test system uses Kerberos, SASL and GSSAPI. I've got person objects located in two different org. units and want to search both of them for a potential match, so I included these two statements in slapd.conf:
authz-regexp uid=([^,]*),cn=example.com,cn=gssapi,cn=auth ldap:///ou=eng,dc=example,dc=com??one?(&(uid=$1)(objectClass=person))
authz-regexp uid=([^,].*),cn=example.com,cn=gssapi,cn=auth ldap:///ou=bio,dc=example,dc=com??one?(&(uid=$1)(objectClass=person))
Unfortunately, it's not working as I hoped. If I have two test users, uid=john in ou=eng and uid=pete ou=bio, then after first authenticating them with the Kerberos kinit command, in this situation a subsequent ldapwhoami command for each will give:
dn:uid=john,ou=eng,dc=example,dc=com dn:uid=pete,cn=example.com,cn=gssapi,cn=auth
The second result is, of course, completely useless. However, if I change the order of two authz-regexp statements I get:
dn:uid=john,cn=example.com,cn=gssapi,cn=auth dn:uid=pete,ou=bio,dc=example,dc=com
Now the first result is useless. In other words, both authz-regexp statements work, but the second statement is being ignored. Why? How can I get slapd to also process the second authz-regexp statement?
Thanks,
Jaap
Jaap Winius wrote:
Hi all,
My OpenLDAP 2.4 test system uses Kerberos, SASL and GSSAPI. I've got person objects located in two different org. units and want to search both of them for a potential match, so I included these two statements in slapd.conf:
authz-regexp uid=([^,]*),cn=example.com,cn=gssapi,cn=auth ldap:///ou=eng,dc=example,dc=com??one?(&(uid=$1)(objectClass=person)) authz-regexp uid=([^,].*),cn=example.com,cn=gssapi,cn=auth ldap:///ou=bio,dc=example,dc=com??one?(&(uid=$1)(objectClass=person))Unfortunately, it's not working as I hoped. If I have two test users, uid=john in ou=eng and uid=pete ou=bio, then after first authenticating them with the Kerberos kinit command, in this situation a subsequent ldapwhoami command for each will give:
dn:uid=john,ou=eng,dc=example,dc=com dn:uid=pete,cn=example.com,cn=gssapi,cn=authThe second result is, of course, completely useless. However, if I change the order of two authz-regexp statements I get:
dn:uid=john,cn=example.com,cn=gssapi,cn=auth dn:uid=pete,ou=bio,dc=example,dc=comNow the first result is useless. In other words, both authz-regexp statements work, but the second statement is being ignored. Why? How can I get slapd to also process the second authz-regexp statement?
You can't. As the slapd.conf(5) manpage states, the matching process stops at the first rule that matches the incoming SASL name. If you want to use multiple authz-regexp statements, they must each have unique "match" portions because any duplicates will be ignored.
For your case, you need to come up with a single search specification that will handle both branches of your search. One possible solution would be to use entryDN in the filter:
ldap:///dc=example,dc=com??sub? (&(|(entryDN:dnSubtree:=ou=eng,dc=example,dc=com) (entryDN:dnSubtree:ou=bio,dc=example,dc=com)) (uid=$1)(objectclass=person))
Howard Chu wrote:
For your case, you need to come up with a single search specification that will handle both branches of your search. One possible solution would be to use entryDN in the filter:
Typo in here, should be dnSubtree:=ou=bio,...
ldap:///dc=example,dc=com??sub? (&(|(entryDN:dnSubtree:=ou=eng,dc=example,dc=com) (entryDN:dnSubtree:ou=bio,dc=example,dc=com)) (uid=$1)(objectclass=person))
Quoting Howard Chu hyc@symas.com:
You can't. As the slapd.conf(5) manpage states, the matching process stops at the first rule that matches the incoming SASL name. ...
Okay. I saw that too, but confused the SASL name with the SASL user name. So, the first of my two authz-regexp statements was always a match, which stopped the process.
... If you want to use multiple authz-regexp statements, they must each have unique "match" portions because any duplicates will be ignored.
And mine were duplicates, since the replacement pattern is not part of the match (search pattern).
For your case, you need to come up with a single search specification...
Where can I find information on how to write LDAP URL search specifications? For example, RFC2255 doesn't say much about it (e.g. no mention of ampersand or pipe characters).
... that will handle both branches of your search. One possible solution would be to use entryDN in the filter:
authz-regexp uid=([^,]*),cn=example.com,cn=gssapi,cn=auth ldap:///dc=example,dc=com??sub? (&(|(entryDN:dnSubtree:=ou=eng,dc=example,dc=com) (entryDN:dnSubtree:=ou=bio,dc=example,dc=com)) (uid=$1)(objectclass=person))
Unfortunately, this doesn't work at all. Using ldapwhoami I now get:
dn:uid=john,cn=example.com,cn=gssapi,cn=auth dn:uid=pete,cn=example.com,cn=gssapi,cn=auth
Thanks,
Jaap
Jaap Winius wrote:
Quoting Howard Chu hyc@symas.com:
You can't. As the slapd.conf(5) manpage states, the matching process stops at the first rule that matches the incoming SASL name. ...
Okay. I saw that too, but confused the SASL name with the SASL user name. So, the first of my two authz-regexp statements was always a match, which stopped the process.
... If you want to use multiple authz-regexp statements, they must each have unique "match" portions because any duplicates will be ignored.
And mine were duplicates, since the replacement pattern is not part of the match (search pattern).
For your case, you need to come up with a single search specification...
Where can I find information on how to write LDAP URL search specifications? For example, RFC2255 doesn't say much about it (e.g. no mention of ampersand or pipe characters).
... that will handle both branches of your search. One possible solution would be to use entryDN in the filter:
authz-regexp uid=([^,]*),cn=example.com,cn=gssapi,cn=auth ldap:///dc=example,dc=com??sub? (&(|(entryDN:dnSubtree:=ou=eng,dc=example,dc=com) (entryDN:dnSubtree:=ou=bio,dc=example,dc=com)) (uid=$1)(objectclass=person))
Unfortunately, this doesn't work at all. Using ldapwhoami I now get:
dn:uid=john,cn=example.com,cn=gssapi,cn=auth dn:uid=pete,cn=example.com,cn=gssapi,cn=auth
uid=([^,]*) looks strange to me. How about trying uid=([^,]+) instead?
Ciao, Michael.
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?
Cheers,
Jaap
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.
Quoting Jaap Winius jwinius@umrk.nl:
authz-regexp uid=([^,]*),cn=example.com,cn=gssapi,cn=auth ldap:///dc=example,dc=com??sub? (&(|(entryDN:dnSubtree:=ou=eng,dc=example,dc=com) (entryDN:dnSubtree:=ou=bio,dc=example,dc=com)) (uid=$1)(objectclass=person))
Unfortunately, this doesn't work at all. ...
But this does work:
authz-regexp uid=([^,]*),cn=example.com,cn=gssapi,cn=auth ldap:///dc=example,dc=com??sub? (&(|(entryDN:dnSubtreeMatch:=ou=eng,dc=example,dc=com) (entryDN:dnSubtreeMatch:=ou=bio,dc=example,dc=com)) (uid=$1)(objectclass=person))
I found what I needed to know on the man page for slapcat; first example.
Cheers,
Jaap
openldap-technical@openldap.org
-
Howard Chu -
Jaap Winius -
masarati＠aero.polimi.it -
Michael Ströder