Bug 9658 - Session Setup AndX exchange fails with an oversize security token
Summary: Session Setup AndX exchange fails with an oversize security token
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.6
Classification: Unclassified
Component: File services (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-13 14:16 UTC by David Disseldorp
Modified: 2021-02-11 14:03 UTC (History)
2 users (show)

See Also:


Attachments
proposed SMB1 fix (2.07 KB, patch)
2013-02-13 14:20 UTC, David Disseldorp
jra: review+
Details
network capture showing strange security token resend client behaviour (54.47 KB, application/octet-stream)
2013-02-13 14:56 UTC, David Disseldorp
no flags Details
oversize pac authentication attempt, 2k12 client vs XP server (284.15 KB, application/octet-stream)
2013-02-14 10:51 UTC, David Disseldorp
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Disseldorp 2013-02-13 14:16:48 UTC
A user's Kerberos security token grows with group membership, as described in http://support.microsoft.com/kb/327825 . 

When authenticating with a large security token, the token is split across multiple Session Setup AndX requests, to which the server initially responds to with STATUS_MORE_PROCESSING_REQUIRED.

In Samba 3.6 the STATUS_MORE_PROCESSING_REQUIRED Session Setup AndX response does not include the NativeOS, NativeLanMan and PrimaryDomain fields. With these fields missing, some Windows clients (Windows Server 2012 and Windows 7 SMB1 clients) resend the same Kerberos security token in the second request as the sent in the first, rather than the continuation. Authentication fails as a result.

Note, this bug does not affect Samba 4.0.x releases, which use the gensec layer.
Comment 1 David Disseldorp 2013-02-13 14:20:38 UTC
Created attachment 8546 [details]
proposed SMB1 fix
Comment 2 David Disseldorp 2013-02-13 14:56:40 UTC
Created attachment 8547 [details]
network capture showing strange security token resend client behaviour
Comment 3 Jeremy Allison 2013-02-14 00:06:03 UTC
Can you upload a wireshark capture trace showing the same logon against a Win2k server so I can see the STATUS_MORE_PROCESSING_REQUIRED Session Setup AndX response from a Windows server ?

Jeremy.
Comment 4 Jeremy Allison 2013-02-14 00:06:42 UTC
Comment on attachment 8546 [details]
proposed SMB1 fix

I'm pretty sure this is correct. I want to see the Windows reply for my own peace of mind :-).
Comment 5 Jeremy Allison 2013-02-14 00:09:06 UTC
Re-assigning to Karolin for inclusion in 3.6.next.

Jeremy.
Comment 6 David Disseldorp 2013-02-14 10:40:03 UTC
(In reply to comment #3)
> Can you upload a wireshark capture trace showing the same logon against a Win2k
> server so I can see the STATUS_MORE_PROCESSING_REQUIRED Session Setup AndX
> response from a Windows server ?

I don't have a Windows Server 2k host in my test environment, but will attach a capture of a Windows Server 2k12 client attempting Krb authentication with a Windows XP server.
Comment 7 David Disseldorp 2013-02-14 10:51:40 UTC
Created attachment 8551 [details]
oversize pac authentication attempt, 2k12 client vs XP server

Authentication fails in this case with STATUS_TOO_MANY_CONTEXT_IDS, but the client can still be seen correctly responding to the STATUS_MORE_PROCESSING_REQUIRED responses (which include the NativeOS and NativeLanMan fields) with security token continuation data.
Comment 8 David Disseldorp 2013-02-14 12:17:02 UTC
One final note, the Samba 3.6 SMB2 session setup code path does not currently include any support for multi-request authentication with a large security token.
Comment 9 Jeremy Allison 2013-02-15 20:05:32 UTC
Ok, I'm satisfied (except for the SMB2 issue, but let's leave that for another bug :-).

Once Karolin commits the fix we can close it out !

Cheers,

Jeremy.
Comment 10 Karolin Seeger 2013-02-18 08:53:19 UTC
Pushed to v3-6-test.
Closing out bug report.

Thanks!