This is strange. The public key in an ID file for a particular user does not match the public key in the person document, but the user still authenticates and has relevant authority. ( exported the key to clipboard from the ID file and compared with person document )
This user is the first user - admin - created for this domain, so fairly important. It has been recertified due to normal expiration intervals. However the situation exists that an ID file ( probably before recertification ) with the wrong public key ( fairly similar key with the odd octet differing )can authenticate with the server and access databases that have no default or public access.
The client is 6.5 with a 5.0.9a server. The infrastructure is very simple with a single server. The problem was identified when trying to resolve a nested group authentication problem with a different user.
Anyone seen anything like this before? I always understood that this would not work, but maybe the odd octet can be different?
Subject: “Notes Certified Public Key” == Notes Certificate
The object that Notes/Domino refers to as a “Notes certified public key” is basically a Notes certificate, that creates a signed mapping between a name and the public key. Recertifying the ID file will update the Notes certified public key stored in the directory and the ID file, but as long as the name and public key haven’t actually changed, old copies of the ID file will still be able to authenticate to the server and download the updated certificate.
Subject: Public keys don’t match, but user.id still authenticates with server!!!
Implement password checking on the server and on this ID (or all IDs). The settings are on the Security tab of the Server doc.
Subject: Public keys don’t match, but user.id still authenticates with server!!!
Unless you enable one of a couple of optional security fields in the server document (like “Compare public keys against those stored in directory”), the person document plays no role in authenticating the user, and never has. As long as the user ID and server ID can authenticate each other, everybody’s happy. So the situation you describe is normal behavior.
Subject: RE: Public keys don’t match, but user.id still authenticates with server!!!
you need to enable the setting in the person dosument “check password”
Subject: RE: Public keys don’t match, but user.id still authenticates with server!!!
I believe that setting does NOT cause the server to compare public keys during authentication.
Subject: RE: Public keys don’t match, but user.id still authenticates with server!!!
It would appear that my concern is unfounded. Thanks for clarifying that.