Andrew Deason wrote:
It's been awhile since I posted this, but for the record (and if
anyone
encounters this in the future), this was a problem with the ldap/fqdn
principal keytab on the DS server. It needed to have a weaker enctype
(des-cbc-crc worked, though others probably do, as well), or else
apparently Solaris couldn't handle it.
Thanks for the followup. It's a bit puzzling still; where is the KDC hosted?
The principal's record in the KDC should contain keys encoded with all of its
supported enctypes. Changing the keytab on the server wouldn't change what
type of service tickets the KDC issues, that would still be controlled by
what the KDC knows and what the client supports.
At any rate, it's good to know that this is a problem area. Yet another
reason not to use SunDS...
--
Andrew Deason
adeason2(a)uiuc.edu
On Wed, 31 Jan 2007 17:35:47 -0600
Andrew Deason <adeason2(a)uiuc.edu> wrote:
> I am trying to use OpenLDAP's ldapsearch to connect to a Sun DS 5.2
> server using SASL/GSSAPI to authenticate. The setup works perfectly
> fine on Solaris clients, but not on Linux ones using OpenLDAP's
> ldapsearch (Debian sid on x86). Instead, it always gives the following
> error:
>
> SASL/GSSAPI authentication started
> ldap_sasl_interactive_bind_s: Invalid credentials (49)
> additional info: SASL(-13): authentication failure: GSSAPI
> Error: Unspecified GSS failure. Minor code may provide more
> information (Unknown code 188)
>
> This error is coming from the DS server (right?), so I know this may
> not be OpenLDAP's problem. I was just wondering if anyone else had
> encountered this problem, or if there are any workarounds or anything,
> or if this is known to just not work at all.
>
> I'm using the Cyrus SASL implementation with MIT Kerberos. I tried
> this with ldapsearch 2.3.30 and 2.2.23.
>
> --
> Andrew Deason
> adeason2(a)uiuc.edu
>
--
-- Howard Chu
Chief Architect, Symas Corp.
http://www.symas.com
Director, Highland Sun
http://highlandsun.com/hyc
Chief Architect, OpenLDAP
http://www.openldap.org/project/