This content has been marked as final. Show 12 replies
EEPC does not store the password, so it cannot pass it across unfortunately.The only thing which is ever stored is one way salted PKCS-5 hashes for history checking.
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.
That is sort of implied... since the user has forgotten the MEE password (and Windows if it is same). If you lose your house key, change the dead bolt lock and the handle lock.
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?