11:14 a.m.
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
8:17 p.m.
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
8:47 p.m.
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=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?
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
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9:23 p.m.
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))
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7:46 a.m.
Quoting Howard Chu <hyc(a)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
11:07 a.m.
Jaap Winius wrote:
Quoting Howard Chu <hyc(a)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.
5:32 p.m.
Quoting Michael Ströder <michael(a)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
2:34 p.m.
Quoting Michael Ströder <michael(a)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.
3:46 p.m.
Quoting Jaap Winius <jwinius(a)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
4812
days inactive
4814
days old
openldap-technical@openldap.org
8 comments
4 participants
participants (4)
-
Howard Chu -
Jaap Winius -
masarati＠aero.polimi.it -
Michael Ströder