[20146] in Kerberos_V5_Development
Re: Oracle ODP.NET use of MIT KfW
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Jul 24 17:46:15 2020
To: Scot McKinley <scot.mckinley@oracle.com>, <krbdev@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <ad8a80d0-88d1-1d00-e11e-e2a2cbacae57@mit.edu>
Date: Fri, 24 Jul 2020 17:46:05 -0400
MIME-Version: 1.0
In-Reply-To: <a509a416-3cad-7445-f6c6-659501272aae@oracle.com>
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On 7/24/20 4:41 PM, Scot McKinley wrote:
> * The announcement pages for the KfW have quoted support for the exact
> same Windows versions for at least 7 years, probably longer. The below
> statement has been exactly the same for versions 4.0.1, 4.1 AND the new
> 4.2beta1. Can we get it updated?
I've made a note to update it.
> * The Microsoft Credential Guard blocks acquisition of windows domain
> based TGTs, thus blocking MSLSA based KfW credential acquisition. Has
> this been addressed in 4.2beta1 or are there plans to address it (eg, by
> switching to a SSPI based credential acquisition)?
When using the MSLSA cache, KfW attempts to acquire credentials via the
SSPI (LsaCallAuthenticationPackage with
KERB_RETRIEVE_TICKET_CACHE_TICKET). For local-realm use, it should not
be necessary to retrieve the TGT.
If Credential Guard is blocking even the obtaining of service tickets by
applications (I'm not clear on whether this is true), then it's
conceivable that libgssapi_krb5 could use the LSA to obtain GSS tokens,
bypassing libkrb5 altogether. At that point it might be simpler to use
a GSS shim to the Microsoft krb5 implementation, which I believe already
exists.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
