The ID Vault may not be doing what you think it is !

Some interesting things we found during ID Vault troubleshooting.

In one environment we found some issues with the ID Vault and some users who's ID had not successfully sync'd for at least 6 months, this is where you could run into problems with user's certificates expiring and never being updated in the Vaulted ID. There is no warning that sync'ing has actually failed other than a "ID not downloaded because the wrong password was supplied." message in DDM and in the Security Log, which could also mean the user has simply done just that and entered the wrong password. In a large environment with many thousands of users (often forced to change passwords at regular intervals as corporate policy) this can be a nightmare to troubleshoot because it's actually not unusual for users to enter the wrong password at times anyway.

When using the "Extract ID" feature we also found that even if the password on the extracted ID is set the same as the user's current ID password (the password on the ID in the Vault) and the extracted ID is placed in the user's local Data directory, then these ID's will never actually sync even when the user switches to the same ID (that is supposed to force an immediate sync or upload). In that scenario we would just rename the local ID and pull the ID stored in the Vault down to the user but thought it was interesting that the extracted ID's were seen by the Vault as being "different" even when the password was the same. But again, if the local ID has been deleted or got corrupted and Vaulted ID has not sync'd for the last 6 months and the certificates in the ID are expired then you are back to square one with a user who cannot access the server.

Another interesting find was that when checking the local user ID with the File -> Security -> User Security dialog we found that if the ID file had at some time in the past successfully uploaded into the ID Vault there was a message indicating "This id file has been backed up into the vault" even if the Vaulted ID and the Local ID were not currently sync'ing correctly(and hasn't for some time). This created another issue because in the case of a corrupted or deleted local ID, the ID in the Vault could not be pulled down because the password stored on that ID was 5 previous passwords old (not sync'd for 6 months) and the user either could not remember it or was not allowed to reuse it now. This requires a Password Reset for an operation that should really be seamless and not require admin or user interaction.

Oh yeah!, don't get me started on the whole Password Reset self service thingo you know, the one where the user logs on to the server over http and can Reset their forgotten Notes Password after authenticating with their http password that was probably the same as the Notes one they've forgotten.............