[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: LDAP Dies When Attempting To Use Kerberos 4 Mechanism (ITS#2991)



Thanks for looking at the problem. There are a couple of other issues
associated with the problem:
- after I observed the problems descirbed with openldap2.1.25 I compiled
and tested it with openldap2.26. The transcripte I sent was from the tests
run with version 2.26, not 2.1.25. The transcript appeared to be the same
so that is the one I sent.

- I am using Cyrus SASL 2.1.7. I could try upgrading that.

- The ldap search command I used clearly specified the kerberos_v4 mechanism
isauth1:~ # ldapsearch -d5 -X 'uid=jhh,cn=msu.edu,cn=kerberos_v4,cn=auth' 
-b 'dc=msu,dc=edu' '(objectclass=*)' -W

- The configuration file clearly specifies the kerberos 4 mechanism -
saslmech KERBEROS_V4
sasl-regexp
        uid=(.*),cn=.*,cn=auth
        uid=$1,ou=person,dc=example,dc=com

>From the message the slapd reports just before it dies -
Mar  3 02:06:20 isauth1 slapd[32753]: conn=0 op=0 SRCH
attr=supportedSASLMechanisms
Mar  3 02:06:20 isauth1 slapd[32753]: SASL [conn=0] Failure: KERBEROS_V4
unavailable due to lack of IPv4 information
Mar  3 02:06:20 isauth1 slapd[32753]: conn=0 op=0 SEARCH RESULT tag=101 err=0
nentries=1 text=
Mar  3 02:06:20 isauth1 slapd[32753]: conn=0 op=1 BIND dn="" method=163

It is plain that it could not communicate with the kerberos 4 server due
to a lack of communications parameters and so it disables the kerveros_v4
mechanism. The transcript from ldapsearch at this point in the dialog
produces the following output:
ldap_interactive_sasl_bind_s: server supports: OTP DIGEST-MD5 CRAM-MD5
ldap_int_sasl_bind: OTP DIGEST-MD5 CRAM-MD5
SASL/OTP authentication started

And so it would appear that ldapsearch picked the first alternative to
kerberos 4 from the list of supported mechanisms, but slapd invalidated
the kerberos_v4 mechanism when it didn't find proper communications
parameters.

You are probably correct the the use of the OTP mechanism is causing the
clapd to crash, however why can't it talk to the kerberos 4 server and so
avoid defaulting to the OTP mechanism (which you have stated has a known
bug)?

I have determined that the sasl libraries need the proper communications
parameters to communicate with the kerberos 4 server. The saslauthd
appears to handle the issue by consulting /etc/krb.conf and
/etc/krb.realms. I don't do anything to the saslauthd but specify
kerberos_v4 as the mechanism during configuration. It authenticates my
user ID and password against our kerberos 4 immediately. When the wrong PW
is passed it fails obviously.

Testing the sasl libraries with some cruder test fixtures, it becomes
obvious that the error reported above concerning not being able to use the
KERBEROS_V4 mechanism due to lack of IPV4 information is actually
generated by the sasl libraries.

The saslauthd is able to authenticate using the kerberos 4 mechanism when
properly configured.

What is going on with the way slapd uses the sasl  libraries? How does it
pass the communications parapeters to the sasl libraries? Are their
function calls in the sasl libraries that can be used to extract this
information from /etc/krb.conf and /etc/krb.realms?

What is the proper configuration of the srvtab file that kerberos 4 and 5
both use. What information is really being conveyed here? I don't believe
that this is where the information that is need really comes from, but I
could be wrong.

Here is my srvtab file:
isauth1:~ # more /etc/srvtab
ldap.isauth1.cl@MSU.EDU
This was constructed as per the documentation provided on the openldap web
site.

Here is my /etc/krb.conf file:
isauth1:~ # more /etc/krb.conf
MSU.EDU
MSU.EDU afsdb0.cl.msu.edu admin server

Here is my /etc/krb.realms file:
isauth1:~ # more /etc/krb.realms
.msu.edu

Thaks for any information/help that you can provide.

John Hayes
Systems Analyst/Michigan State University

> Your transcript shows that your Bind attempt was using the OTP mechanism,
> not
> Kerberos IV. The SASL OTP mechanism was known to crash and there has been
> no
> interest in investigating that problem. It appears to work in OpenLDAP 2.2
> using
> Cyrus SASL 2.1.17 though.
>