RE: can I use a kerberos ticket with ldapsearch (and ldap libraries)

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Michael Torrie [mailto:torriem@cs.byu.edu]

> On Thu, 2002-04-18 at 07:23, Howard Chu wrote:
>
> > The rootpw config has nothing to do with SASL. In the 2.0.x
> release the only
> > valid DNs for a SASL bind are of the form "uid=<username> +
> realm=<realm>"
> > If you want "ldapadmin@REALM" to be treated as your server root then you
> > need to
> > configure
> > 	rootdn	"uid=ldapadmin + realm=REALM"
>
> Followup guestion.  Since the userPassword field is obviously bogus
> (unused) since we don't do a simple bind, how do I configure OpenLDAP to
> only allow certain principals to bind as an arbitrary user?  I read
> something a while back about an attribute that could specify multipal
> principals, but it used a now depricated ObjectClass.  Basically can I
> do something that's the same effect as .k5login on binding to ldap?  Do
> I need to do special things in my LDAP acls?  (I imagine so.)

Your question isn't very clear to me, but I'll take a stab at it.
In OpenLDAP 2.0, SASL principals cannot bind as arbitrary users. They bind
as themselves only, and their names are in the DN form I gave above. Your
ACLs need to control access based on those DNs.

In version 2.1 the SASL DN format is changed, and support is added for a
SASL principal to bind as some other user. But since you're not using 2.1
yet, the feature doesn't apply to you.

To give you a taste of what's coming: the OpenLDAP 2.1 SASL DN format is
	uid=<user>, cn=<realm>, cn=<sasl-mechanism>, cn=AUTH
where user, realm, and sasl-mechanism are replaced by the actual values, and
cn=AUTH is a constant.

The exception to this is in SASL EXTERNAL with TLS, where the DN from the
user's certificate is used directly as the SASL DN.

Also, in 2.1 there is a sasl-regexp directive that defines rules to map the
above SASL DNs to any other form. As a very simple example, I use this rule:
	sasl-regexp "uid=\(.*\),cn=symas.com,cn=gssapi,cn=auth"
"cn=$1,ou=personnel,o=symas corp.,c=us"

This would map my Kerberos login hyc@symas.com to
	cn=hyc,ou=personnel,o=symas corp.,c=us

The DN mapping feature can perform its own LDAP search to resolve names,
which makes it very powerful. I could use this rule instead:
	sasl-regexp "uid=\(.*\),cn=symas.com,cn=gssapi,cn=auth"
"ldap:///ou=personnel,o=symas corp.,c=us??sub?cn=$1"

For a Kerberos login hyc@symas.com this would return the entry that matches
"cn=hyc" and use that entry's DN. On my directory, this would return
	cn=Howard Chu,ou=personnel,o=symas corp.,c=us

Which coincidentally :) happens to also be the DN in my SSL certificate...
(Naturally the above search works because my entry contains "hyc" as one of
the values of the cn attribute.)

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support