Agent-based FSSO

FSSO NTLM authentication support

In a Windows AD network, FSSO can also provide NTLM authentication service to the FortiGate unit. When the user makes a request that requires authentication, the FortiGate unit initiates NTLM negotiation with the client browser. The FortiGate unit does not process the NTLM packets itself. Instead, it forwards all the NTLM packets to the FSSO service to process.

NTLM has the benefit of not requiring an FSSO agent, but it is not transparent to users, and the user’s web browser must support NTLM.

The NTLM protocol protects the user’s password by not sending it over the network. Instead, the server sends the client a random number that the client must encrypt with the hash value of the user’s password. The server compares the result of the client’s encryption with the result of its own encryption. The two will match only if both parties used the same password.

FSSO NTLM authentication support

NTLM authentication

If the NTLM authentication with the Windows AD network is successful, and the user belongs to one of the groups permitted in the applicable security policy, the FortiGate unit allows the connection but will require authentication again in the future when the current authentication expires.

Fortinet has tested NTLM authentication with Internet Explorer and Firefox browsers.

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 the figure below, 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 FSSO NTLM authentication support

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.

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.

  1. 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 base64encoded NTLM Type 1 negotiation packet.

  1. 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.

  1. 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:

 

l username and domain l the challenge nonce encoded with the client password (it may contain the challenge nonce twice using different algorithms).

  1. 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.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

This entry was posted in FortiGate, FortiOS 5.6 on by .

About Mike

Michael Pruett, CISSP has a wide range of cyber-security and network engineering expertise. The plethora of vendors that resell hardware but have zero engineering knowledge resulting in the wrong hardware or configuration being deployed is a major pet peeve of Michael's. This site was started in an effort to spread information while providing the option of quality consulting services at a much lower price than Fortinet Professional Services. Owns PacketLlama.Com (Fortinet Hardware Sales) and Office Of The CISO, LLC (Cybersecurity consulting firm).

One thought on “Agent-based FSSO

  1. Stewart Myles

    Thanks I find your site useful, I have followed these instructions and we have a issue where users are not detected by the Fortinet agent if they move from wireless to LAN and vice versa, also if user come out of sleep mode they won’t have any internet, any ideas were to look?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.