NTLM authentication fails with 'The IWA direct realm encountered an unmapped error code'

Products

• ProxySG Software - SGOS

Issue/Introduction

The ProxySG returns the following error when performing NTLM authentication.

Appliance Error (internal_error) An unrecoverable error was encountered. "The IWA direct realm encountered an unmapped error code, contact your system administrator."

 

The following messages are displayed in the LSA Debug Logs.

2756.276 LW_Error_to_auth_result(), mapping unknown error code 40041 to AUTH_E_ONBOX_UNMAPPED_ERROR 2425351
2756.276 gss_accept_sec_context failed. Major: 0xD0000, Minor: 0x9C69(40041). Unknown code Bb 105
2756.276 GSSAPI:  Error in gss_accept_sec_context() at g_accept_sec_context.c:295 [major: 851968, minor: 40041]
2756.276 GSSAPI:  gss_accept_sec_context() at g_accept_sec_context.c:293 [Minor: 40041]
2756.276 TRACE: lsass - [ntlm_gss_accept_sec_context() gssntlm.c:1402] Error code: 40041 (symbol: LW_ERROR_INVALID_PARAMETER)
2756.276 TRACE: lsass - [NtlmClientAcceptSecurityContext() acceptsecctxt.c:93] Error code: 40041 (symbol: LW_ERROR_INVALID_PARAMETER)
2756.276 TRACE: lsass - [NtlmTransactAcceptSecurityContext() clientipc.c:222] Error code: 40041 (symbol: LW_ERROR_INVALID_PARAMETER)
2756.276 TRACE: lsass - [NtlmServerAcceptSecurityContext() acceptsecctxt.c:115] Error code: 40041 (symbol: LW_ERROR_INVALID_PARAMETER)
2756.276 TRACE: lsass - [NtlmCreateChallengeContext() acceptsecctxt.c:283] Error code: 40041 (symbol: LW_ERROR_INVALID_PARAMETER)
2756.276 TRACE: lsass - [NtlmCreateChallengeMessage() context.c:556] Error code: 40041 (symbol: LW_ERROR_INVALID_PARAMETER)

Cause

NTLM is a challenge/response protocol. The client sends a Type 1 message, the proxy responds with a Type 2 message, then the client provides its complete credential in a Type 3 message. This all must occur on the same TCP connection.

There are generally two possible causes that result in this error state:

1. The Type 1 message contains an invalid parameter.
2. If the proxy receives the Type 3 message on a new connection, it tries to parse it as a Type 1 message since it's the first message on the connection.

Resolution

1. If the error is returned in response to a Type 1 message, validate the Type 1 message does not contain any invalid parameters.
2. If the error is returned in response to a Type 3 message, ensure all of the NTLM Type 1, 2, and 3 messages occur on the same TCP connection.
   
   The ProxySG will add Connection: Keep-Alive in the Type 2 response message's HTTP headers. It has been seen in some environments that an intermediary device such as an HTTP WAN optimizer can be configured to change this header to Connection: Close causing the client browser to split the Type 3 message onto a separate connection. Such a configuration will cause this issue.