Front-side NTLM authentication

Airlock IAM supports NTLMv2 authentication of clients. Note that we do not recommend NTLMv2 authentication due to security flaws in the protocol.

Note that this feature has been deprecated and will be removed. See Features discontinued with the JSP-Loginapp.

Use Front-side Kerberos authentication instead.

The following diagram shows the general workflow of an NTLM authentication:

1. The user tries to access the resource under /protected. The corresponding mapping on the airlock is protected and uses Airlock IAM as one-shot authenticator.
2. There is no NTLM header in the request. Hence, Airlock IAM requests to do NTLM authentication with the user by adding the "WWW-AUTHENTICATE NTLM" header to the message. Note that in case BASIC-authentication is configured, also a "WWW-AUTHENTICATE Basic realm="..."" header with a configurable realm is added.
3. The user's browser sends an NTLM T1 message. Airlock forwards this message to its one-shot authenticator Airlock IAM. Airlock IAM answers with an NTLM T2 message.
4. The user's browser responds with an NTLM T2 message. Airlock also forwards this message to its one-shot authenticator Airlock IAM. Airlock IAM extracts the information from the T3 message and starts a NETLOGON call with a domain controller. When the domain controller accepts the username/password combination, Airlock IAM performs an optional internal authentication and afterward the identity propagation.
5. Finally, Airlock IAM tells Airlock Gateway (WAF) to forward the request to the backend.

Note that the NTLM connection is based upon connections and does not care about the Session Cookie inside Airlock.

• NTLM configuration (one-shot flow)