I have a few users whose passwords seem to randomly "go bad". That is, they cannot log in at pre-boot. And the default password doesn't work. I was ready to chalk this up to fat-fingering, but this morning, I worked with one of our network guys and walked through a password recovery with him. He successfully logged in and the credentials were passed through to Windows. Subsequently his machine synched with the server (I checked the audit log). Then he called me again this afternoon and said his password wasn't working again. We checked numlock/capslock. He typed extremely slow and careful and swears no fat-fingering. I logged in as Admin just to be sure it would let someone in. So once again, I just did a password recovery and he is fine.
The question is - what are the possible causes besides the obvious fat finger I mentioned? Can a token just randomly change or become corrupted in some way that disallows a log in but allows a password recovery? Any ideas on how to troubleshoot would be appreciated.
try "12345" in these cases - if any token password operations fail, they always try to set things back to the default.
An example would be a windows password change where the new windows password is not acceptable by EEPC (for example it's in the history, or does not meet the requirements).
Sorry for not being clear. The default password has been tried. In the case of the one I worked with this morning, the password reset worked fine and EE passed the credentials to Windows successfully. And as described above, the machine had a subsequent synch. So as far as I understand, a successful EE login, followed by a successful Windows login, followed by a successful server synch should complete the process. The second password failure occurred within hours and did not involve any change in the Windows password.
Am I doing everything I can and I just have to accept that there will be a number of unidentified password failures?
Looks like it might be getting clearer. This error occurred a couple of times this morning which indicates the token and SSO updates may not be making it to the server reliably.
Error connecting to database [5c00000f]: Failed to connect to the remote computer
Next question then is can I set the synch to retry sooner than the 60 minutes interval we have set in the case of a failure to connect? In other words, I want a 60 minute wait when it is successful, but I want to try again in say 5 minutes if it is unsuccessful.
Once again, thanks for pointing me in the right direction.
failing to upload the token won't change it locally, so usually making the sync more frequent only adds unnecessary network traffic.
A local change though either comes by virtue of a successful sync (where a change moved to the client), or if the client itself changed the password. There's no random password changes/resets.
Ok. So back to square one. I'm attaching the client log file. I hope it isn't too presumptious of me to ask you to look at it.
I didn't see anything proprietary in it. I did the first password recovery around 9AM. I did the second one about 1:45. As you can see, there were problems updating the server a couple of times.
BTW, his user object is "2b2".
so I guess we are talking about the user nhardware1?
the important lines are:
1/13/2010 2:58:07 PM Adding user (ID=0000005c) nhardware1
1/13/2010 2:58:11 PM Updating local SSO info with database changes for user (ID=0000005c)
1/15/2010 11:47:44 AM Updating local token data with database changes for user (ID=0000005c)
1/19/2010 10:29:51 AM Updating local token data with database changes for user (ID=0000005c)
1/19/2010 11:49:39 AM Updating local token data with database changes for user (ID=0000005c)
1/19/2010 4:59:40 PM Updating local token data with database changes for user (ID=0000005c)
1/21/2010 9:07:31 AM Updating local token data with database changes for user (ID=0000005c)
1/22/2010 9:30:14 AM Updating local token data with database changes for user (ID=0000005c)
1/22/2010 10:46:13 AM Updating local token data with database changes for user (ID=0000005c)
So you can see, that the database always has a later timestamp than the local machine for that account. That would indicate that the time/timezone is wrong somewhere - either on an admin machine where the token is being reset, or on their machine.
recreate the users token (don't reset it) - that will set the timestamp to that of the machine you are running EEM (SBAdmin.exe) on. As long as the users machine has the right time you should see that go down to their machine. Then, if they change the password you should see on the next sync that it goes in reverse - ie up to the db.