Good morning once again Adam. I am sending this, as I have not received your response to my email of Sept 10 (shown below).
Please note the information provided below lists remaining issues, which our document developers are still working on. I will update you as information develops. Regards, Bill Wesse MCSE / Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -----Original Message----- From: Bill Wesse Sent: Wednesday, September 10, 2008 7:14 AM To: 'Adam Simpkins' Cc: '[EMAIL PROTECTED]' Subject: Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO Good afternoon Mr. Simpkins. We have completed our investigations concerning your request for correction assistance regarding NTLM authentication using SPNEGO (in [MS-NLMP]), and have provided the document changes shown below. These changes will be available in a future document refresh. Please note that your other comments (shown in 'Remaining Issues' below are still under investigation. I will keep you updated as developments occur. ============================================================================== Original Comment: When NTLM authentication is negotiated over SPNEGO, Windows clients do not properly wrap the initial NTLM token inside a GSS-API InitialContextToken (described in RFC 2743 section 3.1). [MS-NLMP] Document Change: <#> Section 3.2.5.2: This behavior is present on Windows Vista, Windows Server 2003, Windows XP, and Windows 2000. For backward compatibility and historical reasons, the Windows implementation of SPNEGO has the following behavior: it accepts raw Kerberos messages that are based on [RFC4121] and [RFC4120], and it accepts raw NTLM messages that are not embedded in [RFC4178] SPNEGO messages. This behavior is known as the Universal Receiver behavior. ============================================================================== Remaining Issues: [MS-SPNG] Inside the actual note <5> in Appendix A, it would be nice to also mention that the inner mechToken/responseToken always contains the standard OID (1.2.840.113554.1.2.2) in the thisMech field, even when the supportedMech chosen by SPNEGO is 1.2.840.48018.1.2.2. Windows servers do not accept the "truncated" OID in the thisMech field. Another related point that should probably be documented is that Windows servers do not seem to accept well-formed GSS InitialContextTokens containing NTLMSSP. I have attached a trace of that, too (gss_ntlmssp.cap frame 7). (The server is the same Windows Server 2003 system as in the other traces.) Regards, Bill Wesse MCSE / Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
