[Steven French]

The negprot response is interestingly different between Samba head and
Win2K although it may be harmless. The oids are in reverse order in Samba
from the OIDs in spnego negprot security blob that Win2K server sends and
one oid is missing.  Presumably this ordering encourages the client to use
NTLMSSP when going to Samba while the clients would be encouraged to use
Kerberos when going to Win2K.  The missing oid is 10 bytes - 2a 86 48 86 f7
12 01 02 02 03 which appears to be an interesting subdialect of ("user to
user") Kerberos ticket exchange which is even documented. Take a look at:
http://www.wedgetail.com/jcsi/2.2/kerberos/apidocs/com/dstc/security/kerberos/gssapi/package-summary.html
 which mentions draft-swift-win2k-krb-user2user-02.txt    It is not clear
whether the missing encryption type is important (it seems optional). Samba
server seems to prefer NTLMSSP (by listing it first, before Kerberos in the
Negprot response) so the client might not even use it if the missing
Kerberos OID were offered.  In addition the security blob in the NTLMSSP
final SessSetup Response is 0 bytes in the Samba case and non-zero
(although the ASN1 equivalent of an empty response) in the Win2K response.

Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at us.ibm.com