We are running EEM/PC 5.2.3 on windows XP clients.
This AM one of our helpdesk staff changed his AD password on a non encrypted machine, then tried to login on his encrypted machine & obviously had to use his old EEPC password. So he created a new token (not reset) in EEM, cleared SSO & did a force sync to his laptop. He then re started but the default 12345 is not accepted in pre boot so he has to use his old EEPC password again. Error message he gets is "0xe0010002 Authentication Parameters are incorrect".
We then did the same again & but this time didnt reboot but did ctrl alt del & tried to login again, this time 12345 worked in that it prompted for a new password, he set that to match his AD password.
We then synced again & did a reboot.
In pre boot again it wont accept his new password only his old one. We have even tried putting his old password into preboot, then ticking change password & trying to force it that way. But after every reboot it will only accept the original EEPC password.
He has even removed EEPC from his machine & re encrypted but its still the same. We have also tried this on a second encrypted machine with the same result.
We have had similar situations before & have reset the AD password as well which has made the issue go away.... but I'd like to get to the bottom of it this time.
Now whether this is coincidence or not, but on this occassion I have noticed that I cannot open his audit logs on the server properly, I get "0xe0000010 Unknown error", then I click OK & can see old audit logs stopping at the 15th June. This audit log error also happens for another user in the same group but he is not getting any login errors at the moment.
I have checked the time & date settings on his laptop & they are ok.
The other thing I wondered was whether the password issues might be to do with UPN, as per the 5.2.4 release notes:
5240.4 When using UPN usernames, at Ctrl+Alt+Del the password initially is captured and not later
SSO is set for the user and works as expected for UPN and SamAccountname initially.
Capturing the password from Ctrl+Alt+Del works too, but only if
• The name is either presented already by Windows as UPN format in the change password
screen in Windows, Or
• The user manually changes it to UPN format themselves before entering the new password.
The client has been modified so that Windows username comparison logic is aware of UPN
formatted names (i.e. takes into account the domain name when comparing usernames)
I attach the client log from the pc, the problem user is highlighted in red.
I dont have the user audit logs as they are corrupt.
Any ideas ?
In the 15:30 session, there's no evidence to indicate you created a new token for the user - only that you set the token to require change? We see database side SSO changes coming down though (meaning someone right-clicked a user perhaps and set their SSO details?)
In the 15:33 session, we see a new token coming down from the db, indicating you did touch it then
Perhaps someone confused setting the SSO details with creating a token?
That was another curious thing which we noticed too (forgot to mention that in original post), I 100% have been selecting "Create Token" in the EEM (password only token). I've did this a few times with this user yesterday, I guess its linked to the corrupt user audit logs & therefore corrupt user object itself, seeing as we get the same behaviour on another machine with that user.
We are experiencing the same password issues but the way we deal with it is through Encryption recovery. We were told this will get fixed in the next version.