Multiple LDAP servers, one for Authentication and one for Authorization?
I have a deployment coming up where we want to SSO/authenticate against Active Directory LDAP and authorize application access in OpenLDAP groups.
FortiOS 7.0.x on Fortigate 1801f and 101f. I don't believe we are planning on FortiAuthenticator at this time.
I imagine that (if this is even possible) this would require that the usernames be an exact match between AD and OpenLDAP, or that a mapping of usernames or UIDs be maintained.
Ours is a severe access-control and auditing environment... The dual LDAP goal is to enable enterprise AD authentication and pervasive logging for access control, but then maintain application control in OpenLDAP groups that the enterprise admins can't access or edit.
We want to confirm username/password via one LDAP connection to the Enterprise Active Directory, but then allow access to specifically published applications (user based access control in the firewall policies) via a second LDAP connection to OpenLDAP.
This way, we can work with our Enterprise administrators for Single Sign On but maintain application access from our internal, private OpenLDAP.
Answering your question, and just doing a quick read of FSSO, it looks like we'd like to use FSSO for authentication when an Active Directory user first touches the FortiGate. Then OpenLDAP lookup will allow the FSSO-authenticated user to pass through the policies and have access to HTTPS, SSH, and other controlled resources behind the FG.
There may be a non-Forti solution... OpenLDAP can serve as a proxy to other LDAPs, including AD. I'd like to keep the Fortigate in its' role as gatekeeper for all traffic, though, and I don't want to create a maintenance burden of username/UID mapping that an LDAP-LDAP proxy would generate.
- FSSO looks up group membership to LDAP (AD or others) and IP from the workstation of the logon event.
- The FortiGate will receive the login event prepared if matching the defined group filter (exactly with the same notation).
In this flow you may or may not include openLDAP in the group lookup, but in my view it complicated things actually. With openLDAP only it is unlikely you get anything similar to these logon events that the Collector could process.
- the ONLY way to involve OpenLDAP in an FSSO setup as described above is to force the group lookup to OpenLDAP
-> a user would trigger a login in AD, Collector Agent would detect this, and then trigger a lookup to the configured LDAP server
-> the problem is that Collector Agent at least assumes the LDAP server to be an AD server, and there aren't really any options that can be configured aside from base DN:
This means Collector Agent is going to be using AD LDAP syntax (looking for memberOf attribute, instead of member, for example).
If OpenLDAP can handle this, and reply accordingly with group information, then Collector Agent can fetch group information from OpenLDAP while the actual login comes from AD, and forward that (AD user+OpenLDAP group) to FortiGate.
However, FSSO is very deeply integrated with Active Directory (and the corresponding LDAP syntax), so I'm not confident this would work.
On the FortiGate itself, the group lookup is always part of the authentication, and can't be split off into a separate query to a different LDAP server.
+++ Divide by Cucumber Error. Please Reinstall Universe and Reboot +++
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.