FortiGate Agentless FSSO: apply security rules based on AD objects (usernames, groups, etc...) without deploying any software/agents...
Hi friends,
Here we are again with the last post of 2024, but before we begin, let me make a musical recommendation: "Cannonball" (Supertramp 1985)…”yeah, like a cannonball!”
Well, let's get down to business..Fortinet Single Sign-On (FSSO) is a feature that enables seamless user “identification” by integrating FortiGate devices with Active Directory (AD). Traditionally, implementing FSSO required installing a Collector Agent on domain controllers, which not always is possible. To simplify deployment, Fortinet introduced the Agentless FSSO feature, allowing FortiGate devices to directly poll AD servers for user login events without the need for additional software on domain controllers.
Agentless FSSO provides near-instantaneous identification of user logins and logouts by monitoring Active Directory (AD) security logs. This real-time monitoring enables the dynamic application of security policies based on user identity and role.
While this feature is relatively common among other manufacturers, if you find it surprising, I encourage you to analyze it further and consider implementing it in your environment.
However, before deploying this feature in a production environment, ensure it meets your security and operational requirements. Proper evaluation is crucial to avoid potential issues.
As you know, I enjoy testing things out. I always make an effort to verify every feature or solution, and this case will be no exception. It’s one thing to write about "something" based solely on theory, data sheets, or marketing presentations—which is fine—but it’s far better to test and experience it firsthand.
FortiGate-VM
For this post, I deployed a FortiGate virtual machine with an evaluation license: FortiGate VM Administration Guide on VMware ESXi. Naturally, this type of license comes with certain limitations, which are detailed here: Evaluation License Limitations.
One limitation I find worth highlighting is that it is not possible to use certificates with keys longer than 512 bits. In other words, I was unable to use certificates with key lengths of 1024 bits or higher, as this license only allows encryption operations with lower key lengths (low encryption operation only).
Considering the described restrictions, the product performs very well and meets all expectations.
The LAB
The following is the high-level topology used in this lab:
As you can see, the lab consists of different user subnets deployed within the same VRF. When I say "in the same VRF," I mean that, in this case, there is no firewall (or other device) enforcing security policies between these networks. The only active firewall is the FortiGate virtual machine.
A DHCP service has been implemented for all user networks.
In addition to the user networks and DMZs, the lab also includes an Active Directory (pkiot.local) composed of four domain controllers located in different sites.
What is the purpose or use case of this post?
The goal of this lab is to apply security policies based on users or groups, regardless of the network they are connected to—whether it’s Network 1, Network 2, Network 3, Network 4, etc.
For example, let’s suppose there is a web server in the DMZ, debian-web-01.pkiot.local (192.0.2.101), and only users from the Finance department should have access to this server.
Members of the Finance department can move between different networks without restrictions, so we must ensure that security policies are applied at each access:
As you can see, the source IPv4 address of the user "financialuser01" depends on the location they are connected to, and in each location, there is a different DHCP pool. Trying to assign the same IPv4 address from each pool to each user would be... to say the least, complicated.
This is where the FortiGate (Agentless) FSSO functionality comes into play. What the FortiGate firewall will do is query each domain controller about logins and logouts to identify the IPv4 address associated with each user.
It is important to mention that all domain controllers should be included to gather as much information as possible.
Thanks to this functionality, what we can do is apply security policies based on AD users or groups almost instantly. For certain environments, this is more than enough; for others, it is not.
This is the access to debian-web-01.pkiot.local from a machine where the user "financialuser01" has logged in:
The following image shows the logs of the access in the FortiGate:
FortiGate Agentless FSSO configuration
The configuration of this functionality is divided into 3 parts:
1. Configure an LDAP Server
An AD can be composed of multiple DCs, and, as expected, AD users can log in to the AD using any of the DCs that are part of it. In this lab, 4 DCs have been created in the AD; therefore, in FortiGate, we will configure the 4 DCs as LDAP servers.
User & Authentication → LDAP Servers
Remember: In the lab, I am using unencrypted LDAP (TCP/389). The reasons are clear, but in production, please implement LDAPS (usually TCP/636).
It's time to create the identity connectors for the AD DCs. Through these connectors, polling is configured on each AD DC, which allows the FortiGate to retrieve the log information for each user. With this information, the FortiGate is able to determine the IPv4 address associated with each user.
Security Fabric → External Connectors
Below is the configuration of one of the DCs that make up the AD:
By clicking on the "Edit" box in Users/Groups, we can access the AD tree and select the objects we need to use in our security policies (firewall rules). For this lab, 4 groups have been selected: DEVELOPMENT, FINANCIAL, HHRR, and OPERATIONS.
The AD objects that have been selected can also be seen here:
3. Configure the firewall policies with user/group identification
Once we have created the LDAP servers (in this case, the DCs), configured polling on the DCs, and selected the objects we need to use in our firewall policies, the only thing left is to proceed with the creation of the firewall policies.
Policy & Objects → Firewall Policy
If we edit the policy and modify the User/Group field, we can include, among others, the AD groups that we previously selected during the polling configuration (External Connectors):
Test 1: Access only for users belonging to an AD group
Once the firewall policy configuration is complete, it's time to test the access. To do this, we will log in to the AD with a user belonging to the FINANCIAL group, financialuser01, test the access to the server in the DMZ, and finally review the logs on our FortiGate:
Below are the log entries from the firewall logs:
For reference, I include the LDAP messages between the FortiGate and DC1. Basically, the firewall queries the group membership of the user "financial01," and DC1 responds with the result:
In order to verify proper functionality for users who do not belong to the "FINANCIAL" group, we will log in with another user on the same machine: "developmentuser01":
Below are the logs recorded in the firewall:
The following images show the LDAP captures between the FortiGate and one of the DCs regarding the user "developmentuser01" and their group membership. Query from FortiGate to DC1 (w2k12-01.pkiot.local):
Response from DC1 (w2k12-01.pkiot.local): memberof "DEVELOPMENT", meaning the user does not belong to the "FINANCIAL" group, which is the one allowed in the security rule.
Test 2: Access from another network/location
In this case, we will test access to the resources in the DMZ from a user belonging to the "FINANCIAL" group, but connected from another network/location, for example, 192.168.6.0/24. As expected, everything works correctly:
Test 3: What happens in the event of a failure of one or more DCs?
The tests conducted so far have used DC1 (w2k12-01.pkiot.local) for both user logins to the domain and the queries made from the FortiGate. To ensure the proper functioning of the solution, we will proceed to disconnect DC1 and DC4 (w2k12-04.pkiot.local). This way, we will verify if the solution remains stable.
Below are the captures of the LDAP queries from the FortiGate firewall, in this case, towards DC2 (w2k12-02.pkiot.local):
Of course, the security policy continues to work correctly:
If we now log in with another user who does not belong to the FINANCIAL group, for example, hhrruser02, the security policy that will be applied will be the denial policy:
Below are the LDAP queries from the firewall to DC2 (w2k12-02.pkiot.local). As seen, the group that hhrruser02 belongs to is HHRR, not FINANCIAL:
Conclusion
The FortiGate Agentless FSSO (Single Sign-On) functionality represents an efficient and flexible solution for integrating user- or group-based authentication from Active Directory (AD) into network security policies. This functionality eliminates the need to install additional software on servers, simplifying deployment and maintenance.
By centralizing user authentication directly from the domain controller, FortiGate enables organizations to apply dynamic and specific security policies based on the identity of users or groups. This optimizes security management, allowing more granular control over resource access while enhancing the end-user experience with seamless authentication.
In summary, FortiGate Agentless FSSO is a valuable tool for organizations seeking to combine operational efficiency and robust security, leveraging the capabilities of their existing AD infrastructure to implement policies tailored to the specific needs of each user or group. However, always analyze your production environment and ensure that this approach meets your security, operational, and other requirements. Perhaps choosing agent based FSSO is better for you if there is a large user base, if you need better support for multi-domain environments, if you need more detail of event logging (It allows granular monitoring of logon events, including workstation-based logins), if you need more reliability and enhanced security, etc...
Documentation
Manager for OT/ICS/xIoT Cybersecurity Development. Senior Advisor for Regulation, Risks and Emerging Technologies Landscape
2 个月Congrats for such interesting work! Let me tell you that there is another tool, FortiAuthenticator, that allows to expand these capabilities from one Firewall to choose different firewalls, allowing to configure AD integrations once but leveraging at scale and establish a complete Role Based Access Policy for the different privileges to the different network segments
Network Engineer | Telecomunication | CCNA
2 个月Great!