Figure 1: Enable lockouts -- The Configuration document holds the key to enabling Internet Password lockouts.



Figure 2: Lockout reporting -- INetLockout.nsf holds the record of invalid attempts and lockouts.

Three strikes

Domino has a well-deserved reputation as a secure platform. In that context, it's surprising that Domino has been missing the ability to offer features such as Internet ID locking after some number of unsuccessful login attempts. For some of us, the issue was so serious that we had to resort to writing our own solutions (click to see my article "Track Invalid Web-based Login Attempts"). Fortunately, in the beta 2 release, Notes 8 includes the new "Enforce Internet Password Lockout" feature. I can finally retire my convoluted workaround!

Enabling the function is easy. From the Domino Administrator, navigate to the Configuration Tab and expand the Server and Configurations nodes. My server is called ohcmhsrv009, and there was already a configuration present for it. If the server on which you want to enforce lockouts isn't listed, just create a configuration document.

After you're in the configuration document, go to the Security tab. You should see a screen that looks like figure 1. The kinds of features you need to adequately secure your Web logins are there. You can control what you log: failures or attempts and failures. You can control the maximum number of attempts before the system locks the ID. You can set the field to configure how long the lock will hold (i.e., how long before the lock expires) in minutes, hours, or days -- the default is 0, which presumably is never -- an admin would have to unlock it. Finally, you can configure the interval for counting strikes. The default is one day, so the user can try to log in three times in one day before getting locked out.

After you've configured it, the server logs invalid attempts in the Domino console and in a new NSF called INetLockout.nsf. The Domino server creates this database in the data directory's root after you configure the system to log invalid attempts. That database has decent tracking features, and you can perform basic audits based on its functionality. Figure 2 shows an example of what three strikes looks like. Its two views let you quickly and easily see invalid login attempts and lockouts.

This is a beta release, and I expected some unusual behaviors. For example, in its current incarnation, Domino's lockout feature only logs invalid attempts and it only locks out IDs that use the full name to log in. For example, if I use Terry Crow to try to log into Names.nsf three times, the system locks my ID. However, if I use tcrow, I can try to log in forever. Domino logs the attempt on the console, but never in INetLogout.nsf. I've reported the issue to IBM Lotus on its beta Web site.

Another unusual behavior is that to unlock the ID, you have to delete the document in INetLockout.nsf. That means you lose your audit trail! IBM Lotus responded to my beta forum question about this issue in a way that suggests it was interested in finding a solution, and even offered a workaround: Change the INetLockout template so documents don't really get deleted; just move the document to an audit view. The key seems to be that if a document's on the "Locked Out Users" view, Domino considers the ID locked (based on the parameters you set in the Server Configuration document).