smbd in master and kerberos SASL auth for passdb modules
ab at samba.org
Mon Mar 19 14:36:06 MDT 2012
On Mon, Mar 19, 2012 at 22:19, Jeremy Allison <jra at samba.org> wrote:
> On Mon, Mar 19, 2012 at 03:08:02PM +0200, Alexander Bokovoy wrote:
>> 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:
>> 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
>> 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: [2012/03/19 14:48:25.057178, 0]
>> Mar 19 14:48:25 m17 smbd: principal is 0xc7cd80 (0)
>> Mar 19 14:48:25 m17 smbd: [2012/03/19 14:48:25.058706, 0]
>> Mar 19 14:48:25 m17 smbd: default ccache is FILE:/tmp/krb5cc_1t0dnd
>> Mar 19 14:48:25 m17 smbd: [2012/03/19 14:48:25.059510, 0]
>> Mar 19 14:48:25 m17 smbd: keytab is 0xc7cea0 (0)
>> Mar 19 14:48:25 m17 smbd: [2012/03/19 14:48:25.060482, 0]
>> Mar 19 14:48:25 m17 smbd: options are 0xc7cde0 (0)
>> Mar 19 14:48:25 m17 smbd: [2012/03/19 14:48:25.061318, 0]
>> Mar 19 14:48:25 m17 smbd: options are using the ccache (22)
>> Mar 19 14:48:25 m17 smbd: [2012/03/19 14:48:25.074648, 0]
>> Mar 19 14:48:25 m17 smbd: creds uses keytab (0)
>> Mar 19 14:48:25 m17 smbd: GSSAPI Error: Unspecified GSS
>> failure. Minor code may provide more information (Credential cache is
>> Mar 19 14:48:25 m17 smbd: [2012/03/19 14:48:25.093531, 0]
>> Mar 19 14:48:25 m17 smbd: 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
>> 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
>> 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 ?
I need to authenticate LDAP connection with a mechanism other than
simple bind. This could be solved generally by allowing to use a
different bind method in smbldap_connect_system() in
source3/lib/smbldap.c, like in the patch I made:
Adding bind callback support to smbldap would solve a problem of
making own authenticator but it will not make SASL GSSAPI-based one
working without ensuring smbd is built with a single Kerberos library.
The rest can be done by an smbldap's user code and as
http://abbra.fedorapeople.org/.paste/krb5_bind_test.c shows, the
actual code is rather small (it would be a bit different in Heimdal
variant but still small).
>> 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
>> 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 ?
Guenther is looking into it, he might have already got some progress.
I experimented with enabling MIT krb5 build in waf myself and one
issue is that we currently have global set of defines across both
source3 and source4 that affect both parts. We need to be able to
switch certain groups of defines per subsystem in order to enable
finer selection like triggering libkrb5 selection at least on
source3/source4 level. When I enable global MIT krb5 build, I'm
getting hit by heimdal not compilable because wrong include paths are
used as parts of system wide Kerberos step over.
/ Alexander Bokovoy
More information about the samba-technical