Application Delivery Management
Application Modernization & Connectivity
CyberRes by OpenText
IT Operations Management
The WatchDog driver has been developed as a way to provide very simple eDirectory event monitoring for objects and attributes that are updated by Identity Manager Drivers and Administrators. A filter controls the class of objects and the attributes that are reported on when changes are made. Initially this is limited to standard attributes for Users only. The report provides basic event information for Add, Modify, Rename, Move and Delete events. The report file records the changes made, the time those changes occurred, the event ID and the last Modifier name. This driver does not provide reporting on detailed events with eDirectory, such as login or LDAP lookup events. Such monitoring requires a proper SEIM solution.
The driver framework can be extended to report on additional object classes and attributes by extending the driver Filter. It is recommended that such extensions be added through the use of a custom package that includes the Filter Resource option. Additional policies can be added where required, such as for scoping objects appropriately, using the same custom package methods. All reporting creates an IO load on the server running the driver, so caution must be exercised to avoid performance impacts and excessive disk space utilization. This driver does not manage the report files generated, so that must be managed outside of the driver itself.
Special thanks to, Rainer Oebels, who developed the original WatchDog driver framework. He graciously allowed his framework to be used and enhanced into this solution. This solution has been implemented successfully in multiple environments since then.
This work is not to be construed as a representation by any participating company to develop, deliver, or market a product. This work is provided "AS IS" without any warranty, either expressed or implied, including any implied warranties of merchantability or fitness for a particular purpose. Micro Focus, and their affiliates exclude all liability for damages of any kind (including direct, indirect, incidental, consequential, loss of business profits or data) arising out of or relating to use or inability to use the Work, even if advised of the possibility of such damages. Some states do not allow limiting liability for consequential or incidental damages so this limitation may not fully apply. All Micro Focus marks referenced in this presentation are trademarks or registered trademarks of Micro Focus, respectively, in the United States and other countries. All third-party trademarks are the property of their respective owners.
Some additional notes on using the modifiersName attribute information:
Out of the box WatchDog includes the modifiersName attribute in the User Filter. This allows for reporting that attribute when a user object is modified. That can help identify who, or what, initiated the change event. When themodifiersName has not changed between one event and the next, the driver is not provided that attribute in the event document and has to request it from eDirectory; at the time the event is processed by WatchDog. As there may some latency between received events and when the driver is able to write to the disk, it is possible for the modifiersName to be changed before it is requested from eDirectory. This can result in a misleading indication of who the modifiersName was for a given event. If events are not backed up in cache, this should be a rare occurrence. One has to be aware of this possibility before relying on the accuracy of the report.
When Identity Manager drivers generate events, the modifiersName will usually be the name of the server hosting the driver. If the WatchDog driver is running on a different server than a given driver, the remote server will be identified in the modifiersName. This can also be seen when eDirectory synchronizes updates between servers and the sending server is reported in the modifiersName. When the modifiersName is combined with the event-id information, included in each event, it is possible to get a fair indication of the driver that initiated specific events. Again caution is called out as some drivers react to events using the same event-id when they generate further events.
The combination of event-id and Last Modifier can be best utilized when WatchDog is running on the same server as the driver(s) that are being monitored. Running WatchDog on multiple IDM hosts can be used to track events from drivers running on different servers. Running multiple WatchDog drivers will require the appropriate additional disk space on each server it is running on. All disk space used will need to be managed separately from WatchDog as the reports are not cleaned up automatically.