Did you check his user object audit log? Is he logging in from one system or more?
Oops. Forgot to mention that that was one of the first things I did. He claims not to be logging in to any other machine and the logs support that.
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?
1 of 1 people found this helpful
look at the client log - it will tell you if/where any password changes are coming from.
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".
SbClientLog.Txt.zip 7.5 K
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.