It's only the first time - this is (badly) explained in p56 of the documentation - https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/ 23000/PD23435/en_US/EEPC_6_1_2_product_guide.pdf
basically, if the SSO details are blank, or fail (password incorrect etc), whatever Windows accepts as a subsequent login is re-stored and used to update the pre-boot password. If the SSO Details work, then the user didnt type anything anyway.
So, for a normal windows login, it's usually handled without user intervention anyway so there's no need to "capture" anything - nothing gets typed.
As a second method, ctrl-alt-del etc password changes are trapped and used to update the preboot password any time they are seen on a protected client.
Instead of looking for a different product, maybe upgrading to the current v7 version would be a good first step, to take advantage of the last couple of years of improvements?
V7 is currently in certification and I am looking to roll it out in the next month or so...assuming it fixes this issue. If it doesn't then this issue is probably big enough to delay my rollout and at least consider other options.
My problem is that after users change their passwords, log off, and log back on, they are still initially prompted for the old password the next time they reboot. Because it could be several days between password change and next reboot my service desk is beginning to field a lot phone calls.
The product should not require a failure to trigger a sync. If it can capture the password upon login failure, there is no reason it could not monitor the credential providor for changes. I know that previously with XP the GINA was montiored and both logon events and lock/unlock were able to trigger a password sync.
We also have a problem with some users being repeatedly prompted to register for self recovery on each reboot but that is probably unrelated.
The password sync happens immediately on the local machine, though may take a while to propagate to other machines. If it doesnt happen straight away, it's not going to happen at all (well, until something else triggers it anyway).
The most common reason passwords don't sync is because you set a template in EEPC which is incompatible with what the user is trying to change their password to - even history will cause it to be rejected without notification.
So, turn all the template, history and password quality rules off and let Windows handle it.
All the things which worked "previously" are exactly the same now - nothing changed as far as credential capture is concerned.
We are not using the EEPC password management feature. All rules are handled by AD so that is not the issue.
The question is simply "does EEPC sync passwords on all windows logon events or only when a previous SSO failure has been detected." If its only after a failure has been detected this is a problem for us.
No, it does not sync passwords on all login events - that's never been a feature of the product. It only syncs on change or failure events, which should capture most use cases. The only thing it won't capture is the case where a user sets a different password for the preboot than the one they using in windows - they would have to do this intentionally though.
Password syncing on XP was most definitely more robust than it is with windows 7 as lock/unlock worked flawlessly for us for several years. Now that we are moving to windows 7 this is becomming a major issue.
Synch on change/falure is only useful if a user changes their password via ctl-alt-del or reboots immediately. In our environment where a user may need to sync 10 different systems, changing the password via a universal password management system and then using lock/unlock or logoff/logon is much more reliable than logging into 10 different systems and making changes.
I guess we could talk internally abut forcing a reboot after every password change but I have my doubts as to whether or not that would fly.
Now that I think about it, another concern comes to mind with this issue. We are looking at rolling out vpro/purchasing deep command in the near future so that we could use the "disable preboot when on trusted network" feature. If lock/unlock only syncs on failure or change events, then I can pretty much guarantee that many of our users would end up being several password changes behind if and when they do take their laptop off campus and try to log in. This would force self recovery or, more likely, even more service desk calls.
Are their any plans in the works to add other sync methods? I not we may need to have further talks in regards to Deep Command also.
If you're using a universal password management system, the best thing to do would be to link that with epo and use the eepc.changeuserpassword api - then your universal system will be feeding password changes to EPO.
I'm not sure why you suggest a reboot though - that doesnt really seem to help matters - the password change happens within Windows.
There are not really any other sync events we can use - we only know what the windows password is when it's typed, and we only know about change events when the network provider is called. Since we are trapping both already - what other sync methods do you suggest?
I get that we could sync every single time a user logs into Windows, but think what a huge network burden that would be, replaying all those changes across the network.
There was a reason we didnt use the API when we set this up several years ago but I dont remember what that reason was. I hadn't thought of revisiting that decision. That could be the solution.
As to why a reboot? Because it forces an SSO failure while the user still has their old password in memory and would trigger the sync. What other option do I have if it only syncs on sso failure or change events?
While I haven't completely thought it through, I do not initially see how checking for changes on every login even would be a network burden. You are only checking the local machine. You are not actually checking to see if the AD account is valid, just whether or not the stored username/password combination matches what is in the preboot cache.It would only be propagating changes if an actual "change" was detected and that is the same traffic that would happen in the case of a change event/SSO failure anyway.