Feature - Sync LDAP Users to eramba

say i have 8000 people and im doing exception management, how i give each an account without going mad?

  • ldap group sync?
  • quick add button on the “requester” field?


long term queue: https://github.com/eramba/eramba_v2/issues/1958

1 Like

I too would like this but it should come with a new user type to assign only, or be a separate LDAP sync group.

I was thinking on this a little bit today, under sytem / settings / user accounts we’ll define using a drop down:

“Settings” → “Account Sync - LDAP” → {LDAP Sync Name} → {Edit} | {Audit Trails} | {Force Sync} | {Simulate Sync} | {Delete}

The idea is that the admin can define one or more LDAP Syncs, by defining for each one of them:

  • Sync Name
  • Sync Description
  • LDAP Group Connector (from System / Settings / LDAP Connectors) … this connector type group is needed because it pulls the list of groups and the members of each group.
  • LDAP Authenticator (this is used to populate the data for a given user) … this connector is needed because it gives us the details of every user (name, surname, login name, email, etc) which are needed to create an account

At this stage we need to validate these settings are ok:
1/ the user needs to select one group (from the available list of groups for this group connector)
2/ then a second drop down lists all users for that selected group (from the list of users for that selected group)…this comes from the GROUP LDAP Connector.

then we need to “Test” the combination of the selected GROUP and the selected USER… the check we do is: we get all required fields for user creation from the ldap connector: name, surname, login, email.

Important to remember: users in a group can be configured differently by the AD admin … for example they could forget to assign an email to an acccount…so while the test on a single user worked well … for all users might not work well.

  • One or more eramba groups (mandatory)
  • One or more eramba language (mandatory)
  • API enabled or not
  • One or more eramba portals (mandatory)
  • A dropdown with “Delete” or “Disable” , so the admin chooses what action eramba should take for those accounts that exist in eramba and do not exist on the group.

Once the Sync is created (saved) we trigger the “Simulate Sync” functionality which basically creates a modal that lists in a filter:

Create|(Delete|Disable),Name, Surname, Login, Email, Portal, Group, Language, API

the idea is that the user can see what will happen if the sync would run now … what accounts would get created, what would be disabled. This modal can be triggered anytime by using the menu option Simulate Sync.

What eramba will do on every sync? (which we dont know if it will be daily or hourly)

  • get the list of user accounts on the groups configured on each sync configured
  • for each user, pull the user data (using the auth connector) … if all fields are completed…create the account if is not already on the system and all mandaotry fields have been provided by the LDAP sync.

Audit Trails, we need one for each Sync configured, you log the following actions:

  • Sync process started: Sync $name
  • Sync process $name: User account $s found on ldap group $s
  • Sync process $name: User account $s exists in eramba we are not creating it again
  • Sync process $name: User account $s does not exists in eramba - mandatory fields look ok ready to create
  • Sync process $name: User account $s does not exists in eramba - mandatory field missing: $s,$s,$s we are not creating the account
  • Sync process $name: User account $s has been created


  • Sync process $name: Login account: $s found in eramba and not found on group - deleting|disabling
  • Sync process completed, Sync $name

The default user management filter needs to include a “Tab” for LDAP Synchronisation, the following fields should be available:

Tab Name: LDAP Synchronisation
LDAP Synchronisation Name
LDAP Group Connector
LDAP Auth Connector
Ldap Group

Make default on the filter for user management the column “LDAP Synchronisation Name”

Is it possible to get a kind of “client” running on a machine to push LDAP data towards eramba instead of having eramba pulling? Background here is: If we run eramba in a cloud environment which is not connected to our LAN/AD, we would need to open up access to our LDAP. Running a push agent would simplify this a lot and most probably also fix the above issues.

hi ! - is not really the way ldap works … is a bit like sql where the client (eramba) queries the server (ad in your case i guess).

opening ldap to internet is as safe as using https to pay with a credit card, is tls encapsulated so not trusting LDAPS is like not trusting HTTPS (which at this point runs most of what happens on internet and corporate networks)… :slight_smile: … you probably also dont need to open your corporate ldap/ad service to the entire internet, you can probably narrow down with a firewall to the networks were your cloud services are located.

another alternative is to install on your cloud a directory service (and eramba queries that) that federates your corporate service…but essentially you are doing the same as the above scenario as your cloud federated directory still needs to pull that from your corporate directory. both azure and amazon have solutions for this.

all these are infrastructure decisions … but that is just my guess


I’m unsure how this feature is supposed to work. I tried to use it with a group that has over 600 people in it, but instead of creating all the accounts it disabled over 100 existing accounts and created 23 (I only had about 110 to begin with).

The AD group I’m trying to sync is made up of several nested groups (very few direct accounts). Can the sync process see all the sub and sub-sub group members? How do I diagnose what went wrong?

If I’m going to set up several sync jobs pointing to different groups (to provide different types of access in eramba), what if a user appears in more than one of the AD groups? What sync job and resulting settings will be applied? Will one sync job disable an account that doesn’t exist in that group, then another sync job with the user re-enable it?

Appreciate if you can provide more detail on the capabilities and limitations, and how you intended this capability to be used.

there is a sync simulation you can run to see what the system would do, have you tried that? we are working on a few fixes but im not sure they relate to this.

I ran the simulation, and it did what it said it would do, but the result is not correct. I’m not getting most of the group members created in eramba, and some group member’s eramba accounts are being disabled.

I need to understand how it interacts with the AD Group and why it can’t see all the members. I’ll try to do more analysis to see if I can figure out what it is seeing.

[UPDATE]: My testing and results confirm, you are looking at user objects only and not getting the members of group objects. I’m trying to add a group which has many sub-groups. eramba LDAP Sync only sees the users and ignores the groups. Is this something you will look to remedy?

[UPDATE 2]: So testing this LDAP Sync feature disabled most of the accounts I already had created, and now I’m trying to re-enable them. For some reason the option to make the accounts Active is grayed out, forcing me to switch each account to be local, then I can make it Active, then I make turn off the local setting. Is there some other way to make accounts Active without making them local first?


if you want eramba to search nested groups, you have to reconfigure the search pattern of “LDAP Filter: Group Membership” to:


Then you’ll see all members.

We are working on fixes, we will have them ready by tomorrow probably and once they are done we’ll update the documentation.

Thanks for the tip. I’m hoping you can further clarify it.

My current search pattern is: (&(objectCategory=user)(memberOf=%GROUP%))

It looks like you’re suggesting adding a number: 1.2.840.113556.1.4.1941: to memberOf portion. What is the significance of this sequence?


this Sequence tells the Active Directory, that it should respond with all users in the requested group within users of nested groups.

Just try it… it works.



Thanks for the background on the secret sauce! It does work.

I still have issue with how the LDAP sync works in as a mechanism for managing user roles so looking forward to further development of the feature.

Ok … this feature became a real nightmare as we found many many details as we tried to correct the bug, believe it or not we spend 2 weeks working and testing this thing - not common at all that it takes so long to get something right.

Release 2.5.4 will go out tonight, we have updated the LDAP sync documentation already:

We will produce a video too that shows how the system works.

We are sorry for the delay, we just could not get it right … hopefully it will now work correctly.


Thanks for taking the time and working to get it right. When it is ready it will be a very helpful feature.

1 Like

We just updated the documentation (written) an video: