smbd in master and kerberos SASL auth for passdb modules

[Jeremy Allison]

On Mon, Mar 19, 2012 at 03:08:02PM +0200, Alexander Bokovoy wrote:
> Hi,
> 
> I'm working on making FreeIPA's passdb module (ipasam) to use kerberos
> service key to authenticate against LDAP server. As such, this
> requires use of SASL interactive authentication with libldap and I
> have it working in a simple separate program. However, when
> integrating that code into git master, I encountered several issues
> I'd like to discuss and find ways to solve them.
> 
> 1. smbldap infrastructure in source3/lib/smbldap.c gives fair way to
> cut down amount of work when writing own passdb module. It does not
> support interactive SASL binds though. We could have solved it by
> introducing a way to setup an alternative callback for auth purposes
> which, if set, would be called instead of ldap_simple_bind_s(). I have
> a simple patch here:
> http://abbra.fedorapeople.org/.paste/0001-Add-ability-to-use-external-callback-to-perform-LDAP.patch
> which shows how to achieve it.
> 
> 2. With the callback patch I'm able to initiate GSSAPI SASL bind to
> LDAP server. Unfortunately, it fails.
> 2.1. smbd in master is built with Heimdal and system-wide libldap/sasl
> libraries. The latter (sasl) is also linked against system-wide
> libkrb5.
> 2.2. ipasam is built separately and compiled with system-wide MIT
> krb5, as well as system-wide ldap/sasl libraries.
> 2.3. both system-wide libkrb5 and Samba4's heimdal libraries are
> pulled into smbd.
> 2.4. heimdal gives EINVAL (22) when calling to
> krb5_get_init_creds_opt_set_out_ccache(). It fails both with a memory
> and file-based ccache.
> 
> Mar 19 14:48:25 m17 smbd[27758]: [2012/03/19 14:48:25.057178,  0]
> ipa_sam.c:3119(bind_callback)
> Mar 19 14:48:25 m17 smbd[27758]:   principal is 0xc7cd80 (0)
> Mar 19 14:48:25 m17 smbd[27758]: [2012/03/19 14:48:25.058706,  0]
> ipa_sam.c:3127(bind_callback)
> Mar 19 14:48:25 m17 smbd[27758]:   default ccache is FILE:/tmp/krb5cc_1t0dnd
> Mar 19 14:48:25 m17 smbd[27758]: [2012/03/19 14:48:25.059510,  0]
> ipa_sam.c:3130(bind_callback)
> Mar 19 14:48:25 m17 smbd[27758]:   keytab is 0xc7cea0 (0)
> Mar 19 14:48:25 m17 smbd[27758]: [2012/03/19 14:48:25.060482,  0]
> ipa_sam.c:3133(bind_callback)
> Mar 19 14:48:25 m17 smbd[27758]:   options are 0xc7cde0 (0)
> Mar 19 14:48:25 m17 smbd[27758]: [2012/03/19 14:48:25.061318,  0]
> ipa_sam.c:3136(bind_callback)
> Mar 19 14:48:25 m17 smbd[27758]:   options are using the ccache (22)
> Mar 19 14:48:25 m17 smbd[27758]: [2012/03/19 14:48:25.074648,  0]
> ipa_sam.c:3140(bind_callback)
> Mar 19 14:48:25 m17 smbd[27758]:   creds uses keytab (0)
> Mar 19 14:48:25 m17 smbd[27758]: GSSAPI Error: Unspecified GSS
> failure.  Minor code may provide more information (Credential cache is
> empty)
> Mar 19 14:48:25 m17 smbd[27758]: [2012/03/19 14:48:25.093531,  0]
> ipa_sam.c:3148(bind_callback)
> Mar 19 14:48:25 m17 smbd[27758]:   bind_callback: cannot perform
> interactive SASL bind with GSSAPI
> 
> Why I know that its heimdal that fails? Because if I would use
> krb5_cc_new_unique() as above to create a unique credentials cache
> rather than using the default one, I'm getting different temporary
> ccache names when used within smbd and as a standalone application,
> both with FILE and MEMORY types of ccaches. With FILE type MIT libkrb5
> produces ccaches of /tmp/tktXXXX and heimdal produces
> /tmp/krb5cc_XXXX. Also with MEMORY type the name pattern is different.
> 
> Here is how I do set my unique ccache to be default one (in case it is
> not visible to the rest of the code on sasl side), this still has no
> influence on the outcome (failure):
>         rc = krb5_cc_new_unique(data.context, "FILE", NULL, &data.ccache);
>         rc = krb5_cc_initialize(data.context, data.ccache, data.principal);
>         rc = krb5_cc_get_full_name(data.context, data.ccache, &ccache_name);
>         rc = krb5_cc_set_default_name(data.context,  ccache_name);
> 
> When built standalone against MIT kerberos 1.10 I have on my system,
> the code works: http://abbra.fedorapeople.org/.paste/krb5_bind_test.c
> (this snippet lacks all the error checks on purpose, to simply show
> the flow).
> 
> We could have used GSSAPI's gss_krb5_import_cred() instead of raw
> kerberos functions here similar to how Simo does it in gss-proxy
> (http://fedorapeople.org/gitweb?p=simo/public_git/gss-proxy.git;a=blob;f=proxy/src/gp_creds.c;h=c53a26d12d0ab0393f76220ad79e04a86624a744;hb=5b40dd690e95de3320c3a15df0ddf9489d5fdcec#l172)
>  and then passed the gss credentials object to the SASL but
> unfortunately SASL as used in libldap does not allow you to pass
> GSSAPI credentials in as we don't have access to sasl_conn_t instance
> stored within LDAP connection structure, this is openldap's libldap
> limitation.
> 
> Alternatively, we could have added the SASL interactive bind code to
> smbldap and that probably would have worked when using Heimdal only
> but then I'm not sure Heimdal and MIT kerberos have compatible ccache
> on-disk structures.

Ok, I'm not sure what you need here to make this work.

We need to be able to have an smbd that works without Heimdal,
and simply uses the MIT libraries (blocker bug for 4.0).

Can you be precise about the code changes you need please ?

> Speaking of those, there seems to be no central place in smbd which
> tries to define a default ccache location. Having smbd running under
> root privileges most of time, it would imply for kerberos library that
> unless changed default ccache would be /tmp/krb5cc_0, a credentials
> cache of root user. This is at least fragile, we probably need to
> define some samba-specific default credentials cache (in
> $PIDDIR/samba.ccache, for example).
> 
> A bug https://bugzilla.samba.org/show_bug.cgi?id=8717 tries to
> summarize different aspects on why having ability to not mix kerberos
> implementations is good. My example shows this is real issue -- not
> only because of kerberos code used within the samba modules and smbd
> themselves but also due to import of system-provided ldap/sasl
> libraries.
> 
> It would be good to avoid embedded heimdal code being linked to
> source3's smbd when using system-provided kerberos library.

Indeed. How do we fix this ?

Jeremy.