NTLM in a multiple domain environment
In a multiple domain environment for NTLM, the important factor is that there is a trust relation between the domains. In a forest, this relation is automatically created. So you can install FSSO agent on one of the domain controllers without worry.
But in case of multiple domains that are not in a forest, you need to create a trust relation between the domains. If you do not want to have a trust relation between your multiple domains, you need to use FSAE 4.0 MR1 and the DC agent needs to be installed once on each domain. Then you can use security policies to configure server access.
In
Figure 83, three domains are shown connected to the FSSO Collector agent server. The Client logs on to their local Domain Controller, which then sends the user logon event information to the Collector Agent. When the Client attempts to access the Internet, the FortiGate unit contacts the Collector Agent for the logon information, sees the Client is authenticated, and allows access to the Internet. There are multiple domains each with a domain controller agent (DCagent) that sends logon information to the Collector agent. If the multiple domains have a trust relationship, only one DCagent is required instead of one per domain.
Figure 83: FSSO NTLM with multiple domains not in a forest
Understanding the NTLM authentication process
1. The user attempts to connect to an external (internet) HTTP resource. The client application (browser) on the user’s computer issues an unauthenticated request through the FortiGate unit.
2. The FortiGate is aware that this client has not authenticated previously, so responds with a 401 Unauthenticated status code, and tells the client which authentication method to reply with in the header: Proxy‑Authenticated: NTLM. Then the initial session is dismantled.
3. The client application connects again to the FortiGate, and issues a GET-request, with a Proxy‑Authorization: NTLM <negotiate string> header. <negotiate‑string> is a base64-encoded NTLM Type 1 negotiation packet.
4. The FortiGate unit replies with a 401 “proxy auth required” status code, and a Proxy‑Authenticate: NTLM <challenge string> (a base 64-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.
| The TCP connection must be 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. |
5. The 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:
6. username and domain
7. the challenge nonce encoded with the client password (it may contain the challenge nonce twice using different algorithms).
If the negotiation is successful and the user belongs to one of the groups permitted in the security policy, the connection is allowed, Otherwise, the FortiGate unit denies the authentication by issuing a 401 return code and prompts for a username and password. Unless the TCP connection is broken, no further credentials are sent from the client to the proxy.
| If the authentication policy reaches the authentication timeout period, a new NTLM handshake occurs. |
