ED Statistics Logging

Author	David Hawes
Date	2005/05/13

(draft)

The Virginia Tech Authentication System, known as ED-Auth, currently has no means to expose statistics and information about authentication attempts. Useful information includes such things as last successful login, last login failure, number of failures, host authenticated from, etc. Most modern authentication systems have the ability to present this information in some form, and some systems are capable of taking actions on this information, such as account locking on consecutive password failure attempts.

As ED-Auth is an OpenLDAP instance and is thus simply an LDAPv3 server, it does not inherently take care of the things typical authentication systems would take care of, as listed above. This document outlines the problems with ED-Auth presenting information and statistics about operations performed against it and various ways these problems can be solved.

Since OpenLDAP is intended to be used as an LDAPv3 server, it does not by default support the types of things typical authentication systems would support. A now expired Internet-Draft, draft-behera-ldap-password-policy-xx.txt, included in the OpenLDAP distribution, has been implemented as an overlay for OpenLDAP called ppolicy. The ppolicy overlay transforms an OpenLDAP instance into an authentication server, supporting such things as password locking. Though untested by Middleware, the ppolicy overlay cannot be used for ED-Auth for one major reason: the load balanced nature of ED-Auth.

The ppolicy overlay is a per-instance overlay that works only on a single OpenLDAP server. If our environment consisted of a single server, and that server was the authoritative repository for that data, the ppolicy overlay would probably give us quite a bit of functionality with ED-Auth that would be desirable. Unfortunately, neither of these are true. ED-Auth is comprised of multiple servers (4) in a clustered, load-balanced environment and data in ED-Auth is merely an end-user reflection of data owned by the VT Registry. In other words, there is no means for the ppolicy to share data between the multiple OpenLDAP instances that comprise ED-Auth, and there is no way to push this data back to the Registry, which should (by definition) be the source of all data in the ED-*s.

So, a means to present authentication information and statistics about ED-Auth should include at least the following:

• The ability to collect authentication information from each ED-Auth and reflect that information in the other ED-Auth instances
• The ability to persist authentication information in the Registry.

In the previous section it was stated that we need at least two things to take place in order to present authentication information reliably. In reality, if we persist this information in the Registry, we take care of reflecting the information in all ED-Auth instances since the typical replication paths will push the necessary data to all instances. It should be noted that pushing data back to ED-Auth instances is only needed if we want to display the data in ED-Auth or want to take some action on this data at the time of authentication. For the time being, we may simply want to show statistics in a tool such as the DAT, so pushing these stats back is not really necessary.

There are two things we need in order to store data in the Registry:

• A means for ED-Auth to know when authentication attempts are taking place (Authentication Awareness)
• A mechanism for updating the Registry

Any of the the solutions will need tablespace in the Registry for storing authentication information. The schema for new tables doesn't need to be included in this document, but the table could contain such columns as the following:

• last_successful_auth (the date and time of the last successful authentication attempt)
• last_failed_auth (the date and time of the last unsuccessful authentication attempt)
• successful_auth_count (the total number of sucessful authentication attempts)
• failed_auth_count (the total number of failed authentication attempts)
• auth_count (the total number of auths, failed and successful)
• failed_auth_attempts (number of failed authentication attempts since last successful auth)
• last_auth_from (hostname or IP where last authentication attempt came from)

There are several ways we can push authentication data to the Registry:

---

Such a mechanism would use direct SQL to add, modify, and delete entries in the Registry.

Pros:

• Simplicity

Cons:

• Runs counter to our 3-tier environment (we are trying to get away from doing Registry direct operations, Entity Beans should be used for this).

---

Such a mechanism would use a Session Bean that would handle the logic for adding, modifying, and deleting entries in the Registry using Entity Beans.

Pros:

• Business logic for setting authentication information can be handled here
• Complies with our 3-tier environment
• Whatever pushes data to the Registry can be completely dumb (not worry about last attempts, etc.)
• Ability to use future partial record replication at the Registry

Cons:

• Almost certainly forces us to use a Java client, requiring a JDK on the ED-* machines

---

Such a mechanism would use Web Services to add, modify, and delete entries in the Registry. This solution would most likely be built on top of a Session Bean.

Pros:

• Clients other than Java can use it
• Can use client certificate authentication over https

Cons:

• What languages can we use to interface with a web service?

Some of the ways we can determine when an authentication has taken place:

---

Some daemon or program would be running to read the OpenLDAP logs and cull out authentication information.

Pros:

• OpenLDAP does not have to be altered in any way.
• A unified logging machine will only require us to have one client updating the Registry for all the ED-Auth instances.

Cons:

• It's log watching–gross!
• Logs could change format.

---

An Overlay (kind of an OpenLDAP module) would intercept requests going back to a client and determine what just took place.

Pros:

• We know exactly what is taking place at the LDAP level.

Cons:

• OpenLDAP is running custom code (alleviated with testing)
• Must either call the Registry updater directly or send to a proxy to update the Registry. (more complexity)

---

A SLAPI Plugin would intercept requests going back to a client and determine what just took place.

Pros:

• Same as the overlay.

Cons:

• Not as mature as the overlay.

Since we need to update the Registry in some way and already extensively use Session Beans with great success, a Session Bean is the best choice for updating the Registry with authentication information. By using a Session Bean, we gain the advantage of placing all the business logic we need for updating the Registry in the bean, plus the ability to optionally use a Web Service interface built on top of the bean. This solution for updating the Registry most closely conforms to Middleware practices and the infrastructure we already have in place.

Authentication awareness is the real problem with logging authentication information, as the solution must be lightweight and unobtrusive so it does not degrade performance of ED-Auth. If this is the sole concern, a log watcher is the least obtrusive option available, and will not degrade performance at all. On the other hand, an overlay solution most likely provides more reliability, as an action is guaranteed to be seen by the overlay (the log watcher relies on syslog, which can glitch), but there is almost certainly a performance hit (testing will be necessary to see if this performance hit is negligible or not).