- Microsoft SQL Server Linux GSSAPI Questions / Issues

[Robert Dorr]

This is great information and extremely helpful.  Thank you for the quick response.


-----Original Message-----
From: Greg Hudson [mailto:ghudson at mit.edu] 
Sent: Sunday, January 21, 2018 3:27 PM
To: Robert Dorr <rdorr at microsoft.com>; krbdev at mit.edu
Cc: Scott Konersmann <scottkon at microsoft.com>; Mitchell Sternke <misternk at microsoft.com>; Dylan Gray <Dylan.Gray at microsoft.com>
Subject: Re: - Microsoft SQL Server Linux GSSAPI Questions / Issues

On 01/21/2018 02:22 PM, Robert Dorr wrote:
> We pulled the MIT and github version of the krb5 project. In the MIT version we can execute configure in the src directory and then make and build as expected.
> The github version states it is a replica of the MIT version.

The github krb5/krb5 repository is a mirror of the authoritative MIT
krb5 git repository, which is not publically available.  The tarfile distributions are created from the authoritative git repository, but are not simply checkouts; they have the autoconf-generated files, a build of the documentation, and

> We run autoconf and try to build and it always reports [...]

You want to run "autoreconf" instead of "autoconf".

> Caching Issues

> gss_acquire_cred_from for machine (MACHINE$) – succeeds and creates 
> krb5cc_0 – principal is MACHINE$@DOMAIN.XYZ.XYZ call 
> gss_aquire_cred_with_password for (user at DOMAIN.XYZ.XYZ) – fails with error that cache is not the correct principal If we kdestroy the krbcc_0 and execute the gss_acquire in reverse order the principal for krb5cc_0 is user at DOMAIN.XYZ.XYZ and both calls succeed.
> If we force the cache to be KEYRING:persistant we can kdestroy and run in any order and the api calls succeed.
> Is there a recommended cache for best security and if so how can it be forced?

This answer may be a little scattered, as I can't tell what the desired behavior is for your use case.

If you want to cache credentials for two different client principals in default cache, the default cache needs to use a collection-enabled cache type.  KEYRING and DIR are collection-enabled; FILE is not.

If you are using gss_acquire_cred_from() with a "keytab" key, you could also specify a "ccache" key to control where the obtained credentials will be cached.  This could be a MEMORY cache or a FILE cache at a dedicated location.

gss_acquire_cred_from() unfortunately has different behavior depending on the version.  It originated in Solaris Kerberos, where it stores the obtained credentials in a unique memory cache.  It is then up to the caller to use gss_store_cred() or gss_store_cred_into() to put the credentials into an externally visible cache, if that is desired.  MIT
krb5 1.14 and later have the same behavior.  But prior versions of MIT
krb5 (including 1.13, which is what Ubuntu 16.04 ships with) automatically store the obtained credentials in the default cache.

If you are using gss_acquire_cred_from() and need to work with older versions of MIT krb5, I think the best option is to use
gss_krb5_ccache_name() before the call to set the default ccache to a memory cache, and then again after the call to set it back to the previous value for the thread.

> UPC Failures
> 
> We notice that enabling KRB5_TRACE we often see the following. Is there a way to avoid the UPN call in order to improve performance?
> [20681] 1516383737.459171: Received error from KDC: 
> -1765328332/Response too big for UDP, retry with TCP [20681] 
> 1516383737.459172: Request or response is too big for UDP; retrying 
> with TCP

In krb5.conf, set:

    [libdefaults]
        udp_preference_limit = 0