Spurious AS request in ads_sasl_spnego_bind() (was: Re: Event log 4768 audit failure)

[Uri Simchoni]

Hi,

I had a closer look at this, and it looks like the spurious AS request
is created because in ads_sasl_spnego_bind(), the order of events is:
1. Try ads_sasl_spnego_gensec_bind()
2. If that fails, do a kinit and retry

Presumably, the idea is that step 1 is supposed to leverage a cached
TGT, thus avoiding another AS handshake, and if there isn't any, do a
kinit to obtain a TGT and retry the sasl bind.

What actually happens, is that in step 1, if there's no cached TGT, the
code generates an AS request, but a wrong one - using the name of the
current user (hence "root" as reported).

What I'm not sure about is what's the right direction for the fix - is
it to avoid generating an AS request in step 1), or to generate the
RIGHT AS request in step 1 (AFAIK, generating a TGT is outside the scope
of GSSAPI, GSSAPI can only acquire a TGT from a cache, so I'm not sure
why it even tries that).

Maybe we can use gensec to determine whether we have a TGT, instead of
calling ads_sasl_spnego_gensec_bind() twice?

Instead of:
ads_sasl_spnego_gensec_bind();
if (!success) {
	ads_kinit_password();
	ads_sasl_spnego_gensec_bind();
}

Change to:
if (!gensec_we_have_a_tgt()) {
	ads_kinit_password();
}
ads_sasl_spnego_gensec_bind();

Any pointers/comments would be welcome.

Thanks,
Uri.

On 06/08/2016 09:28 PM, Uri Simchoni wrote:
> On 06/08/2016 06:38 PM, VigneshDhanraj G wrote:
>> Hi all,
>>
>> Hi all,
>>
>> I upgraded samba from 4.2.9 to 4.2.12. After upgrade i am seeing numerous
>> amount of kerberos errors in DC event. Event id- 4768(Audit Failure)
>>
>> A Kerberos authentication ticket (TGT) was requested.
>> Account Information:
>> Account Name: root
>> Supplied Realm Name: TEST.LOCAL
>> User ID: NULL SID
>> Service Information:
>> Service Name: krbtgt/TEST.LOCAL
>> Service ID: NULL SID
>>
>> There is no user as root in my DC and there is no functionality breakup. It
>> is getting correct user name .But, by default first kerberos ticket
>> requested by root. whenever samba is restarted or communicating with my
>> system. Audit failure logs are dumped.
>>
>> I think it might be a regression issue from samba while fixing badlock.
>>
>> could anyone help regarding this issue?
>>
> 
> Seen it too (in packet traces, 4.3.latest, net ads join -k, bundled
> Heimdal), but have zero time to work on it at the moment. If none gets
> there first I'll fix it in a couple of weeks (or at least look into it).
> Haven't seen any functional impact until you mentioned that audit log.
> 
> Thanks,
> Uri.
>