- Microsoft SQL Server Linux GSSAPI Questions / Issues

[Greg Hudson]

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