共用方式為

3.1.4 Higher-Layer Triggered Events

  • 發行項

The application SHOULD<44> initiate NTLM authentication through the Security Support Provider Interface (SSPI).  NTLM does not support token framing as defined in [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 ([MS-ERREF] section 2.3.1) to the client application.<45>

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