Skip to main content
slk2k
slk2k
New Member
March 28, 2019
Solved

FortiAuthenticator 6.0 support of nested groups on my Remote LDAP query

  • March 28, 2019
  • 1 reply
  • 7304 views

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

    Best answer by ergotherego

    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.

    1 reply

    ergotherego
    ergotheregoAnswer
    New Member
    April 22, 2019

    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
    slk2kAuthor
    New Member
    April 24, 2019

    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

    Terms & ConditionsAccessibility statement