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

Richard Sharpe realrichardsharpe at
Sun Nov 8 03:10:31 UTC 2015

On Sat, Nov 7, 2015 at 12:32 AM, Stefan Metzmacher <metze at> wrote:
> Am 06.11.2015 um 03:22 schrieb Richard Sharpe:
>> On Wed, Nov 4, 2015 at 11:23 AM, Jeremy Allison <jra at> 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> 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
>> 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.

Richard Sharpe

More information about the samba-technical mailing list