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 ([RFC2743] section 3.1).

  • GSS_Init_sec_context

    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.<42>

    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 3.3.1.5.2.2. The application will send the NEGOTIATE_MESSAGE (section 2.2.1.1) to the server application.

    When the client application receives the CHALLENGE_MESSAGE (section 2.2.1.2) 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 2.2.1.3) to the server application.

  • GSS_Wrap

    Once the security context is established, the client application can call GSS_WrapEx() (section 3.4.6) to encrypt messages.

  • GSS_Unwrap

    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.

  • GSS_GetMIC

    Once the security context is established, the client application can call GSS_GetMICEx() (section 3.4.8) to sign messages, producing an NTLMSSP_MESSAGE_SIGNATURE structure (section 2.2.2.9).

  • GSS_VerifyMIC

    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().

Show: