Thursday, February 28, 2013

Enhanced Single Sign-On to Windows AD in FortiOS 5.0

FortiOS 5.0 brings with it an enhancement to how single sign-on can be performed in a Microsoft Active Directory environment.

In prior versions of FortiOS an agent software was needed on either a Domain Controller or a Member Server. There was a lot of push back since many IT admins were not comfortable running third-party software on their critical AD servers. FortiOS 5.0 allows the firewalls to directly query the AD global catalog and event logs, the agents are now optional.

When a Windows AD user logs on at a workstation in a monitored domain, the FortiGate unit:
  • detects the logon event in the domain controller’s event log and records the workstation name, domain, and user
  • resolves the workstation name to an IP address
  • uses the domain controller’s LDAP server to determine which groups the user belongs to
  • creates one or more log entries on the FortiGate unit for this logon event as appropriate
When the user tries to access network resources, the FortiGate unit selects the appropriate security policy for the destination. The selection consists of matching the FSSO group or groups the user belongs to with the security policy or policies that match that group. If the user belongs to one of the permitted user groups associated with that policy, the connection is allowed. Otherwise the connection is denied.

(From the FortiOS 5.0 Authentication Guide)


Paulo Raponi said...

This not working with NTLM yet...

Paulo Raponi

sashkashurik said...

While I have seen this in a guide, I'm not sure that it actually works. The guide itself is written with an agent install in mind(see firewall rules examples just after the setup guide).
Has anyone tested it? How reliable it is? Are there any missed log-on events?

Anonymous said...

I assume that in FG v5 it is polling mode version.
I think that Collector Agent installed on any server (no DC) in domain one big advantage - performance.

With CA all the nasty things are done by CA and then send to FG.
If you use polling mode in FG itself, it will use some resources.

other question is: Do work both variants the same?

Anonymous said...

I would like to know if it is possible to populate some custom information dynamically in the fortigate logging tables?

Anonymous said...

Anyone tested this configuration? it's not worked for me.

OG said...

FW60c FortiOS 5 Patch2, 2012 PDC+SDC

Basicly everything ist working (LDAP, FSSO) - only Problem ATM ist that the Collectors (installed them on both DCs) do not sync the Userlogin Information. So if Fortigate is connectet to PDC it doesn'T get the logininformation from SDC. Debug is in progress and I'll post as soon as I got the error.

dizkonekid said...

Polling mode with the FGT works just fine for medium to low amounts of traffic. It only works if every domain controller in question is also a Global Catalog. The polling events take a lot of I/O so it does not scale well and limits the amount of UTM that can be accomplished on the gate. However, it does make sense for small to medium sized shops who do not want to use the DCAgent.

The one big piece that is missing is the WMI host check that can be performed on the DCAgent for log off events. This decreases the amount of the a "hole" at an IP address is left open once a client logs off the network. If you have DHCP lesases set for under 24 hours then this could very well be a problem.

If you want a recommendation, make sure you consider all the ways FSSO can get accomplished, FGT+DCAgent. FGT polling, and FortiAuthenticator.