The LDAP change reporting respective synchronization is probably one of the most interesting modules within the whole application. But what does it actually do?

During the initial setup / configuration of the application you are asked to define an Active Directory domain and distinguished name / path that you want to have synchronized. This path will be monitoring on an defined interval by the roaming/floating code execution. The interval can be changed in the Sys Config.

Synchronized and monitored are:

  • all users underneath the defined DN
    • if a user is added to a group outside of the DN tree, you still will see this
    • unless the group is a foreign group from a trusted domain – this would be only visibly from this foreign domain
  • all groups underneath the defined DN
    • in case a member from another tree branch / DN is joined to the group, you still will see this
    • if you join a foreign member, you will see at a bare minimum the SID of this user
  • all computers underneath the defined DN
    • as for LDAP – computers are any workstations or servers that are joined to the domain
  • for all three types, any group-membership relation are reported as well
  • a synchronization can take several seconds to several minutes all depending on the amount of objects in the defined OU path in your Active Directory – a dialog box will show up at the application that is executing the synchronization and vanish once it finished – since this will roam around, you might or might not see it
    • a manually forced synchronization can be started in the module LDAP sync log at any point in time

In general, not all Active Directory properties are synchronized. Only the most important and usual once are currently in the synchronization. This can be easily changed while adjusting the table columns and the code, but please be aware – some attributes in Active Directory are simple strings and integer values, others are whole collections / lists – you might need to pay close attention or do some research. In general, you will find examples for most cases already in the code module mdlLDAP. Some developer experience is recommended.

How it works:

  • per default the interval is 30 minutes
  • the system synchronizes all objects and documents anything that has been changed
    • note that changes that have been made and undone within the interval might not be recognized
  • changes are reported to a LDAP sync. log table that you can filter by date/time, user, group and computer as well as the logtext
    • the log text entry actually shows what value changed including the old and new value
  • an email will be send out every 24 hours around 7 AM per default that shows you a grouped summary of what changed as well

Note: the first synchronization will show you a lot and create a lot of entries in the logfile. This is simply due to the fact that system has to start somehow. Once the initial synchronization is done, it will calm down and only detect further changes. Please also expect the first email after the first day to be rather long due to this fact. 

Per default there is no access to the tables for all those groups, computer and relationship entries. Those tables still work with the same triggers in SQL as the rest of the database and have _history tables attached, but per default there is no view on those tables – the LDAP sync. log should be sufficient enough, the rest is actually just your Active Directory.

Having this said, the users are actually in the employees module – please see the next chapter for more details on this.

Please note – the system tries to identify where the change happened. Especially for groups – if there is a log entry that a user was added to a group this might be attached to the user only rather then reported on the group – some code changes could advance this, but as of now this is not the case. This was kept like this to avoid double entries in the logfile as well as in the report emails, that would actually cause more confusion then doing good.

It is further not possible to determine who made the change. There is ready software out there that can do stuff like this, but you will pay a good price for it in most cases. The reason why this application is not doing this is simply due to the fact that you would need access to the domain controllers, actually all of them and their security eventlogs assuming you have them configured good and deep enough to find out who originally made the change. This could mean you constantly need to investigate and read possibly all domain controllers you might have in place world wide. It is simply out of the scope of this application and would not be possible with a regular user account.

Speaking about a regular user – there is NO domain administrative right needed to execute the LDAP synchronization. This can be done with any member user of your Active Directory.