Lotus Software logo
IBM Lotus Domino 8.5 Administrator
  Versions 8.5 and 8.5.1

Securing Internet passwords

Internet passwords can be subject to attacks by malicious sources. For example:

Use one or more of the following features to secure access to Internet passwords stored in the Domino Directory, or make them more difficult to guess.

Using xACLs to secure Internet passwords

One way to secure Internet passwords is to use Extended ACLs, or xACLs, to control access based on levels in the naming hierarchy, and at the form and field level.

For passwords stored in the Domino Directory, administrators can set up xACLs to limit access to Internet passwords to the users themselves, for accessing their own passwords, and adminstrators, for allowing administrative changes to passwords.

First, enable extended access for the Domino Directory:

  1. Open the database, and choose File - Application - Access Control.
  2. Make sure you have Manager access in the database ACL.
  3. Click Advanced, and then select "Enable Extended Access."
  4. At this prompt, click Yes to continue:
  5. "Enabling extended access control enforces additional security checking. See Domino Administrator Help for more details. Do you want to continue?"

  6. At this prompt, which appears only if the advanced database ACL option "Enforce a consistent Access Control List across all replicas" is not yet enabled, click Yes:
  7. "Consistent access control must be enabled first. Do you want to enable it now?"

  8. At this prompt, click OK:
  9. "If more than one administrator manages extended access control for this database, enable document locking on the database to avoid conflicts."

  10. Click OK in the Access Control List dialog box.
  11. At this prompt, click OK:
  12. "Enabling extended access control restrictions. This may take a while."

Next, set up the extended access to secure Internet passwords.

  1. Open the database, and choose File - Application - Access Control.
  2. Click Extended Access. The Extended Access dialog box appears.
  3. In the Target pane, select the root [ /] and click Add.
  4. In the Access List pane, select Default.
  5. Click Form and Field Access. The Form and Field dialog box appears.
  6. In the Forms list box, select Person. Leave the Access settings for Forms blank.
  7. In the Fields list box:
    1. select HttpPassword and set the Read and Write access settings to Deny.
    2. if it appears, select dspHttpPassword and set the Read and Write access settings to Deny.
  8. Click Ok.
  9. Repeat this process for the HttpPassword and dspHttpPassword (if it appears) settings in the Person form for the following Access List entries:
  10. Access List entry

    Read access setting

    Write access setting




    [Local administrators group]



    [Local servers group]



Note If Anonymous access was previously defined in the access list, it should be set up to deny read and write access to HTTPPassword and dspHTTPPassword (if it appears) fields in the Person form.

Note Once xACLs are enabled for a Domino Directory, LDAP anonymous access is not controlled by the list of fields in the All Server Configuration document. Since the default xACL setting for Anonymous is "No Access," once xACLs are enabled all anonymous LDAP searches will fail.

Using more secure password format

When you enter an Internet password and save the Person document, Domino automatically one-way hashes the Internet password field. To improve the default password, use the more secure password format.

You can upgrade the password format for Person documents that already exist or automatically use the more secure password format for all Person documents that you create.

For existing Person documents

  1. From the Domino Administrator, click People & Groups, and select the Person documents that you want to upgrade to a more secure password format.
  2. Choose Actions - Upgrade Internet Password Format.
  3. If all servers in the Domino domain run release 8.0.1 or above, select "Yes - Password verification compatible with release 8.0.1 and above." Otherwise select "Yes - Password verification compatible with release 4.6 and above."

For new Person documents

  1. From the Domino Administrator, click Configuration, and select All Server Documents.
  2. Choose Actions - Edit Directory Profile.
  3. If all servers in the Domino domain run release 8.0.1 or above, select "Yes - Password verification compatible with release 8.0.1 and above." Otherwise select "Yes - Password verification compatible with release 4.6 and above."
  4. Save and close the document.

Note The more secure password format is required if you choose to synchronize a user's Internet password with their Notes password.

Another way of preventing malicious sources from guessing passwords is to simply make them harder to guess - by making the passwords longer and more complex, using a variety of characters, avoiding the use of real words, and so on.

Using Internet password lockout

Internet password lockout lets administrators set a threshold value for Internet password authentication failures for Domino Web and Domino Web Access users. This helps to prevent brute force and dictionary attacks on user Internet accounts by locking out any user who fails to log in within a preset number of attempts. Information about authentication failures and lockouts are maintained in the Internet Lockout application, where the administrator can respectively clear failures and unlock user accounts.

It should be noted that this feature is subject to Denial of Service (DoS) attacks. A DoS attack is one in which malicious users explicitly prevent legitimate users of a service from using that service. In the case of Internet password lockout, legitimate Internet users could be prevented from logging in to a Domino server by attackers who intentionally make failed log in attempts.

Note Internet password lockout has no affect on Domino Off-Line Services (DOLS).

There are some usage restrictions for Internet password lockout:

For single sign-on, the Domino server on which the Internet password lockout feature is enabled must also be the server that issues the single sign-on key. If this key is retrieved from another source (another Domino server or WebSphere server), the SSO token will always be valid on the Domino server, regardless if Internet password locking is enabled.

The Internet Lockout database

The Internet Lockout database (inetlockout.nsf) is created from inetlockout.ntf:

By default, the Internet Lockout database ACL allows manager access only to the Admin Group. Default and anonymous are denied access. However, the database ACL can be modified to provide users and groups access to view and unlock users.

For each user attempting to log in to Domino using an Internet name and password, information about the lockout state is maintained in the Internet Lockout database, including the user name, number of failed attempts, and lockout status. Lockout attempts are not recorded in the lockout database if the user is already locked out, or if the user logs in successfully. However, while the Internet Lockout database maintains lockout state information, the Domino Domain Manager (DDM) is the location in which login failures and lockout history information should be maintained, providing you with historical records of login failure attempts.

Any changes to the access information for users stored in the Internet Lockout database are implemented immediately. You do not need to restart the HTTP server in order for changes to take effect.

There are two views in the Lockout database:

The fields are the same for both views:

You delete a record to unlock a user.

You can mark multiple records for unlocking or deletion by clicking 'Mark for Delete/Unlock' in the tool bar, and then delete them by clicking 'Delete Marked Items.''

It is recommended that you periodically verify that that the Internet Lockout database contains only records of valid users. Remove the names of those users who have had name changes, or who have been removed as users of the Domino server. There is no automatic cleanup of the database; while having outdated user records will not cause functional problems, too many records in the database could cause Internet authentication performance to slow down.

You can create custom login-forms for the Internet Lockout database that can be used to tell users that they may be locked out.

Replicating the Internet Lockout database

As an administrator, you need to decide whether replicating the Internet Lockout database to other servers is useful for you. A major advantage of replicating the database is that lockout information is replicated to multiple servers. You can look at any replica and determine the lockout status of users across multiple servers, instead of having to open up the Internet Lockout database on each server for which Internet password locking is enabled.

However, replication also has its disadvantages; for example, replication storms can occur if your network is under attack, or if a denial-of-service attack occurs. Additionally, if replication is slow to occur, anyone checking the lockout database on a given server might not be able to see that a person is locked until replication occurs (however, they can always open the replica directly on the server in question).

The Internet Lockout database is created with a replica ID that stays the same for any replica on any server for which Internet password locking is enabled in a domain. By default, replication is temporarily disabled for Internet lockout databases. This is to prevent replication storms described earlier. To replicate the database to another server, disable the Temporarily disable replication option in the Other section of the Replication Settings dialog box. You can then set up the database to replicate (either scheduled or clustered replication).

Note When you replicate this database to other servers, the 'invalid attempts' information is calculated for each individual server. For example, if the threshold for 'John Doe' is three, and he has two invalid attempts on Server A and has one on Server B, he is not locked out of either server. The attempts are not combined for a total of three. The reason for replication is ease of administration, not to establish global thresholds.

Configuring Internet password lockout

You enable Internet password lockout in the server configuration settings document. This allows administrators to turn on the Internet Lockout feature across multiple servers.

Note It is recommended that the Server document option 'Fewer name variations with higher security' is enabled. This minimizes the problem of ambiguous names. Domino supports logging in to the Web server with a short form of the user name (if the password is correct), even though the short name may match two or more people in the directory. Incorrect logins that occur when a user types in an ambiguous name will result in a failure for each ambiguous match, because there is no way to tell which user was trying to log in. Furthermore, failure attempts being cleared using the 'lockout expiration' settings occur only for the user whose username and password successfully match.

To enable and configure Internet password lockout
  1. In the Domino Administrator, click Configuration - Server - Configurations. Open the configuration settings document for the server for which you want to enable Internet password lockout.
  2. Click Security. You have three options for the setting Enforce Internet Password Lockout:
  3. Note If Internet password lockout is not enforced in the Server document, any other Internet lockout settings, such as those in a policy document, are disabled.

    If enabled, the following settings appear:



    Log Settings

    You can choose the type of events that you want to log on the console and in DDM. User name and IP address are also logged.

    • If 'Lockouts' is enabled, both the events in which a user has been locked out and events in which a user tries to authenticate but is already locked out are logged. This is enabled by default.
    • If 'Failures' is enabled, any failed authentication attempt is logged. The IP address and user name of the client trying to authenticate are also included in the log.

    Default Maximum Tries Allowed

    Specify the maximum number of bad password attempts allowed before the user is locked out. The default is 5. Once the user is locked, the user must be unlocked before any new values for this setting are in effect for that user.

    If a user has a different value for the setting in their user policy, it overrides the one set in the server configuration document.

    Note If this value is 0, unlimited password attempts are allowed.

    Default Lockout Expiration

    Specify the period of time for which a lockout is enforced. After the specified time period expires, the user account is automatically unlocked when the user next tries to authenticate. In addition, all failure attempts are cleared.

    Note If this value is 0, the lockout will not expire automatically. The account must be unlocked manually.

    Default Maximum Tries Interval

    Specify the length of time failed password attempts are retained in the lockout database before they can be cleared by a successful authentication. The default value is 24 hours.

    This does not apply to users who are locked out. If a user is locked out, the only thing that can clear failure attempts and unlock the account is to do so manually, in the Internet Lockout database, or when Lockout Expiration occurs.

    Note If this value is 0, every successful login, for a given user who is not locked out, clears all failed password attempts by that user.

Policy settings for Internet password lockout

With the exception of the log settings, the options described previously can also be specified in a user policy. This might be useful if an administrator only wants to enforce Internet password lockout for a subset of users in an organization. In this case, these settings can be established for that group.

Related topics
Custom Web server messages
Creating a security policy settings document
Managing Internet passwords

Library | Support | Terms of use |

Last updated: Monday, October 5, 2009