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: [EMAIL PROTECTED]