Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
slk2k
New Contributor

FortiAuthenticator 6.0 support of nested groups on my Remote LDAP query

Hi Everyone,

 

Windows AD server with nested groups (groups of groups of persons). Trying to get FortiAuthenticator to add users via that group (and ultimately, sync users back too). 

 

i have tried a bunch of things (and even enlisted support's help) and after several hours of work, they seemed frustrated and came back with a "it's not supported".  But, I found recent KB for Fortigate to rework the query to support finding users in nested groups.

 

https://kb.fortinet.com/kb/viewContent.do?externalId=FD41657&sliceId=1

 

I also tracked a MS article speaking to the same:

 

https://docs.microsoft.com/en-us/windows/desktop/adsi/search-filter-syntax

 

So i have tried changing the query to align with that (experimenting with the queries in Authentication->Remote Auth Servers->LDAP, Import users by Group Membership, but not having any success.  It does find any user within a specific group, but not nested groups. Hoping to if someone knows if this is really not supported or if it does work!

 

Thank you!!

Shawn

1 Solution
ergotherego
Contributor II

Nested security group lookups should primary come down to your LDAP query.

 

This is the magic query string you want that will do recursive group lookups:

 

memberOf:1.2.840.113556.1.4.1941:=

 

For example, I created a catch-all group (aka super group) named "MySuperGroup". The members of that group are departmental level groups. E.g, "marketing", "sales", etc. Those dept-level groups then have the user accounts as members.

 

Here is example 'LDAP filter' (adjust based on your OU path obviously). This will catch objects of class "person" and that ultimately are a member of MySuperGroup.

 

(&(objectClass=person)(memberOf:1.2.840.113556.1.4.1941:=CN=MySuperGroup,OU=FortiAuthenticator Group Structure,OU=Groups,OU=Internal,DC=user,DC=domain,DC=com))

 

Note in my case, given that OU path, the 'Base distinguished name' in the Remote User Sync Rules page is below. If you are not getting any user results back, you may need to play with this a bit, but I believe you just need to identify the top-level OU that contains your super-group, user groups, and users themselves.

 

OU=Internal,DC=user,DC=domain,DC=com

 

Lastly, if memory serves, I had trouble ingesting users that crossed the top-level OU boundary. So if a user account lived under OU=External,DC=user,DC=domain,DC=com, I don't believe I was able to catch it. Again, this is from memory but I believe it comes down to that query and how it functions against a LDAP database.

View solution in original post

2 REPLIES 2
ergotherego
Contributor II

Nested security group lookups should primary come down to your LDAP query.

 

This is the magic query string you want that will do recursive group lookups:

 

memberOf:1.2.840.113556.1.4.1941:=

 

For example, I created a catch-all group (aka super group) named "MySuperGroup". The members of that group are departmental level groups. E.g, "marketing", "sales", etc. Those dept-level groups then have the user accounts as members.

 

Here is example 'LDAP filter' (adjust based on your OU path obviously). This will catch objects of class "person" and that ultimately are a member of MySuperGroup.

 

(&(objectClass=person)(memberOf:1.2.840.113556.1.4.1941:=CN=MySuperGroup,OU=FortiAuthenticator Group Structure,OU=Groups,OU=Internal,DC=user,DC=domain,DC=com))

 

Note in my case, given that OU path, the 'Base distinguished name' in the Remote User Sync Rules page is below. If you are not getting any user results back, you may need to play with this a bit, but I believe you just need to identify the top-level OU that contains your super-group, user groups, and users themselves.

 

OU=Internal,DC=user,DC=domain,DC=com

 

Lastly, if memory serves, I had trouble ingesting users that crossed the top-level OU boundary. So if a user account lived under OU=External,DC=user,DC=domain,DC=com, I don't believe I was able to catch it. Again, this is from memory but I believe it comes down to that query and how it functions against a LDAP database.

slk2k

That's it! - Worked like a dream!

 

You solved what 2 Fortinet Tier 1 support Engineers couldn't in many weeks.  I am not upset, it's just outside their area of expertise.

 

Thank you!!

Shawn

Top Kudoed Authors