3.1.4 Higher-Layer Triggered Events
The application initiates NTLM authentication through the Security Support Provider Interface (SSPI), the Microsoft implementation of GSS-API [RFC2743]. NTLM does not support RFC 2743 token framing (section 3.1 [RFC2743]).
The client application calls GSS_Init_sec_context() to establish a security context with the server application.
If the ClientBlocked == TRUE and targ_name ([RFC2743] section 2.2.1) does not equal any of the ClientBlockExceptions server names, then the NTLM client MUST return STATUS_NOT_SUPPORTED to the client application.<40>
NTLM has no requirements on which flags are used and will simply honor what was requested by the application or protocol. For an example of such a protocol specification, see [MS-RPCE] section 220.127.116.11.2.2. The application will send the NEGOTIATE_MESSAGE (section 18.104.22.168) to the server application.
When the client application receives the CHALLENGE_MESSAGE (section 22.214.171.124) from the server application, the client application will call GSS_Init_sec_context() with the CHALLENGE_MESSAGE as input. The client application will send the AUTHENTICATE_MESSAGE (section 126.96.36.199) to the server application.
Once the security context is established, the client application can call GSS_WrapEx() (section 3.4.6) to encrypt messages.
Once the security context is established, the client application can call GSS_UnwrapEx() (section 3.4.7) to decrypt messages that were encrypted by GSS_WrapEx.
Once the security context is established, the client application can call GSS_VerifyMICEx() (section 3.4.9) to verify a signature produced by GSS_GetMICEx().