cli_credentials ccache semantics and test changes

Andrew Bartlett abartlet at
Wed May 23 18:55:12 MDT 2012

On Wed, 2012-05-23 at 18:47 +0200, Alexander Bokovoy wrote:

> - Log -----------------------------------------------------------------
> commit dcfb34fbb4b7484bdaa70fbe9ae9fd84738ab469
> Author: Alexander Bokovoy <ab at>
> Date:   Wed May 23 17:34:24 2012 +0300
>     blackbox: fix samba4.blackbox.kinit test
>     This deserves some explanation.
>     With commit 518232d4578d700f5f5ea1609275a6cd1de3a1e7 samba4.blackbox.kinit test set
>     was wrapped with password settings reset before and after the tests with an idea to
>     maintain reliable state for the tests. As result, the resetting of the password
>     settings was done after the test that tried to use smbclient with a Kerberos ticket
>     obtained with machine account credentials.
>     However, the code in credentials_krb5.c, function cli_credentials_get_client_gss_creds(),
>     never worked correctly when credentials were already in ccache. Instead, gensec_gssapi module
>     always re-kinited even if existing credentials were available in the ccache. This had an effect
>     on 'samba4.blackbox.kinit(dc:local).reset password policies(dc:local)' test equal to
>     never having initialized ccache at all, as if 'rm -f $KRB5CCNAME' was run before the test.
>     When the issue of not using already initialized credentials from ccache was fixed with
>     d0aae88f1290e6a7a6d4bfc24aa62795e4892a31 'auth-credentials: Support using pre-fetched ccache
>     when obtaining kerberos credentials' commit, Samba 4 credentials library started to correctly
>     re-used already obtained credentials from ccaches. This caused failure of the test
>     'samba4.blackbox.kinit(dc:local).reset password policies(dc:local)' because machine account
>     has no permissions to modify password settings.
>     Thus, the correct fix is to reset ccache state before performing the test.
>     Autobuild-User: Alexander Bokovoy <ab at>
>     Autobuild-Date: Wed May 23 18:46:12 CEST 2012 on sn-devel-104


I'm really sorry, but this is not the right way to handle it.  Indeed,
the need to change this test (which was perfectly correct beforehand)
shows that the code change was incorrect.  We will need to revert both
of these, and I need to work with you more closely to sort out a way to
support your legitimate needs.

> commit ec989e7c402e9868d45d7764175f2b44d85bb244
> Author: Alexander Bokovoy <ab at>
> Date:   Fri May 18 10:05:38 2012 +0300
>     auth-credentials: Support using pre-fetched ccache when obtaining kerberos credentials
>     When credentials API is used by a client-side program that already as fetched required
>     tickets into a ccache, we need to skip re-initializing ccache. This is used in FreeIPA
>     when Samba 4 Python bindings are run after mod_auth_kerb has obtained user tickets
>     already.

> diff --git a/auth/credentials/credentials_krb5.c b/auth/credentials/credentials_krb5.c
> index 684f244..2c93a8f 100644
> --- a/auth/credentials/credentials_krb5.c
> +++ b/auth/credentials/credentials_krb5.c
> @@ -486,8 +486,18 @@ _PUBLIC_ int cli_credentials_get_client_gss_creds(struct cli_credentials *cred,
>  		}
>  	}
> -	ret = cli_credentials_get_ccache(cred, event_ctx, lp_ctx,
> -					 &ccache, error_string);
> +
> +	if (cred->ccache_obtained == CRED_UNINITIALISED) {
> +		/* Only attempt to re-acquire ccache if it is not already in place.
> +		 * this is important for client-side use within frameworks with already acquired tickets
> +		 * like Apache+mod_auth_kerb+Python
> +		 */
> +		ret = cli_credentials_get_ccache(cred, event_ctx, lp_ctx,
> +						 &ccache, error_string);
> +	} else {
> +		ccache = cred->ccache;
> +	}
> +

The problem with this patch is that it does not respect the rules that
are set down (but not clearly documented) on how the Samba4 credentials
system determines if a credential cache should be used. 

Samba tries to always 'do the right thing' with the information it is
presented on passwords.  In particular, the idea is that to enable the
mythical kerberos 'single sign on', environment, that when no password
is specified the credential cache from the environment is used. 

However, when a username or password is specified, such as on the
command line, then that is used in preference to 'found' credentials
cache.  This ensures that if you have done a kinit, that you are not
'locked in' to only using that credentials cache. 

Can you please revert these changes, and then work with me to sort out
why gensec_gssapi was re-kiniting?  My understanding based on our
previous discussion is that this was due to the way you were loading the
realm into either the credentials or loadparm objects.  I had thought
that we were able to come to a solution there, but I'm willing to try
again.  Your use case with the python scripts is very important to me. 

If these changes were in the branch I've been following, then I'm sorry
for not flagging this earlier. 

Andrew Bartlett

Andrew Bartlett                      
Authentication Developer, Samba Team 

More information about the samba-technical mailing list