Manage Learn to apply best practices and optimize your operations.

Assigning unique initial passwords

Read members' comments to Assigning initial passwords by Chuck Connell.

As a follow up to Chuck Connell's Assigning initial passwords, I offer this solution for unique initial passwords that users will change.

A simple local database contains one form (User) and one view (Export string).

The User form contains fields for user values that will vary for users being registered (last name, first name, middle initial, organizational unit, mail server name, etc.)

The Export string view contains one column with a formula displaying registration data for the user, based on the parameters identified in Administration Help ("Registering users from a text file"), each parameter separated by a semicolon. This view is exported as a text file (i.e., newusers.txt), which is then imported during the registration process.

The user's password is assigned from the first 16 characters of the hexadecimal unique ID of the document for the user -- something users will want to immediately change. Users receive a handout with their initial password at a mandatory Using Lotus Notes orientation class (cuts down on future support calls).

A sample formula is provided below.

@trim(lastname) + ";" + @trim(firstname) + 
";" + @trim(minitial) + ";" + @trim(regou) + ";" 
+ @UpperCase(@Left(@Text(@DocumentUniqueID);16)) 
+ ";" + "C:adminids" + @trim(@left(firstname;1)) 
+ @trim(@left(lastname;7)) + ".id" + ";" + mailservername 
+ ";" + "mail" + ";" + @trim(@left(firstname;1)) +
 @trim(@left(lastname;7)) + ".nsf" + etc....


I disagree with Chuck on this one. I use Choice 2 -- "Common password for all IDs, and instruct users to change it," but with a twist. I virtually guarantee that users will change it by making the default so long that no one would want to keep it. It's that simple. And yes, the IDs are stored securely.

-- Steven S.


Chuck assumes in one paragraph that the Internet passwords (Webmail) are the same as the ID passwords and are set when the ID is created. Ouch! Isn't that a bad security practice in general? If one is in an organization that strongly uses (hardly any Notes clients) the Web devices available, doesn't it make sense to set the Internet password, then check the little "Force user to change Internet Password on next login" box?

Good article in general, but I'm wondering how many organizations could cope with the issues involved in the strong password scenario.

-- Eric P.


We assign unique, deliberately obnoxious passwords for our users that they'll have to change to keep their sanity and then send them instructions on doing so. We also use ID archiving and password ID recovery, rendering the concept of keeping the IDs around unnecessary. They are then as secure as the administrators' passwords.

-- member


One customer of mine uses the initial password "please change your password," which is actually very difficult to type accurately blind, is long and rubs in the fact that they should change it every time that they log in to Notes. While the #2 choice is poor, agreed, this initial password does mitigate it to a reasonable extent.

-- Mick M.


For choice #4, Chuck stated, "The administrator will have to keep a written list of all username/password pairs, which is less likely than the administrator remembering one password for all accounts."

I assign complex passwords, but I never write down the passwords. When I certify my password, I created a numeric key:
25781452 - pick your own eight-digit key.

Now in my case, my ID file would be called or for Joe Blow the ID file would be For names less than eight characters, just repeat the first characters to get to eight, so becomes jblowjbl.

Now we use the key, the first number of the key is 2, so the first letter of the password is b, the second number of the key is 5, so the second character of the password is w. So now the password assigned to Joe Blow is "bwbljowb." Now Joe recognizes that his password consists of letters in his name but it is such a pain, that he is quite willing to change the original password. Joe could not reverse engineer the key because some of his letters are duplicated, the first b is the first position and the second b comes from position 7. Now John Vanderhoff could reverse engineer the key, but chances are a couple of minutes after he got the password, he changed it and forgot about the original password. Now if I need to retrieve the original password, I look at the filename and using the key I know the password without ever having written the password down. I actually have the key written down on a post-it in my office, that a glance at when I'm creating a new ID.

-- John V.


To Steven S. -- Yes, this is a reasonable solution. It still leaves open the fact that the original copies of all the IDs have the same password, and that everyone knows it. But if you are REALLY confident about the storage for your original IDs, this can work well.

Eric P. -- Two comments: First, many users do, in fact, want their Notes and Internet passwords to be the same. Obviously, they would be more secure if they used two different passwords, but the reality is that most people want to minimize the passwords they remember. Second, you are right about the value of the "force user to change" option. I overlooked this because I often use R5, and that option is not supported in R5 (as far as I can tell). But I agree that administrators should use this feature for Internet passwords in R6. member after Eric P.'s post -- Yep. What you describe is exactly what I advocate.

Mick M. -- Same comments as what I responded to Steven S.'s post.

John V. -- Hhhmmm...This is really the same as my choice #3 in the survey. You are assigning unique passwords to each ID, but the passwords are simple and easy to figure out. (If someone figures out the trick to their initial password, they know everyone else's initial password also.) But you are right that people will probably change their password. Make sure you store the original ID files securely, though (i.e., the Password Recovery feature), or you are inviting everyone to guess your scheme and steal IDs.

Thanks to everyone who wrote!

-- Chuck Connell

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

Dig Deeper on Lotus Notes Domino Password Management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.




  • iSeries tutorials's tutorials provide in-depth information on the iSeries. Our iSeries tutorials address areas you need to know about...

  • V6R1 upgrade planning checklist

    When upgrading to V6R1, make sure your software will be supported, your programs will function and the correct PTFs have been ...

  • Connecting multiple iSeries systems through DDM

    Working with databases over multiple iSeries systems can be simple when remotely connecting logical partitions with distributed ...