View member feedback to this tip.

When I perform Notes/Domino security assessments, one of my standard audit items is the "check password" feature. This option is found in the Domino public directory (names.nsf) at Server/Servers/Security/Check Passwords on Notes IDs. I commonly refer to this option as "server-side password checking" since Notes passwords are always checked at the workstation.

In my experience, most Notes/Domino administrators do not have this option enabled. I believe this is unfortunate and that the feature should be used more often. It offers significant benefits with little drawback. Server-side password checking tells Domino to double check that the password the user typed (to unlock the Notes ID file) is the same password that the server thinks the user has. In other words, the password is checked twice -– first to make sure it unlocks the ID file at the workstation, and then against the server's record of the user's password.

"How can this help?," you might ask. If a password unlocks an ID file, the password must be OK, right? Not necessarily. Suppose someone steals a copy of your Notes ID and figures out your password. You suspect that your ID has been stolen, so you change its password. Each time you log on, you must enter the new password. But what about the stolen ID file? It still has the old password and will work fully with the old password. Your attempt to change your password only worked for your exact copy of your ID file, not for any other copies. Server-side password checking solves this problem.

When this option is turned on, the server rechecks the password you enter. The server also receives updates to the password whenever you change it. So in the above scenario, the stolen ID file will be disabled, because Domino will discover the ID's user is typing an old password.

This feature also has the added ability that you can turn it on gradually and for small batches of users at a time. After the server-wide setting is enabled, as described above, each Person document in the Domino Directory must also enable password checking on a per-user basis. To see these fields in a Person document, use the Domino Administrator client to open a person record in edit mode, then go to the Administration tab. Notice that the default value for each person is "don't check password." To enable server-side password checking, select one or more people at the view level, then use the pull-down action Set Password Fields. (Do not modify the fields directly in a Person record.)

A few final notes:

  • When you use Set Password Fields, you also can enable password expiration at the same time. Password expiration is a valuable security mechanism, but you do not have to turn it on in order to use password checking.

  • When you use Set Password Fields, you also have the option to lock out the selected IDs. This is a helpful mechanism when users leave your organization. You can maintain their account information in the Domino Directory and leave their mail file in place for future reference, but lock out their ID from logging on.

  • For R6, you can configure server-side password checking as part of a Security Policy document. For more information, see R6 Admin Help/Index/Security Policy Settings.
The only drawback I am aware of with server-side password checking is that the server's record of a password can get out of sync with reality. When you first enable the option, the server must update itself with information about each password, and must do so whenever a password changes. If this process goes wrong (which is uncommon) the server can lock out a valid user. This is easy to fix, however, by just disabling server-side password checking for the affected user only, allowing them to log on. You can then re-enable password checking, and the server will sync up again.


Chuck Connell is president of CHC-3 Consulting, which helps organizations with all aspects of Domino and Notes. CHC-3 allows companies to outsource their Domino administration needs via DominoAdministration.com and runs the popular security site DominoSecurity.org.


MEMBER FEEDBACK TO THIS TIP

The major drawback that I see, which Chuck did not mention, is related to admin copies of ID files. The copies our administrators (and high-level help desk staff) have on a secure network drive will not have the same password as the Domino Directory. Those copies would then become unusable. This eliminates a lot of administrative help we can provide to our remote clients. For this reason, our office has chosen not to implement this feature.

-- Kimberly S.

CHUCK'S RESPONSE:

Ah! You are right that server-side password checking invalidates other copies of the ID file. But this is a good thing! In my opinion, you should not keep copies of ID files with passwords known to admin/help people. Doing so allows anyone in the admin/help group to log on as any user. You should set up Password Recovery, which is much safer. See Domino Admin Help for full information.

***************************************************************

I thought this was a very good article. The only comment I have is that if you can turn it off for an individual user at the workstation, then why couldn't a stolen ID be used, even if the password was changed, since they could turn the option off, thus defeating the purpose of having server-side password checking. Or is there a way to turn it on at the server, and require it for all users, no matter what their local workstation option is selected? Thanks.

-- Kevin

CHUCK'S RESPONSE:

Hi Kevin,

Thanks for writing. The check-password option is turned on/off by an administrator in the Domino Admin program, not by a user at their workstation. Sorry I did not make this clear.

***************************************************************

Great tip. I'm all for enabling the security features of Domino.

However, the main drawback seemed like an excessive process to me. Why not simply clear the password field in the address book (only visible when doc is in edit mode), ensure the change has replicated to the server the users authenticate with (typically the home/mail server or a directory server) and get the user to authenticate? The password on the server is then updated with the latest password in the ID file and thus locking out any invalid IDs.

This also helps with ID files that are stored by administrators. In that the administrator can clear the password digest before using the ID file with the old known password. The server will ensure that the password is changed if it has passed the expiry period. This lets administrators quickly reissue an ID file if a user has forgotten the password or lost the ID file. Although password recovery should really be used for this!

-- Mike O.

***************************************************************

From my reading of the technical details of the "check password" feature, it isn't actually server-side checking. The server sends the password digest to the client when it tries to authenticate, and the client checks that digest against the current and past digests stored in the ID file.

This does increase security, but it relies on an uncompromised client, so it is inaccurate to call it server-side password checking. The server doesn't do any comparison.

-- Mike D.

***************************************************************

Thanks for the great article!

One of the snags in implementing this for us has been that server-side password checking doesn't seem to play nicely with DOLS. It seems that when password checking is enabled, and the Internet password and the ID password are not the same, DOLS refuses to synchronize properly. Our only recourse has been to ensure users synchronize their Web and ID passwords. Any thoughts?

-- Jeff D.

***************************************************************

Without enabling the server-side password check on server security, the Check password feature on the PAB person doc does not work. So one has to enable this check if you require the Check password option on the Person doc to work!

-- Deepa K.

***************************************************************

I've tried to use "Set Password field" to enable password checking. AdminP has processed this request. However, the user changed the password after that. And the password digest is still empty. I searched .AjDLaC38Jrn.1@.ee76ebc>SearchDomino.com admin forum but no hint.

I need help!

-- Gini W.

CHUCK'S RESPONSE:

Have you turned on password checking for the whole server? (Via names.nsf / Server / Servers / Security / Check Passwords on Notes IDs.) You must turn on the server option, then enable the feature on a per-user basis.

***************************************************************

This article was great , but in my opinion made no strong case in favor of the password checking feature.

I will list my pros and cons hereafter:

Pro:

  • Better security, marginal
Cons:
  • Increased workload for SA, especially in organizations with more than 5000 users, when things go wrong.
  • When an ID is stolen, the "thief" can change the password and so shut out the rightful owner of the ID. The thief can do an incredible amount of damage within the notes environment before he is stopped.
  • Possibility of having user's ID and servers going out of sync.
  • It doesn't solve any security risks from HTTP-based interactions with the server.
Finally, in Chuck's defense, I've got to say that I probably will tell everybody to get this feature enabled, merely on its benefit of marginal better security.

-- Edwin L.

***************************************************************

We are exploring the server-side password checking (SSPC) feature but have encountered one snag. Many of our users have ID files on multiple systems (home, laptop, desktops). Once the password is changed on one of these systems, it would appear that the others are no longer valid because their password would not match the password stored on the server. While the initial "changed" ID file could be copied to each of the other systems (possibly from a network location), the typical mode for our users is to change the password at each system location (some users operate with different passwords for each location) and would require some user education/reprocessing to incorporate the SSPC feature. Any thoughts?

-- SearchDomino.com member

Do you have comments of your own? Let us know.


This was first published in October 2003

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.