gss_krb5_import_cred fails for Samba

Andrew Bartlett abartlet at
Mon Jul 18 08:30:01 MDT 2011


As the internet searches I did indicate you have been working on
gss_krb5_import_cred(), I thought maybe you could help me out.

The recent addition of this function to MIT kerberos has broken Samba3,
and blocks the use of MIT in Samba4 because it is not identical to the
behaviour provided by Heimdal, and our autoconf logic found
gss_krb5_import_cred, and so expected to use it.

Samba maintains a keytab, with entries for the whole host (multiple
possible principal aliases) under one name in the keytab.  This is then
searched by the kerberos acceptor code, either by iteration or by
specifying the principal argument to gss_krb5_import_cred().

However, this doesn't work in the MIT 1.9 version I have in Fedora 15.
If the principal argument is not specified, then the function fails

This is because alloc_union_cred() calls 
    status = mech->gss_inquire_cred(minor_status,
    if (status != GSS_S_COMPLETE)
	goto cleanup;

    status = mech->gss_display_name(minor_status,

The issue is that mech_name is NULL, as no particular principal has been
bound to the credential (a search should be done during the accept of
the kerberos ticket). 

If the principal is specified (matching the keytab value of host$@REALM)
then the login fails with 'Wrong principal in request'.  In both these
cases, Heimdal does the right thing, and either searches the keytab or
binds all incoming kerberos requests to the specified principal. 

Given this function seems to have been added for Samba, is there a test
case that could be expanded to ensure that Samba's needs for this
function can be met?

The code in Samba is source3/librpc/crypto/gse.c:gse_init_server()


Andrew Bartlett
Andrew Bartlett                      
Authentication Developer, Samba Team 

More information about the samba-technical mailing list