On Tue, 2014-05-13 at 08:12 -0500, Dan White wrote:
On 05/13/14 07:32 -0400, Brendan Kearney wrote:
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:
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 ()
Check your syslog - auth facility, and check your kdc logs.
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
This may be necessary.
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
This is not necessary, for GSSAPI authentication. That is, the error message above is a SASL error message. olcAuthzRegexp would be needed to map the user after authentication has been completed.
good point, why map an identity if it has not been authenticated yet.
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
This is also not necessary, as GSSAPI authentication does not depend on or use saslauthd. It would be needed if performing pass-through or PLAIN/LOGIN authentication.
interesting. when i found the articles that i worked off of for my environment, those distinctions were not made. only recently did i discover that the pass-through auth works. i have set olcSaslSecProps to noanonymous,noplain so it seems to only works in limited cases.