gensec returns the wrong error to kerberos errors like Ticket Expired and clock skew issues

[Richard Sharpe]

On Sat, Nov 7, 2015 at 12:32 AM, Stefan Metzmacher <metze at samba.org> wrote:
> Am 06.11.2015 um 03:22 schrieb Richard Sharpe:
>> On Wed, Nov 4, 2015 at 11:23 AM, Jeremy Allison <jra at samba.org> wrote:
>>> On Wed, Nov 04, 2015 at 11:14:50AM -0800, Richard Sharpe wrote:
>>>> On Wed, Nov 4, 2015 at 10:22 AM, Jeremy Allison <jra at samba.org> wrote:
>>>>> On Wed, Nov 04, 2015 at 10:00:48AM -0800, Richard Sharpe wrote:
>>>>>> Hi folks,
>>>>>>
>>>>>> A capture I have indicates that when a Windows server gets a
>>>>>> KRB5KRB_AP_ERR_TKT_EXPIRED error it returns
>>>>>> STATUS_MORE_PROCESSING_REQUIRED along with an SPNEGO negTokenTarg with
>>>>>> the Kerberos error blob in it.
>>>>>>
>>>>>> Samba, and it looks like gensec, folds that down to LOGON_FAILED,
>>>>>> which makes it very hard for admins to figure out what the real error
>>>>>> is.
>>>>>>
>>>>>> Is there a bugzilla on this?
>>>>>>
>>>>>> If I get a chance I will try to provide a fix.
>>>>>
>>>>> I think that is intentional in order to prevent
>>>>> username guessing attacks.
>>>>
>>>> That doesn't even pass the smell test. The KDC is responsible for
>>>> preventing password guessing games.
>>>
>>> Sure, but smbd is also. Remember we have our own passdb
>>> code which has to implement the same protections.
>>>
>>> However, I haven't looked at that bit of gensec recently
>>> so you may be right here :-).
>>
>> It looks like perhaps in
>> source3/librpc/crypto/gse.c:gse_get_server_auth_token in the default
>> arm of the switch, if gse_min is KRB5KRB_AP_ERR_TKT_EXPIRED or
>> KRB5KRB_AP_ERR_TKT_NYV we should return
>> NT_STATIS_MORE_PROCESSING_REQUIRED.
>>
>> I will see if this produces a response more to the liking of Windows.
>
> Can you file a bug report and attach network captures against windows
> and against
> Samba?

OK, I will likely file a bug, but it looks like this is a problem to
do with the version of MIT Kerberos 5 you are using.

Having done some debugging and a lot of code inspection, it looks like
this is not something that Samba can get right or wrong. The problem
is in gss_accept_sec_context in versions up to at least 1.10.3 and
perhaps later, but I have not checked all versions. Also, I have not
checked versions earlier than 1.10.3 in CentOS 6.6 so it might be a
regression in that version.

In version 1.10.3+ (from CentOS/RHEL 6.6 krb5-1.10.3-37) there is a
path where it seems to forget to create an output token on an error
where the AP request was decoded, however, 10.13.2 does not seem to
have this bug.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)