XDAS Auditing for Successful and Failed Login Events

From eDirectory version 888Patch9 and 902 we can monitor successful and failed login events through XDAS auditing with the help of the latest eDirectory Collector (2011.1r7) and NMAS Collector (2011.1r4). Modify the Directory System to report the LOGIN and AUTHENTICATE events separately. Add two new DS events DSE_LOGIN_EX (mapped to Create Session XDAS event) and DSE_AUTHENTICATE (mapped to Authentication Session XDAS event) which are used for Login and Authentication. These new events are only used by XDAS.

Also XDAS instrumentation provides reasons for login failures like "Login Failed" for the wrong password, “Account Expired” for Account disabled, and “Account Locked” for account locked due to intruder detection.

Steps to monitor successful and failed login events:

  1. Install and configure 888Patch9/902 eDirectory server.

  • Install and configure Sentinel server with the latest eDirectory and NMAS collector.

  • Select XDAS events "Create Session" and "Authentication Session" for monitoring through iManager.

Now setup is ready for monitoring successful and failed login events.

Check the screen shot below of Sentinel view of a login event for both a successful login and a failed login.

Sentinel View of login events.




How To-Best Practice
Comment List
  • So binding as uid=edirt22222,ou=Int,ou=people,dc=example,dc=omm from Apache Studio, we see an error: (From Apache Studio)
    The authentication failed
    Error while opening connection - [LDAP: error code 49 - NDS error: failed authentication (-669)]

    Yet we observe no event in XDAS when the entry binding with is not found.

    Guessing that on a bind, if the entry is NOT found, then there is no call to NMAS which means we do not get to see the bind result FAILURE event.
  • Logging all events with severity as 7 is solved with Collector 2011.1r8 and eDirectory 9.0.3. The events are set with different Severity mapping in the Sentinel based on he event and the outcome.
  • Unfortunately the approach of using XDAS as auditing interface does not work properly at all. Reason of it is based on decision of XDAS developers, who decided that XDAS will always send all events as INFO via log4j. In addition to this XDAS will log all events as Severity 7 (informational) so that there is a need to do the sorting/filtering of the events up to the collector and pay for events/second no one is interested in. I am curious if owner of this idea will pay expenses caused by this stupid decision (I expect monthly payments in reference to number of events/second no one is interested in). The described behavior does not conform to published documentation.