Using sAMAccountName in Firewall Policies via Remote LDAP User Definitions with FSSO

[cheetah111]

Current Setup:
I have configured FSSO with FortiGate.
By default, when defining users in a firewall policy using FSSO, I have to select users via CN (Common Name) rather than sAMAccountName.
To resolve this, I created a User Definition on the FortiGate with the type Remote LDAP. This allows me to define the user in the firewall policy using the sAMAccountName.

Observations:
In my testing, this works well. When a user logs in/out of Windows, FSSO detects the event and sends the log events to the FortiGate.
Even if a user changes their IP while logged in, FSSO detects the new IP and updates the FortiGate.
Overall, the tests are successful.

Questions:
1. Because I cannot find any official documentation supporting this specific configuration. Are there any hidden risks?
2. Is this feasible for a production environment?
3. Can someone explain the mechanism and the difference between this and the standard configuration?

[Markus_M]

It will help to say how your FSSO setup is done. FSSO works by reading a logon event with the user information from the DC. This will be collected and then sent to the firewall. Typically, the collecting is done with a Collector Agent. It is also possible but quite limited to do that with the FortiGate directly, polling the DC.

In the logon event we find the username and the workstation. We use the former to make a group lookup. We use the latter to find the IP of the workstation and continually lookup the IP, in case it changes.

It matters here more what the username in the logon event is and the lookup is done against it. If there is a match against the CN, it is fine. If there is a match against the sAMAccountName that is also fine, although the configuration needs to be in place. The attributes CN or sAMAccountName are only attributes of the user object. The LDAP query will only ask for "give me an object (=user) that has the Attribute value =username, in the Attribute name of sAMAccountName or CN (or whatever is defined). If there is no match, the group lookup will fail.

That information of FSSO must be present on the FortiGate in the firewall user monitor. It has the IP, user and group. If that information is correct, FSSO will work. You can test simply by looking at the list. If the list is correct, the FortiGate policies will work with these groups or users. The group part is however more common and in practice there should be specific FSSO group that describe the intended access of FSSO users in the firewall policies. Add users to these groups (like "regular internet", "no facebook", "no webmail") and apply webfilter or application control to the policies.