[Date Prev][Date Next]
RE: can I use a kerberos ticket with ldapsearch (and ldap libraries)
> -----Original Message-----
> From: Michael Torrie [mailto:firstname.lastname@example.org]
> 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> +
> > 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:
This would map my Kerberos login email@example.com to
The DN mapping feature can perform its own LDAP search to resolve names,
which makes it very powerful. I could use this rule instead:
For a Kerberos login firstname.lastname@example.org 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
Symas: Premier OpenSource Development and Support