[RFC] fix bug 12007

[Simo]

Sorry have been thinking more.

On Mon, 2016-07-04 at 11:40 -0400, Simo wrote:
> On Mon, 2016-07-04 at 00:06 +0300, Uri Simchoni wrote:
> > 
> > On 07/04/2016 12:00 AM, Uri Simchoni wrote:
> > > 
> > > 
> > > Hi,
> > > 
> > > Attached is a proposed fix for bug 12007 - spurious AS requests
> > > for
> > > "root at my.domain.com" generated by a member server. Still running
> > > it
> > > through local autobuild.
> > > 
> > > The issue surfaced after the April security release, that started
> > > using
> > > gensec_gse for binding ldap connections.
> > > 
> > > The root cause is that with Heimdal, gss_acquire_cred() is
> > > generating
> > > this AS request if the credentials are not found in the ccache. I
> > > have
> > > no idea what good can possibly come out of this AS request for
> > > any
> > > user
> > > of Kerberos. The attached fix replaces gss_acquire_cred by
> > > gss_krb5_import_cred().

This sounds wrong, and we should fix Heimdal if it is trying to re-
acquire the same ticket, not try to work around it.

Are you saying the current ccache has a valid TGT but it ignores it and
tries to acquire a new one ?

If there are no credentials it is perfectly normal to make an AS
request, I do not understand what the problem is here. Do we, by chance
copy in some ccache just the LDAP ticket and not the TGT ?

> > > I'd like some feedback from those familiar with this code -
> > > 1. It could be that the right fix is in Heimdal

Definitely if it really is a bug in finding a valid credential in the
cache.

> > > 2. The reason for acquiring the credentials (in client context!)
> > > seems
> > > to be to be able to set GSS_KRB5_CRED_NO_CI_FLAGS_X option on the
> > > credentials - not sure what scenario this fixes and how to test
> > > there's
> > > no degradation there.

This is fundamental, otherwise LDAP binds will fail because AD uses the
CI flags instead of the SASL negotiation, so we need to be able to
control exactly what flags we send (normally both Heimdal and MIT
Kerberos send both Confidentiality and Integrity flags unconditionally,
because that is mandated by the Spec, but Microsoft interpreted it
differently in some protocols).

> > > 3. Perhaps someone can easily determine the MIT behavior - if MIT
> > > is not
> > > sending this request then maybe the patch should be #ifdef'd on
> > > Kerberos
> > > type - use the more portable gss_acquire_cred() with MIT
> > > Kerberos.

We must use gss_acquire_cred() sorry.

> > > Thanks,
> > > Uri.
> > > 
> > One more things - the gensec_gse code also makes an extra TGS
> > handshake,
> > requesting a TGT, because it requires delegation for the security
> > context. Do we need delegation for LDAP sasl binding/wrapping?

> Generally no, we don't, it should be somehow selectable, base on the
> target machine's "allowed to delegate to" (IIRC) flag.

Brain fart here. We *definitely* almost never want to delegate a TGT,
but we definitely want to request a forwardable ticket, so that the
server can perform constrained delegation if it is authorized and so
configured.

What flags are passed in ? Can you point me at the code path that
generates this ?

Simo.