Ldap Unix Import Users with "Remote User Sync Rules"

[AliE]

Hi all,

In FortiAuthenticator, we managed to import our windows Active Directory with the "Remote User Sync Rules". However, we want to import users in our UNIX LDAP (OpenLdap). Users for this LDAP are used to connect in FAC GUI.

Firstly, we have connected our LDAP with FAC and we could see all of the members.

We can import users manually with "Import Users" in 'Remote User'.

When we choose a group, all of the users in the groups will be added. In addition, we changed "member" by "memberUid".

But with "Sync Rules", we couldn't import users in our LDAP. However, we could see all of our users in the filter.

When we did a manual sync, none of our user will be added in "Remote User".

Here, the rules retrieved 2 users because we have added this 2 users manually. But others users in the LDAP have not added. 

How the users can't be added?

[pminarik]

If you can capture the LDAP communication and read it (e.g. plaintext TCP/389), I would suggest making a packet capture of it. Then you can check what the FortiAuthenticator is requesting and how it is filtering. Maybe you'll find some issue in there.

If that's not possible or you're lost even afterwards:
1, Enable debugging of the sync rule:

FAC RUSR debug - enable

2, Manually trigger sync:

FAC RUSR manual sync

3, Once finished, download the LDAP sync log:

FAC logs - download LDAP sync log

4, Provide the log to the TAC for analysis. (it is encrypted, so you cannot inspect it yourself)

I would suggest attaching any other info to the ticket as well. (e.g. the pcap you've made, an LDIFF dump of an example user and their group (so that TAC knows what attributes are available), ...)

[xsilver_FTNT]

Hi,
hard to guess without seeing actual OpenLDAP objects.
Plus your fist screenshot shows 4 records but by "ou=" I just guess that those might not be actually group (objectClass=posixGroup), or user (objectClass=posixAccount), types of objects but OU (Organizational Units).
Which by plus sign alongside of them might/might-not contain some actual users.

However my suggestion is to pay attention to how OpenLDAP object properties looks like and what is FortiAuthenticator config counterpart.
Namely those:

Remote Auth.Servers / LDAP - which is definition of your OpenLDAP used later in Sync
- to "User object class:" .. does default "person" fit to your OpenLDAP and isn't there objectClass in users as posixAccount ?
- similarly to what is "Group object class:" .. is posixGroup matching your OpenLDAP group definitions?
- next and important one, where to "Obtain group memberships from:" .. from under user definition so as on AD each user has its own MemberOf list, or from group definition where is a list of members inside a group. And finally, does that attribute like "member" or "memberUid" actually exist on OpenLDAP?
Because I can create child object as posixAccount under the posixGroup which can have no member nor memberUid ! But my phpLDAPadmin let's me create accounts and ssign them to group which then springs memberUid as property of that group. And that memberUid then contains UserName-s of actual users/members.

User Management / Remote User Sync Rules

- obviously check BaseDN but yours looks like pointing to root of LDAP tree
- LDAP filter .. seems to point to OU=DT probably due to some objects with gidNumber=2205 on your second screenshot. That one also suggest that filter matches just two users! Not many. If you do expect other users being there, then do they have gidNumber=2205 ?
Probably not. But your filter requires both .. objectClass-posixAccount AND gidNumber=2205.

Not sure how yours but my users do have single gidNumber as their primary group, while being members of multiple groups, and those groups do have their own gidNumber-s, but list of members is in my openLDAP under group as list of memberUid values.

One another caveat of Remote User Sync Rules (RUSR) .. you might have everything OK, but some users were already synced and are already in "User Management / Remote Users" and so they will be updated by RUSR if needed, but if they are the same then they are not going to be re-synced and shown in log. So only differences are synced and logged!

As sync went OK according to your log, then that might be your case.