ID Vault: New password sync is not working robust (presenting "Wrong password" first)

HCL Domino Domino Forum
1

A user (Samantha Daryn/SALES/HENSELER) had changed the password of the local ID on machine 1 at 11:41:13 PM and had closed the Notes client at 11:47 PM.The user ID was updated in the vault at 11:41:22 PM.

The same user logged in on Machine 2 at 11:51, where his Notes was already configured with local a user.id and an old password.

He entered the new password and a “Wrong password” error message appeared.

He entered the new password once again and “Wrong password” appeared again.

The third time the user entered his password, Notes accepted it.

To proove that the first password was not misspelled, it was checked 4 times.

In the 2nd try, the wrong password dialog appeared twice, in the 3rd try the user logged in.

In the 3rd try, the wrong password dialog appeared twice, in the 3rd try the user logged in.

In the 4th try, the wrong password dialog appeared twice, in the 3rd try the user logged in.

Here’s the debug.log of one client session:

debug_IDVAULT1_2008_09_11@23_13_59.log

11.09.2008 23:13:59,65 [0A68:0002-0BF4] DeskClientOpenInt> Calling CreateProgramRCP pszRCPCmdLine[/authenticate “=C:\Program Files\IBM\Lotus\Notes\notes.ini”] bDeskProvisioningRestart [0]

11.09.2008 23:13:59,68 [0A68:0002-0BF4] DeskClientOpenInt> Executed CreateProgramRCP

IDVault Download - Attempt to contact cluster server CN=DERHNMA01/OU=SERVER/O=HENSELER, error: No error

IDVault Download - Attempt to download from cluster server CN=DERHNMA01/OU=SERVER/O=HENSELER, error: No error

IDVault Download - Attempt to contact cluster server CN=DERHNMA01/OU=SERVER/O=HENSELER, error: No error

IDVault Download - Attempt to download from cluster server CN=DERHNMA01/OU=SERVER/O=HENSELER, error: No error

(1-43 [1]) POLL_DEL_SEQNUM: (Connect to DERHNMA01/SERVER/HENSELER: 0 ms) (OPEN_SESSION: 2 ms)

2 ms. [114+32=146]

IDVault Download - Attempt to contact cluster server CN=DERHNMA01/OU=SERVER/O=HENSELER, error: No error

IDVault Download - Attempt to download from cluster server CN=DERHNMA01/OU=SERVER/O=HENSELER, error: No error

11.09.2008 23:14:48 Dynamic Client Configuration started

11.09.2008 23:14:49 Initializing Dynamic Client Configuration

11.09.2008 23:14:49 Dynamic Client Configuration updating policy information

11.09.2008 23:14:49 Dynamic Client Configuration updating location information

11.09.2008 23:14:49 Dynamic Client Configuration shutdown

(2-50 [2]) POLL_DEL_SEQNUM: (Connect to DERHNMA01/SERVER/HENSELER: 126 ms) (OPEN_SESSION: 0 ms)

1 ms. [110+28=138]

These are the corresponding Security event entries:

11.09.2008 22:52:18 ID successfully synchronized with vault ‘O=HENSELER-IDVault’ for ‘Samantha Daryn/SALES/HENSELER’ (IP Address 192.168.91.148:1224).

11.09.2008 23:06:48 ID successfully synchronized with vault ‘O=HENSELER-IDVault’ for ‘Samantha Daryn/SALES/HENSELER’ (IP Address 192.168.91.148:1230).

11.09.2008 23:06:49 ID successfully synchronized with vault ‘O=HENSELER-IDVault’ for ‘Samantha Daryn/SALES/HENSELER’ (IP Address 192.168.91.148:1232).

11.09.2008 23:07:15 ID successfully synchronized with vault ‘O=HENSELER-IDVault’ for ‘Samantha Daryn/SALES/HENSELER’ (IP Address 192.168.91.148:1237).

11.09.2008 23:07:23 ID successfully synchronized with vault ‘O=HENSELER-IDVault’ for ‘Samantha Daryn/SALES/HENSELER’ (IP Address 192.168.91.148:1243).

11.09.2008 23:09:39 ID successfully synchronized with vault ‘O=HENSELER-IDVault’ for ‘Samantha Daryn/SALES/HENSELER’ (IP Address 192.168.91.148:1247).

11.09.2008 23:09:39 ID successfully synchronized with vault ‘O=HENSELER-IDVault’ for ‘Samantha Daryn/SALES/HENSELER’ (IP Address 192.168.91.148:1249).

11.09.2008 23:10:04 ID successfully synchronized with vault ‘O=HENSELER-IDVault’ for ‘Samantha Daryn/SALES/HENSELER’ (IP Address 192.168.91.148:1253).

11.09.2008 23:11:17 ID successfully synchronized with vault ‘O=HENSELER-IDVault’ for ‘Samantha Daryn/SALES/HENSELER’ (IP Address 192.168.91.148:1257).

11.09.2008 23:11:18 ID successfully synchronized with vault ‘O=HENSELER-IDVault’ for ‘Samantha Daryn/SALES/HENSELER’ (IP Address 192.168.91.148:1259).

11.09.2008 23:11:41 ID successfully synchronized with vault ‘O=HENSELER-IDVault’ for ‘Samantha Daryn/SALES/HENSELER’ (IP Address 192.168.91.148:1263).

11.09.2008 23:11:48 ID successfully synchronized with vault ‘O=HENSELER-IDVault’ for ‘Samantha Daryn/SALES/HENSELER’ (IP Address 192.168.91.148:1268).

11.09.2008 23:14:21 ID successfully synchronized with vault ‘O=HENSELER-IDVault’ for ‘Samantha Daryn/SALES/HENSELER’ (IP Address 192.168.91.148:1272).

11.09.2008 23:14:22 ID successfully synchronized with vault ‘O=HENSELER-IDVault’ for ‘Samantha Daryn/SALES/HENSELER’ (IP Address 192.168.91.148:1274).

11.09.2008 23:14:45 ID successfully synchronized with vault ‘O=HENSELER-IDVault’ for ‘Samantha Daryn/SALES/HENSELER’ (IP Address 192.168.91.148:1278).

2

Subject: Balance of simplicity

We discussed for many days what to show to end users when something goes wrong during communication with the vault servers or there is a delay.

We could have just let the end user wait until the attempt to recover the ID file is complete, but that could take a long time in some cases and really isn’t acceptable.

We could have displayed what the current state was → “The background thread attempting to recover your ID file has not finished quickly, we are letting it continue, but we wanted to let you know what was happening in the meantime” or “replication among the vault servers was not complete, so there is a short delay as we try the next replica” This wasn’t really acceptable. We think that most Notes users use Notes to run their business and really don’t care what’s happening under the covers. Any complex dialog would trigger a help call.

Out final design is this:

When a user enters their password we check to see if it matches the local ID file. If it does we’re OK.

If it does not, we start a background thread to locate a vault replica and attempt recovery of the ID file. While this thread is running we set a 5 second timer. If recovery occurs before the timer goes off, we are OK. If not the user is told bad password. Yes - we know its the wrong error message, but let me continue. If the user just enters the same password again we check if the background thread has succeeded. If it has and the password is the same then all is OK.

In the final product, to make this delay shorter, we cache the most recent successful vault server name and contact that server the next time as the first try.

So, what can you tell your end users about password management with the vault?

  1. Tell them that whenever they change a password on one machine the password is saved on a server (if they were on the network). And if they use any other client machine they can always just type the new password (if its on the network). No more changing the password on every machine or copying ID files.

  2. Sometimes when entering your password (either during forgotten password recovery or when using a new password on a machine for the first time) if there is a long delay in contacting the server doing password management you may see the wrong password error. Try again with the same password after a moment before calling the help desk. You can try several times, its OK.

Pete Mierswa

3

Subject: Some feedback

I agree its good to avoid peculiar messages!

Hovever in a WAN sceneario 5 second is probably to short time. Could you give us a notes.ini parameter or policy setting for this timeout

I would probably set a 15 secs for intercontinental Notes users, 5 secs would only cause a predictable confusion?

The caching algoritm is of course good for users who switch PCs often…

Best Regards

Ulf

4

Subject: That delay is configurable through a notes.ini variable

Set IDV_POLL_INTERVAL to the desired delay in ms; the default is 5000 (5 seconds). You can either set that value directly in the client’s local notes.ini, or indirectly through a policy setting.