Security Blob: 605506062B0601050502A04B3049A00E300C060A2B060104...
GSS-API Generic Security Service Application Program Interface
OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
SPNEGO
negTokenInit
mechTypes: 1 item
Item: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP -
Microsoft NTLM Security Support Provider)
mechToken:
4E544C4D535350000100000097B208E2060006002F000000...
NTLMSSP
NTLMSSP identifier: NTLMSSP
NTLM Message Type: NTLMSSP_NEGOTIATE
(0x00000001)
Flags: 0xe208b297
Calling workstation domain: NLW2K8
Calling workstation name: PHANTOM
In CIFS, Windows clients typically send raw NTLMSSP messages in non AD
environment while domain clients send NTLMSSP w/ SPNEGO. I don't really
know whether my observation apply here when NTLM is used as a SASL mech.
Natalie
Max (Weijun) Wang wrote:
How are these 2 forms used (by MS and others)? I've never seen an NTLM token
embedded inside the SPNEGO initial context token.
Thanks
Max
On Feb 4, 2010, at 1:14 AM, Nicolas Williams wrote:
On Wed, Feb 03, 2010 at 08:54:03AM -0800, Natalie Li wrote:
Nicolas Williams wrote:
On Wed, Feb 03, 2010 at 08:34:13AM -0800, Natalie Li wrote:
Max (Weijun) Wang wrote:
Hi Nico
Is there a separate OID for NTLM as a GSS-API mech?
Yes, OID for NTLM is "1.3.6.1.4.1.331.2.2.10"
And the encoded OID octet string is:
102 #define GSS_MECH_NTLMSSP_OID
"\053\006\001\004\001\202\067\002\002\012"
But it doesn't go on the wire in the initial context token, right?
No, if you're interested in implementing raw NTLMSSP (i.e. without the
SPENGO wrapper).
Yes, if the NTLM mech token is embedded in the SPNEGO initial context token.
What a wrinkle! :) Thanks for the info.
