EEPC is hooked into windows as a network provider, so it can only see password changes when you change a network based credentilal (Iike a domain password).
There's no way to hook the local windows password change - it only has relavence to Windows.
When SSO fails, and you're prompted to enter your credentials, we can capture then (via a login hook), so we can update the stored credentials then, but not when you do a password change of a local account.
Okay, I tried on a PC on an AD domain using a domain user account and I see the same behavior, even WITH a sync of the EE client to the EE server. I still have to use the old pw once after the reboot and then provide the new pw again after the failed SSO Windows login attempt.
1. how are you changing your password? using the ctrl-alt-del screen?
What OS are you using? The only thing I can think of is that the credential provider is not working as a network provider - perhaps some other credential tile is taking over?
Yes, CTRL-ALT-DEL, then select Change Password.
Windows 7 with SP1 64-bit. There's no other special software installed, pretty much a stock default Microsoft Windows 7 install. Certainly no other software that would be doing anything with the credential provider.
Oh, and it's EE version 5.2.4 if that matters.
I will say that the PC was NOT a member of an AD domain when the EE client was installed and configured initially. It was added to the domain afterward. Would that make any difference?
possibly - I know there's no QA performed on non-domain hardware, we assume perhaps wrongly that enterprise product is used on domain-connected hardware.
just install again, you won't need to re-crypt etc. There may be reg keys which were updated when you moved into the domain.
You should of course consder upgrading to a newer version as well
Yeah, most of our users are part of our domain, but we have a fleet of users who are not connected to our AD domain and use the PC's in a standalone mode. But some of these users may then connect the PC to their own network that might have its own domain.
This, and that other question of mine about resetting the cached Windows credentials, stem from upgrading this "disconnected" fleet from Windows XP to Windows 7. In Windows XP we had McAfee take over the Windows SCREEN SAVER unlock, but NOT actual Windows LOGIN. But apparently in Windows 7, at least with our version of the EE client, 5.2.4, EE can not take over the screen saver without also taking over the windows login. So now we're trying to make the best of a bad situation.
Unfortunately upgrading the EE client version is out of my control at the moment. They are working on upgrading to 6 but it won't happen for quite a few months yet and we have workstations we need to start rolling out with Windows 7 in this environment now.
yes, Windows 7 uses a credential provider, XP uses a GINA, the capabilities of each system are very different. Remember, you're not logging into "the screen saver" - you're logging into the locked session, much like RDP. Only w95 and before actually implemented the password protection in the screen saver process itself.
That's why you can use any screen saver you like in XP+ - all they are is a full window application, nothing special at all.
Hmm, go figure. I finally got a chance to try just reinstalling the McAfee client after adding the PC to the domain and by golly it worked! It now syncs the password immediately when changing it Windows!
Now, if I can figure out what it's changing, if it is just some registry settings, maybe I can just write a script to just change the registry settings rather than having to actually reinstall the client.
This is an older thread of mine, but I finally got back around to more testing and figuring out exactly what's going on, and did.
As I mentioned in a previous post, McAfee Endpoint Encryption is installed initially on these PC's before they're joined to a domain, then are joined to a domain later.
When I rerun the McAfee EE client install after adding the PC's to the domain, it adds a "Safeboot Network Provider" service that apparently didn't get installed with the initial EE client install. After it adds that service, McAfee will indeed change the McAfee password immediately when the Windows password is changed.
Unfortunately this now creates a different problem for me. I'm using some of these computers with Windows Small Business Server 2011 Essentials. Joining a computer to the domain in this environment consists of running a wizard. This wizard requires rebooting a few times. With this Safeboot Network Provider service now in place, after kicking off the wizard, and the PC reboots the first time, something has invalidated the password for the McAfee EE user account that I was using. I have to do a user recovery to reset the password on it.
The wizard does ask for the network user ID and password of the person that will be using the computer on the server before it reboots but I'm not sure what it might actually do with that information at that point in the setup proces.
The wizard also creates a special local account on the Windows PC that it wants to auto-login with after the reboot to kick the wizard back off and continue (which of course the McAfee auto-login interferes with, which is a whole separate question that I've already figured out how to deal with).
If I run this connection wizard before reinstalling the McAfee EE client, so before the Safeboot Network Provider service exists, I don't have the above problem. The wizard reboots the computer and I can log in to EE with the same password I had used before running the wizard. (Once the wizard finishes and I log into Windows using the network user ID and password, then McAfee picks up the new network password and assigns it to the EE account too.)
But if a situation occurs where I need to run this wizard after the Safeboot Network Provider is installed, it causes the above issue with invalidating the password of the EE account. It won't take either the original password for the EE account before I ran the wizard, nor the password from the network user account typed into the connection wizard, nor the "default" EE password.