With krb5-1.10.x and if there is a large clock skew between a member server and a Windows client (greater than 10 hours after the valid start time of tickets or well before the start time of a ticket) Samba will return STATUS_LOGON_FAILURE to a SESSION SETUP request when it should return STATUS_MORE_PROCESSING_REQUIRED and a Krb_error token.
The problem is that gss_accept_sec_context in krb5-1.10.x behaves incorrectly, although it might look like gse_get_server_auth_token in source3/librpc/crypto/gse.c is at fault.
This was seen on CentOS 6.6/7.
This actually a problem with krb5-1.10.x and is fixed in at least kb5-1.13.2.
There is a bug logged against RedHat here:
This bug has been opened so that people searching might quickly realize what the real problem is.
Created attachment 11586 [details]
What Windows returns ...
Windows returns MORE_PROCESSING_REQUIRED with either Ticket Not Yet Valid or Ticket Expired depending on the direction of the clock skew.
Created attachment 11587 [details]
What Samba returns with the faulty version of krb5
Samba simply returns LOGON_FAILURE which causes Windows to prompt for creds again.
The problem is more complex than I thought.
While later versions of krb5, like 1.10.3, do return a token, they do not return a status of GSS_C_CONTINUE_NEEDED. I was transforming GSS_C_FAILURE to GSS_C_CONTINUE_NEEDED in Samba in the case of the two minor codes I was interested in.
More investigation needed.
Working with Simo on this.
As pointed out in the linked RedHat bug, if gss_accept_sec_context returns a token, even when it also returned an error status, we must return that token to the client.
Change #8936281bcc9bef19ede99146475dd867ed5d3873 was committed that fixes the Samba side of this problem.
However, you need a recent version of krb5-libs on your Linux or other system as well.
Do we need to cherry pick this to 4.3.X or 4.2.X?
Created attachment 11594 [details]
git-am fix for 4.3.next, 4.2.next.
Cherry-pick from master for 4.3.next and 4.2.next.