smbd in master and kerberos SASL auth for passdb modules

[Alexander Bokovoy]

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.

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