I have changed several of my users internet password. I have 2 flavers of users, people here in the office and others in the field exclusively. The people here in the office, I have changed their password and all is fine. My problem is with the remote users, I have changed their password in their person doc on the server a week ago. No one’s password has changed. When I initiate a SameTime meeting and they log in, the old password works, the same is true when they check their e-mail via the web. I even deleted their person doc on their local NAB and copied the updated person doc from the server, no change.
Normally when people write up this issue, it’s because they haven’t given the HTTP cache a chance to clear out the old data and re-index the new.
Easiest thing to do in this case (if permitted) is to simply restart the HTTP service (at the Domino Console type “tell HTTP restart” without the quotation marks and then tap Enter on the keyboard).
But it sounds like you’ve made the change a while ago and still no password changes have taken hold, is that correct?
First of all, DON’T delete person docs unless you really understand what you’re doing. These documents share an encrypted key with the user’s User ID (public key is listed in their person document), and if you lose that key, you’ll need to re-register the users and recreate a new User ID (major pain).
Besides, what’s listed in their PNAB or local replica of the NAB has nothing to do with what the Domino HTTP service uses for authentication. It only uses what’s listed in the Domino Directory on the server.
Are you using R6 or R7 policies? If so, you or another System Admin may have set up User ID and internet password synchronization. This policy (which I use all of the time) tells Domino that you want a user’s internet password to be set to whatever the user’s User ID password is.
So even if you changed the internet password at the server, once the user logs in to Lotus Notes, the internet password would be changed to whatever the User ID password is.
Is that a possibility?
So to recap, even though it’s unlikely at this point, restart the HTTP service.
Next, determine whether or not your domain has a policy setup which is auto-syncing ID password and internet password.
First of all, DON’T delete person docs unless you really understand what you’re doing. These documents share an encrypted key with the user’s User ID (public key is listed in their person document), and if you lose that key, you’ll need to re-register the users and recreate a new User ID (major pain).
Yes, pay heed to the warning above.
Some of the Workplace systems use a Person doc’s UNID to uniquely identify the entry - they may not use the Person’s Notes distinguished name, as we do for ACLs or Group members. Deleting a Person doc and creating a new one will not assign the latter the same UNID as the former.
A user shouldn’t have a Person doc in their own names.nsf, and even if they did it doesn’t have a password field on it. Do you mean the users have a local replica of the Domino Directory? Even if they do it doesn’t matter. Sametime, being a server applicaition, will use the information it has available locally. It doesn’t even know (or care) that there is a replica on the local client.
My first suggestion would be to replicate names.nsf and admin4.nsf from the administration server for your Domino Directory to your Sametime server. If that doesn’t help, change the Internet password in the Domino Directory replica on the Sametime server, then restart HTTP on the Sametime server. That usually clears up these problems for me.