--On Wednesday, September 01, 2010 11:38:55 PM +0300 Zaar Hai haizaar@haizaar.com wrote:

Good day, dear list!

I'm trying to setup SASL GSSAPI authentication for openldap that listens on hostname different from the machine hostname it runs on.

openldap runs on server inka.example.com. ldap/inka/example.com principal is added to ldap's keytab file. This command works just fine:   ldapsearch -Y GSSAPI -H 'ldap://inka.example.com'

Now:  * I've added second IP to the inka.example.com  * Added A record for ldap.example.com to point to that IP and setup corresponding PTR record.  * Created ldap/ldap.example.com principal and added it ldap's keytab.  * Even set openldap to listen only on ldap.example.com IP.

But the command   ldapsearch -Y GSSAPI -H 'ldap://ldap.example.com' fails with the following error in ldap log: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Wrong principal in request)

I see that client successfully obtains ticket for ldap/ldap.example.com@EXAMPLE.COM I've tried to set sasl-host to ldap.example.com and sasl-realm to EXAMPLE.COM in slapd.conf - did not help. I've even tried to do "hostname ldap" on inka.example.com and restart slapd - same error.

...

From what I understand,  the slapd daemon will try, before connecting

the KDC server, to read the keytab file and get the key of the principal ldap/<sasl-host>#<sasl-realm>, so it looks like I'm doing the right thing, but it does not work.

System: Debian testing. slapd-2.4.17-2.1 sasl-2.1.23.dfsg1-5 MIT kerberos 1.8.3+dfsg~beta1-1

Thank you in advance for help,

Zaar

Simon Wilkinson discussed the problem on the Heimdal list.

The problem is that both the client and the server must have a matching idea of the service principal to use in establishing the GSSAPI connection.

The client will use ldap/ldap.uvm.edu, as that's the only name it knows the server by. However, the server will end up using ldap/hostname() and therefore the two won't match, and you'll get these errors.

There is a work around for this at the GSSAPI layer, which is to tell the server to trust any principal that exists in the service's keytab. Unfortunately, Cyrus SASL doesn't seem to expose a mechanism for doing this, and so the only way to do so is via a code change to the SASL library.

The patch to Cyrus SASL that we are using to deal with this is:

@@ -693,7 +693,7 @@ gssapi_server_mech_step(void *conn_context,

GSS_LOCK_MUTEX(params->utils); maj_stat = gss_acquire_cred(&min_stat, - text->server_name, + GSS_C_NO_NAME, GSS_C_INDEFINITE, GSS_C_NO_OID_SET, GSS_C_ACCEPT,

Bill