Fortinet FSAE manual Proxy-Authorization Ntlm negotiate string header

NTLM authentication Using FSAE on your network

3The client connects again, and issues a GET-request, with a

Proxy-Authorization: NTLM <negotiate string> header.

<negotiate-string>is a base64-encoded NTLM Type 1 negotiation packet.

4The FortiGate unit replies with a 401 “proxy auth required” status code, and a Proxy-Authenticate: NTLM <challenge string> (a bae64- encoded NTLM Type 2 challenge packet. In this packet is the challenge nonce, a random number chosen for this negotiation that is used once and prevents replay attacks.

Note: It is vital that the TCP connection is kept alive, as all subsequent authentication- related information is tied to the TCP connection. If it is dropped, the authentication process must start again from the beginning.

5The client sends a new GET-request with a header:Proxy-Authenticate: NTLM <authenticate string>, where <authenticate string> is a NTLM Type 3 Authentication packet that contains:

•user name and domain

•the challenge nonce encoded with the client password (it may contain the challenge nonce twice using different algorithms)

6The FortiGate unit checks with the FSAE client (over port 8000) to see if the authentication hash matches the one on the domain controller. The FortiGate unit will deny the authentication via a 401 return code and prompt for a username and password, or return an “OK” response and the Window’s group name(s) for the client.

Unless the TCP connection is broken, no further credentials are sent from the client to the proxy.

7The FortiGate unit uses the group name(s) to match a protection profile for the client, and establishes a temporary firewall policy that allows future traffic to pass through the FortiGate unit.

Note: If the authentication policy reaches the authentication timeout period, a new NTLM handshake occurs.

	Fortinet Server Authentication Extension Version 1.5 Technical Note
18	01-30005-0373-20071001