Configure Event Agent for AD LDS Repository

[Former Member]

Hi everyone!

I am trying to configure a event agent for an AD LDS (Active Directory Lightweight Directory Services) Repository. Unfortunately the event agent launches the specified job every time (all 30 seconds, where 30 seconds is the polling intervall).

Here is my configuration:

Any hints why this could happen? How do the different event agents work exactly, when do they trigger?

Thanks for you help,

Raphael

[Former Member]

Objectclass * is a problem.  AD is constantly changing.  If a computer gets added, this will trigger your job.  If a group policy gets updated...

Try limiting the objectclass to only those you need (groups & users).  Be aware that computers (and contacts) also have an objectclass of 'user' so they will be monitored as well.  I'm not sure if you can change it to ObjectCategory=Person which would exclude them - depends on the event agent.

Peter

[Former Member]

Hi Raphael,

The event agents are used to monitor the selected repository for the specific changes.

In your case, you have configured agent named "ADLDS_EventAgent". so, as per the configuration you have made under the Agent parameters, this event agent monitors the domain DC=AD-LDS,DC=tst for the operations ADD,MODIFY & DELETE.

So, as configured, for every 30 seconds, the agent polls the target repository to be watched for the 3 operation configured.

To understand exactly how it works, you should also know how the changes to user accounts on AD are logged/stored.

"When a domain controller modifies an object it sets that object's uSNChanged attribute to a value that is larger than the previous value of the uSNChanged attribute for that object, and larger than the current value of the uSNChanged attribute for all other objects held on that domain controller. As a consequence, an application can find the most recently changed object on a domain controller by finding the object with the largest uSNChanged value. The second most recently changed object on a domain controller will have the second largest uSNChanged value, and so on."

For more information on uSNChanged attribute refer Polling for Changes Using USNChanged (Windows)

So, the event agent reads the changes to the user account based on the uSNchanged attribute. And since any operation on Active directory will be one of the operations i.e Add/modify/delete which matches with the configuration criteria, the event agent triggers the job that is configured under the field "Execute job". Usually it will be a notification job.

Hope this helps.

Thanks,

Krishna.

[Former Member]

The dummy job probably doesn't write the highest processed changenumber(s) on the ADS repository variables when its done processing the changes? Unless that is done the event agent will continue to look for uSNChanged > 0 forever which means it will always find changes that needs to be processed.

But why use the eventagent at all? It's barely any more efficient than running the job that reads the changes every 30 seconds anyway. There's a reason why there's so little info on the eventagents, and that is that they never turned out to be very useful or efficient compared to a good "read and process changed entries" job.

Br,

Per Christian

[Former Member]

Hi Per!

I intend to check my repositories for changes that were not made out of IdM (reconciliation). For example group assignments in a LDAP directory. In a large environment you can not load the whole repository every 30 seconds to check for changes...

Attributes for wich a repository is a source will be loaded/updated through a normal job.

How do you cope with this problem?

Thx,

Raphael

[Former Member]

Hi Raphael,

My experiences with this kind of detail in ADS is unfortunately a few years out of date, but:

The uSNChanged in ADS will only tell you the entry has been updated, not what was updated or by whom. So you basicly have to read the (partial) entry and then compare it to your IdM data to see if the change contained altered data which is "owned" by IdM or not.

The event log can contain this kind of audits if auditing options are enabled, but its not available through LDAP (afaik). You should find something about this if you search for Active Directory Auditing.

There is (or was) a DIRSYNC option in ADS LDAP that might be used for something like this. It would require a bit of work to be useful though, something for connector developers (SAP, 3rd party or consultants on-site) to look into.

Another alternative would be for SAP (or 3rd party) to create plugins that are installed on the domain controllers that report the changes to IdM, somewhat like the password hook. Seems to be a pretty big effort, not to mention verifying that it doesnt interfere with other ADS auditing products commonly used in the enterprises which uses the same plugin.

Best regards,

Per Christian