January 12 2011 Wednesday
A little story about an error with ID Vault...
I like blogging such stories about strange incidents in customers :) I hope it helps my newbie readers to learn how to troubleshoot these kind of problems.
Today I made a short visit to a customer to chat. A couple of weeks ago, we struggled with some SSO issues between Domino and Portal. It seems that 'Reset Password' feature of ID Vault was not working since SSO operation. I told them there is absolutely no relation between two issues. I were so sure :)
Last year, the most popular topic in my blog was the one related to ID Vault problems. The reason is obvious. There are some 'nice to have' features that people try out implementation but in case of failure, they may just give up. However, ID Vault is an extremely useful tool that cannot be avoided...
I assumed this to be a classical issue, as well. I checked everything, from public keys to ACLs but it was OK. I recreated cross certifications, tried different users, etc. Nope! ID Vault was giving the classical error: "Missing or invalid Password Reset Trust certificate from 'XXX' to 'YYY': Note Item not found".
Here, I noticed a difference. The classical error may end with 'Entry not found in Index'. Because, normally, the problem originates from a missing certificate document.
So I opened some debug parameters (Debug_IDV_TrustCert=1; Debug_Namelookup=1) and the problem was there smiling at me :)
For password reset operation, there are cross certification documents for each resetters. For example, if an administrator (John May/Acme) will reset password of a user (Mary Jane/Acme), there should be a cross-certification document (O=Acme >> John May/Acme) for password reset operations. Server will find this document first and validate it with the organization certifier. An example:
There were two matches in the address book. I just checked with '($Users)' view and that was correct. There were a person document with 'O=acme' line in shortname field!
Probably we made a mistake while dealing with the SSO issue. It can be fatal to place your certifier name into an alias :)
I am a bit flushed... But the problem has been solved...
Today I made a short visit to a customer to chat. A couple of weeks ago, we struggled with some SSO issues between Domino and Portal. It seems that 'Reset Password' feature of ID Vault was not working since SSO operation. I told them there is absolutely no relation between two issues. I were so sure :)
Last year, the most popular topic in my blog was the one related to ID Vault problems. The reason is obvious. There are some 'nice to have' features that people try out implementation but in case of failure, they may just give up. However, ID Vault is an extremely useful tool that cannot be avoided...
I assumed this to be a classical issue, as well. I checked everything, from public keys to ACLs but it was OK. I recreated cross certifications, tried different users, etc. Nope! ID Vault was giving the classical error: "Missing or invalid Password Reset Trust certificate from 'XXX' to 'YYY': Note Item not found".
Here, I noticed a difference. The classical error may end with 'Entry not found in Index'. Because, normally, the problem originates from a missing certificate document.
So I opened some debug parameters (Debug_IDV_TrustCert=1; Debug_Namelookup=1) and the problem was there smiling at me :)
For password reset operation, there are cross certification documents for each resetters. For example, if an administrator (John May/Acme) will reset password of a user (Mary Jane/Acme), there should be a cross-certification document (O=Acme >> John May/Acme) for password reset operations. Server will find this document first and validate it with the organization certifier. An example:
[0B30:009A-0CC4] NAMELookup::<lookup> Searching view '($Users)' (1 of 1 views).
[0B30:009A-0CC4] NAMELookup::<lookup> Searching name='O=Acme' (1 of 1 names).
[0B30:009A-0CC4] NAMELookup::<lookup> Searching DBIndex=1.
[0B30:009A-0CC4] NAMELookup::<lookup> NumReturned=0, TotalNumReturned=0 match(es) for name='O=Acme'</blockquote>
In this case, it could not find the certifier document (entry not found in index). In my case, though:
<blockquote>[0B30:009A-0CC4] NAMELookup::<lookup> Searching view '($Users)' (1 of 1 views).
[0B30:009A-0CC4] NAMELookup::<lookup> Searching name='O=Acme' (1 of 1 names).
[0B30:009A-0CC4] NAMELookup::<lookup> Searching DBIndex=1.
[0B30:009A-0CC4] NAMELookup::<lookup> NumReturned=2, TotalNumReturned=2 match(es) for name='O=Acme'
There were two matches in the address book. I just checked with '($Users)' view and that was correct. There were a person document with 'O=acme' line in shortname field!
Probably we made a mistake while dealing with the SSO issue. It can be fatal to place your certifier name into an alias :)
I am a bit flushed... But the problem has been solved...
Serdar Basegmez
|
January 12 2011 09:17:59 AM
|
ID Vault Lotus Domino System Administration
|
Comments (3)
Hello Thibaud,
Nice to hear I have helped you!
Hi Serdar,
Thanks for this info, the notes.ini settings helped me to solve this issue at a customer. Seemed that the certifier document couldn't be found anymore. Editing by adding a comment and saving the certifier document solved the issue here.
IBM support portal / kb doesn't have clear info about this and googling brougth me to your blog. thanks!!!.
Greets,
Thibaud
I had run through many of the normal potential issues with ID Vault and missed the fact that a 20 year old certifier document entry was not showing under O=Company in the ($Users) view until spotting the error mentioned here, together with a user with the "Company" as their first name and therefore in ($Users) too, cleaned up and working as I thought it already was for them!