IDM is all event driven. The eDirectory side is no problem; Novell knows how eDir works as it's their product and the ModifyObject event is passed to the IDM driver. Doesn't matter what you do to the object, it will be sent to the driver. Even just running a JRB to essentially modify nothing at all, the event is triggered and the object processed. It will attempt to sync all attributes of that object.
If you were to unload the IDM driver, modify an object (say, change user phone number), flush the IDM event cache and then restart the driver the object would not be processed as it's unaware of the change. However if you then change the user's password, the phone number will sync because all attributes are processed.
On the AD side you've got the Identity Manager plugin (usually hides away in Control Panel), which you will have installed on your DC with the remote loader. That basically catches passwords as they're changed, before they're committed to the directory. In the IDM driver filter the nspmDistributionPassword is set as "notify" in 1 direction and "sync" in the other. I can't remember which way around off the top of my head.
It's probably worth setting up a bi-directional driver from scratch (not starting it) and then comparing the 2 side by side in iManager (or Designer, if that's your thing).
So far as what objects will sync, essentially anything under the Base DN specified in your driver, unless you've done something like exclude the OU class in the filter, in which case subcontainer users would only sync if the OU is actually present in the destination directory.
Been a few months since I've got down and dirty with IDM and I kinda miss it.
