If a user locks their account by entering an invalid password x-number of times, they get the error that their token has been invalidated. According to the KB, we would then need to do a "Change Token" through the recovery console.
What I've found is that this changes their EEPC password but the passwords are then out of synch because then EEPC still uses their good Windows password to log them into Windows. They now have 1 EEPC password and 1 Windows Password. I tried using "Create Token" instead of "Change Token" and the same thing happens.
What I would expect to happen would be that EEPC would pass the users EEPC password to Windows and then Windows would reject is, the user would login with the proper AD password and the EEPC client would sync them up.
Within the console I have the following General options enabled:
Attempt Automatic Windows Logon
Automatically Logon as Pre-Boot User
Endpoint Encryption Logon Component Always Active
Set Endpoint Encryption Password to Windows Password
Must Match Windows User Name
Has anyone configured their environment to work the way I'm expecting it to work?
EEPC must be storing the AD password locally in the SbFS, otherwise how could one ever have an EEPC password different than their AD password? And how would SSO work?
Here's the scenario:
1. UserA has password "pa55w0rd". 2. UserA invalidates token (x-number of failed attempts to Pre-Boot). 3. HelpDesk does "Create Token" or "Reset Token" in webHelpDesk 4. UserA, in pre-boot, picks "temporary" as new password.
So, now the users AD password is "pa55w0rd" and their EEPC password is "temporary".
5. UserA logs into EEPC using "temporary". 6. EEPC SSO kicks in and logs the user into windows using password "pa55w0rd".
But, the user now thinks his password is "temporary", so he'll try and use that everywhere that asks for his AD password, so it will obviously fail. It would also fail on any system that wasn't encrypted.
We could reset the AD password when we do a Create / Reset Token, but then users who know their AD password but don't know their EEPC password (loaner systems they haven't used in a while and are out of sync, support staff on disconnected systems, etc) would have to have their AD password reset just because they guessed a few too many times.
we have two slots in the policy, one for the secure one way hash of the EEPC password, and one for the users Windows credentials (encrypted with the users EEPC key, which itself is encrypted with their true password).
so, we don't need to actually store their password, and it's quite possible to have different windows SSO creds and pre-boot creds.
I should also add, that if you're using SSO, and the user forgets "their password", then they have forgotten both the AD and EEPC password - both need to be reset because the user knows neither of them (wheras EEPC still knows the Windows password).
how to reset an AD password is up to you, but of course, if the user is offline, you can't remotely reset it. This is why we let EEPC keep using it's cached copy (so the user can still use their machine). If you reset their AD password, then that won't take effect until they next connect to the network.
so, best to simply set the users AD password to something temporary, tell them what it is and to use it next time they logon to the network, and tick the change at next login.
When they change their network password, it will of course change their pre-boot password to match (if you have the options set).
convoluted I know, but with the limitation that you can't change your domain password offline, the best of all evils.
I see what you're saying and can see where what you're doing would be beneficial to primarily disconnected users. I guess our process would be that if the user is locked out and knows their AD password, they should use that password to keep them in sync - otherwise both the EEPC and AD password would need to be reset.
MrGui, even when the passwords are in synch on most systems, there are plenty of cases where a user would not know their MEE password but would know their AD password. For example:
Non MEE Admin IT Staff logging into systems that have been offline / locked up over time
System not logged into over period of time where user has reset their AD password multiple times
Users logging into loaner laptops where no one has logged in for a while
There are probably more. I'm trying to design a process around what to do if the user knows their AD password (i.e. it works everywhere else but this one laptop) but the user doesn't know their MEE password.
A reset password will change the MEE password. If they know AD/Windows password, that is all you need. Unless you have a Active Directory password sync service that can export the clear text to a script, then you can't get it. MS uses very different hashes than McAfee does, so you can't just import the hashed password. If they were that easy to transport, it would create a dangerous security situation.
I completely grasp that, but wouldn't a better solution perhaps be to bypass the preboot screen on a user basis (not resetting their MEE password) vs a machine basis, then capturing the users password and performing a synch on login?