Hello, We are trying to get a service (a SMB server) running on Linux kerberized using the GSS API. During the negotiation (SPNEGO), the Windows SMB client specifies MS KRB5 (1.2.840.48018.1.2.2) as the preferred mechanism and supplies the initial token. The gss_accept_sec_context method on the server accepts the token and generates a *NegTokenResp*, setting the *negState* to *"accept-completed"* and *supportedMech* to *KRB5 (1.2.840.113554.1.2.2)* among other things.
However, the Windows SMB client, fails with a pretty opaque message. Investigating further, we managed to find this line in [MS-SPNG] SPNEGO extension document: *The server MUST use the erroneous Kerberos value (1.2.840.48018.1.2.2) as the supportedMech field in the response negotiation token if the optimistic Kerberos token (1.2.840.48018.1.2.2) is accepted. * Elsewhere, it is stated: *Windows clients will fail if the accepter accepts the preferred mechanism token (1.2.840.48018.1.2.2), and produces a response token with the supportedMech being the standard Kerberos OID (1.2.840.113554.1.2.2).* We confirmed that this is indeed causing the Windows client to give up (by doing a ugly hack of manually setting the bit to change the KRB OID to the erroneous OID). The question now is this: Is there a better way of doing this? Are we missing something here? Prakash N ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos