Multiple LDAP servers, one for Authentication and one for Authorization?

[jtnfoley]

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.

Is anyone running a configuration like this?

[Anthony_E]

Hello jtnfoley,

Thank you for using the Community Forum.

I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.

Regards,

[Anthony_E]

Hello jtnfoley,

I am still looking for somebody who could use the same configuration that you are using.

I will let you know ASAP if I find somebody to answer.

Regards,

[Markus_M]

Hi jtnfoley,

I am not running such environment, but maybe can still help. What is your target, I didn't follow this.

You want to authenticate users, but how exactly, captive portal for end users, admin authentication, FSSO (that will be difficult/impossible with openLDAP).

Best regards,

Markus

[jtnfoley]

Hey! Thanks for taking the time!

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.

[Markus_M]

If you do have Active Diretory, FSSO is a good choice.

The flow of this is:

- user auth to domain joined end device

- end device gets profile from DC and creates a logon event on the DC.

- FSSO component (usually a collector agent) gets that logon event (it reads only certain IDs: https://community.fortinet.com/t5/FortiAuthenticator/Technical-Tip-Windows-event-IDs-used-by-FSSO-in... )

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

Best regards,

Markus

[jtnfoley]

Thanks again.

I'll have a 101F and some fortilink'd switches to play with online tomorrow to continue experimenting.

[Debbie_FTNT]

Hey jtnfoley,

to elaborate on the above statement from Markus:

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