[Date Prev][Date Next]
RE: LDAP Dies When Attempting To Use Kerberos 4 Mechanism (ITS#2991)
> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of email@example.com
> 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.
Definitely do so.
> - The ldap search command I used clearly specified the
> kerberos_v4 mechanism
The command you used does no such thing.
> isauth1:~ # ldapsearch -d5 -X
> -b 'dc=msu,dc=edu' '(objectclass=*)' -W
See the ldapsearch(1) man page. The correct way to specify a SASL mechanism
is using the -Y option.
> - The configuration file clearly specifies the kerberos 4 mechanism -
> saslmech KERBEROS_V4
> >From the message the slapd reports just before it dies -
> Mar 3 02:06:20 isauth1 slapd: conn=0 op=0 SRCH
> Mar 3 02:06:20 isauth1 slapd: SASL [conn=0] Failure:
> unavailable due to lack of IPv4 information
> Mar 3 02:06:20 isauth1 slapd: conn=0 op=0 SEARCH
> RESULT tag=101 err=0
> nentries=1 text=
> Mar 3 02:06:20 isauth1 slapd: conn=0 op=1 BIND dn=""
> 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
> 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
> the kerberos_v4 mechanism when it didn't find proper communications
The SASL library tells slapd what mechanisms are available. slapd doesn't
choose or invalidate any of them explicitly.
> 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
Kerberos_V4 requires the IP address of the server. As far as I know we
provide it in the proper format already. Since you're using such an old Cyrus
SASL release (2.1.7) it would be worthwhile to update that (to the current
release, 2.1.17) before proceeding further.
> What is the proper configuration of the srvtab file that
> kerberos 4 and 5 both use.
The answer to that question is in your Kerberos documentation. The OpenLDAP
bug tracking system is not here to provide answers about how to use your
Kerberos software, it's to track legitimate bugs in the OpenLDAP software.
> 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
> This was constructed as per the documentation provided on the
> openldap web site.
You didn't follow the advice to set things up according to your Kerberos
documentation. The srvtab is not a plaintext file, this file is not usable.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support