Re: Help with SASL generic GSSAPI error

[Brendan Kearney <bpk678@gmail.com>]

On Tue, 2014-05-13 at 08:26 +0200, Dieter KlÃnter wrote:
> Am Mon, 12 May 2014 20:52:14 -0600
> schrieb Joshua Schaeffer <jschaeffer0922@gmail.com>:
> 
> > I'm looking for a little help concerning the below error I get when I
> > do an ldapsearch:
> > 
> > root@mytest:~# ldapsearch -Y GSSAPI
> > SASL/GSSAPI authentication started
> > ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) 
> > error (80)
> >      additional info: SASL(-1): generic failure: GSSAPI Error: 
> > Unspecified GSS failure.  Minor code may provide more information ()
> > 
> > That error is pretty generic to me and the searching I've done to
> > find a solution has not yielded anything successful.  I have MIT
> > Kerberos and SASL setup and I'm able to successfully get a TGT from
> > any machine that can see my KDC.  I also can successfully search my
> > ldap directory using simple authentication.  I've run the
> > sasl-sample-client and server between several machines including:
> > ldap server to krb server, test server to krb server, test server to
> > ldap server, etc.  I can complete the sasl test on every one.
> > Running slapd in debug mode doesn't provide me with any additional
> > information:
> > 
> > root@baneling:~# slapd -h "ldap:/// ldapi:///" -d 256
> > 5371865b @(#) $OpenLDAP: slapd  (Apr 23 2013 12:16:04) $
> > root@lupin:/tmp/buildd/openldap-2.4.31/debian/build/servers/slapd
> > 5371865c slapd starting
> > 53718672 conn=1000 fd=13 ACCEPT from IP=10.1.10.10:53839
> > (IP=0.0.0.0:389) 53718672 conn=1000 op=0 BIND dn="" method=163
> > 53718672 SASL [conn=1000] Failure: GSSAPI Error: Unspecified GSS 
> > failure.  Minor code may provide more information ()
> > 53718672 conn=1000 op=0 RESULT tag=97 err=80 text=SASL(-1): generic 
> > failure: GSSAPI Error: Unspecified GSS failure.  Minor code may
> > provide more information ()
> > 53718672 conn=1000 op=1 UNBIND
> > 53718672 conn=1000 fd=13 closed
> > 53718672 connection_read(13): no connection!
> > 
> > I do have the keytab in a non-standard location on the ldap server 
> > (/etc/ldap/ldap.keytab), so I modified /etc/default/slapd and
> > restarted slapd.  I'm not really sure what I can provide from my
> > cn=config that would help diagnose this issue let me know and I can
> > respond with the details.
> > 
> > Here is my ldap.conf from the server I'm running the ldapsearch from
> > (my test server):
> > 
> > root@mytest:~# cat /etc/ldap/ldap.conf
> > #
> > # LDAP Defaults
> > #
> > 
> > # See ldap.conf(5) for details
> > # This file should be world readable but not world writable.
> > 
> > BASE            dc=harmonywave,dc=com
> > URI            ldap://baneling.harmonywave.com
> > 
> > #SIZELIMIT        12
> > #TIMELIMIT        15
> > #DEREF            never
> > 
> > # TLS certificates (needed for GnuTLS)
> > TLS_CACERT        /etc/ssl/certs/ca.harmonywave.com.pem
> > TLS_REQCERT        demand
> > TLS_CHECKPEER        yes
> > TLS_CIPHER_SUITE    SECURE256
> > 
> > # LDAP sudo settings
> > sudoers_base        ou=SUDOers,dc=harmonywave,dc=com
> > 
> > # SASL Kerberos settings
> > SASL_MECH        GSSAPI
> > SASL_REALM        HARMONYWAVE.COM
> 
> Does klist show a ldap service principal?
> 
> -Dieter
> 
> 

a couple of things that may need attention.  you need to map the
kerberos-established identities to ldap user objects.  adjust the below
to match your environment (these need to be in cn=config):

olcSaslRealm: BPK2.COM
olcAuthzRegexp: {0}uid=([^,]*),cn=bpk2.com,cn=gssapi,cn=auth uid=
$1,ou=Users,dc=bpk2,dc=com
olcAuthzRegexp: {1}uid=([^,]*),cn=gssapi,cn=auth uid=
$1,ou=Users,dc=bpk2,dc=com

you might also need to tell sasl to use the kerberos auth mechanism, and
where to find the ldap servers.  again, adjust to your environment
(saslauthd.conf):

ldap_servers: ldap://ldap1.bpk2.com/ ldap://ldap2.bpk2.com
ldap_use_sasl: yes
ldap_mech: kerberos5
ldap_auth_method: fastbind
keytab: /etc/ldap.keytab

from what it seems, there is no BIND DN being presented as authenticated
when you attempt your search.  note the BIND dn ="" in your error
message.