Thanks. So far so good. SASL is now working correctly. I did a chmod
a+r /etc/krb5.keytab and it works. However this is not a good
solution. I guess one solution is to make a special group that I can
put ldap in to access that file. It's odd that there's no option to
specify the keytab file... ;)
Now I need to figure out how the access controls work.
Michael
On Thu, 2002-04-18 at 07:23, Howard Chu wrote:
> > -----Original Message-----
> > From: owner-openldap-software@OpenLDAP.org
> > [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Michael Torrie
>
> > Okay, I'm getting closer. I'm able to do a kinit on my root@MYDOMAIN
> > principal. Then I run:
> >
> > ldapsearch -h myhost.mydomain.com -p 389 -I -b "" -s base -LLL
> > supportedSASLMechanisms
> >
> > I get an error:
> >
> > ldap_sasl_interactive_bind_s: Unknown error
> > additional info: GSSAPI: gss_acquire_cred: Miscellaneous failure;
> > Permission denied;
> >
> > This is better then the last error, which was the generic local error.
>
> I suspect this is due to a missing keytab. As I recall, the LDAP service
> expects to use "ldap/my.fqdn@realm" as the service name and an entry for
> this principal must exist in the default keytab, and the keytab of course
> must be readable by the user that slapd runs under. Since SASL has no way
> of configuring a specific keytab to use, you must use the system's default,
> which is typically /etc/krb5.keytab.
>
> > I take it the ticket is being granted properly (according to the
> > kerberos logs). (minor point, the service ticket requested is not the
> > fully-qualified domain name -- temporarily fixed by adding that to the
> > krb database.) However slapd is obviously not trusting the principal.
> > What principal do I use? My root principal, or the one I set up as the
> > passwd in the slapd.conf file? Obviously I must tell slapd to accept
> > some principal or principals. Can anyone give me a pointer here. I
> > already have my slapd.conf looking like so:
> >
> > rootdn "cn=Manager,dc=...."
> > rootpw {KERBEROS}ldapadmin@REALM
> >
> > So I want to use the ldapadmin principal with kinit, right? That didn't
> > seem to work either.
>
> 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"
> On a SASL bind your rootpw is irrelevant, since SASL will perform the
> authentication using your kerberos ticket.
>
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support
--
Public key available from http://students.cs.byu.edu/~torriem
Attachment:
signature.asc
Description: This is a digitally signed message part