Your views on Notes ID storage

View member feedback to this tip.

In last month's tip, Where to store Notes IDs, I discussed the various places system administrators store Notes ID files. I received some interesting feedback from that column, including ideas about storage I had not considered. SearchDomino.com also conducted an online poll asking the same question, and nicely supplied me with the results of the poll. So this month I will comment on the feedback and poll results. (I will address storage of certifier IDs in a later tip.)

1. Several readers wrote and told me about custom Notes applications they have written to store ID files. Some of the applications contain helpful buttons to attach newly created IDs and to detach them when needed. Various views in the databases track IDs by name, creation date or other criteria. One of the applications contained audit trail features to track each operation on each ID. And, of course, only administrators can access these databases.

2. One reader chastised me for criticizing the storage of ID files on network folders. His point was that a personal network folder could be more secure than the disk drive of a computer kept in a public place. Point well taken. I still believe an ID file is more secure in a locked office on the hard drive of a computer that is turned off for the night, rather than on a network folder. But the "locked office" model does not apply to many organizations.

3. One of my consulting clients showed me how they use personal network folders to create a "roaming user" concept for all employees. All of the Notes workstations files (except the base software) are stored in a personal network folder, assigned to the mapped K drive. This includes the user's ID file, their Desktop.dsk and their Notes data directory. So a Notes user can log on from any computer in the organization and have the same workspace. The Windows log-on scripts map the K drive for each user to the appropriate network folder (which no other user can access). Voila! Roaming users for any version of Notes.

4. A reader told me he is using a product called IDManager from HelpSoft. IDManager helps with many of the common ID management tasks, including password assignment, recertification, account termination and mail-in databases. This reader reports that he is happy with the product.

5. A surprising 46% of readers indicated in the poll that they store their ID files in a "shared drive on the network." I find this answer disturbing, since this practice invites everyone in the organization to see which ID files they can hack into. Part of the problem here is that I did not word the poll correctly; I failed to distinguish between a personal network folder (that other people cannot see) and a shared network folder. A note of caution though to any administrators who are storing IDs in a shared network folder: The passwords for the IDs better be unique and high quality, because you are giving everyone in your organization access to all the ID files and an unlimited time to guess passwords.

6. Finally, one reader pointed out that I have not yet explored every feature of R6, since it contains a roaming user feature. The Notes ID file for these users is stored in a "roaming file" for that user on a Domino server. Thank you for noticing my oversight. If it is important to you that a user can log on to various computers, and you have not already set this up with network directories, you might want to look at this R6 feature.

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

There are a number of criticisms of keeping IDs on shared network drives. These administrators are not implying that the network drives are shared with everyone. Presumably a very small group is allowed to see the directory containing the IDs. Still, we could debate the relative security of network drives whether on a Windows server or other operating system.

-- Doug J.

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

A thorny issue, this one. I'm involved in a mixed iNotes/full Notes 20,000 user environment, moving from multiple domains to a new, single domain. We use a combination of the following (each with their own limitations):

1. Domino's Password Recovery facility. The biggest problems with this are:

   • The limit of eight recovery authorities. With a long-term domain, and a reasonable turnover of administrators, this is a significant problem. We don't want to use functional admin IDs (for obvious audit reasons), and the server-based CA process only updates recovery authorities on active ID files (i.e., those being used to log into servers).

   • IDs created using the server-based CA process are not sent to the Password Recovery database at registration time (unlike conventionally created ID files). It isn't until the full client uses the ID file (and gets the rest of the certification details from the server) that the ID file gets mailed to Password Recovery. We have found some cases in which it never got mailed -- presumably a full-client bug. As a result, we can't use the server-based CA process for registration, because a proportion of our users run only iNotes (although they may switch to full client in the future), so their IDs never get to the Password Recovery database at all!

2. Custom-built ID vault database. Problems:

   • Not automated. We have to rely on administrators adding the ID files at registration time -- this somehow gets overlooked sometimes!

   • Passwords must also be stored, so administrators have unlimited access to ID files, right up to the Chief Executives'.

   • Updates to recovery authorities, certifications and renames all have to be updated into the database manually.

3. Restricted-access shared network drive (required for temporary distribution of IDs at installation time). Problems:

   • Hacker access (as you have pointed out, Chuck).

   • Removal/deletion is not automated. Again, we have to rely on administrators removing the ID files after use, and this gets forgotten.

   • Either a standard password is used (definitely not!), or a parallel method of distributing the passwords is needed.

4. Mail files (as in the R6.0.2 new feature using profile documents). Problem:

   • This doesn't really provide ID "management" at all. We've been testing this. Passwords are not synchronized, and certification, recovery authority and name changes do not get updated into the ID file in the mail file.

More pressure on Lotus is needed -- ID management is a big part of TCO at the moment.

-- John K.

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