Re: custom hostname for openldap/sasl is not working

[Bill MacAllister <whm@stanford.edu>]

--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

--

Bill MacAllister
Infrastructure Delivery Group, Stanford University