smbd in master and kerberos SASL auth for passdb modules

[Alexander Bokovoy]

On Mon, Mar 19, 2012 at 15:08, Alexander Bokovoy <ab at samba.org> 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.
...2.5. and krb5_get_init_opt_set_out_ccache() is missing in Heimdal.
Thus, MIT krb5_get_init_opt_set_out_ccache() is called on a
Heimdal-allocated objects.

> 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.
>
> 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.
>
> --
> / Alexander Bokovoy



-- 
/ Alexander Bokovoy