We ran into an issue recently that requires a little background before I mention it:
First we resolved to use the "Must match windows user name" option and we use UPN. It seems that in WinXP, even when logging in with UPN, that only the short name (pre-windows 2000) is given to McAfee for SSO upon successful login. So for matching, McAfee appears to strip off the front of the UPN and compare it to the short name. In our environment this does not match due to other naming policies. We tried to start changing short names to match but it caused tons of problems with other apps.
We decided to keep our short names the way they are and uncheck must match user name. This fixed some of the problems but one persisted. On some machines, remnants of LanDesk were installed (we don't use it anymore). Apparently at certain times a LanDesk component would make some sort of authentication call that would mimick a successful login to Windows and reset the SSO details to a LanDesk system user - effectively changing the McAfee user's password to that system account. Note that this would not happen if user matching was enforced, but due to our previous issues we have no choice.
While we solved that problem by finishing the uninstall of LanDesk, I'm a bit worried that whatever function call was used could be used again by another app and lock the user out.
And this leads to another question - What exactly (not just saying "login") causes McAfee to update the SSO details? One issue that I'm concerned about is password expiration. Our passwords are set to expire at a certain interval (in AD) and when that happens we have several options for changing the password.
If the user logs in and their password is expired, they are prompted to change it. At this point they make the change and I believe that mechanism works properly because I tested it. Another method is if the password hasn't expired yet or expires while logged in, the user can ctrl-alt-del and click change password. In this case I'm not sure if the passwords will sync. Also the user can change their AD password through a web page - I'd really think this would cause problems because McAfee will not know about it. Upon next reboot or screen-lock however, they would have to type in their old password first... then their new one at the Windows prompt - THEN they should sync.
1. Is my analysis right? 2. What are some things you all are doing to combat these problems if you use SSO?
UPN stripping was I believed resolved a couple of releases ago - as you say Windows has a bad habit of giving out the short name rather than the UPN to applications.
As to what triggers a store of the SSO creds, it's a failed SSO login - so if the stored creds are blank, or fail, they will be refreshed after the successful login.
ctrl-alt-del password capture is handled by a network provider plugin integrated into the client, so as long as it occurs on a EEPC machine you should find that the EEPC password and SSO details are updated during this event.
If you have a custom web page to do pwd changes, you should consider using the EEM API to tie that change back in so it gets sent to the EEM database for propagation.
I'm not that far off then...that's good! I was worried I was doing something totally wrong.
I will try to research the API a bit and see how hard it is to tie into the password change web page we have. Not all of our users have McAfee EE so we'll have to be able to distinguish (I'm sure that's possible).
I guess my only remaining question is about the failed SSO being the mechanism. My question is what exactly is failing? Is it an authentication request to a domain controller? Does it work the same if they are off network? I know what is supposed to happen, but consider the following odd example:
We have had two users that found themselves in a place where they could log into McAfee and the SSO creds that were passed were accepted by windows. After successfully logging in, they were unable to get to sharepoint (which just uses whatever they logged in with I believe). Unfortunately I can't replicate this problem in order to test it but it's definitely happened twice.
Is it possible that if the windows cached credentials are bad, McAfee logs in too quickly... before the cached creds are checked against a domain controller. In this way maybe it is logging in as if it were offline but then when it tries to access a network resource (sharepoint) it gets denied. And since the login occurs so fast... maybe
The way we got rid of the error was to set the AD password to what the user was using for McAfee.
It seems to be a very odd problem but this is why I wanted to know exactly what needs to "fail" for SSO to recapture. If it's NOT failing because it's still using the cached credentials, I would actually want to make the SSO happen slower.
EEPC captures the creds from Windows - you always log on locally, if though what you type does not work, the local Windows will go try to find a domain controller to validate it - that's how the cached creds work. Windows will also try to update the cached creds from the DC if it sees it around.
The actual SSO login happens just like a user would do it - we literally type the keys into the right boxes and press the button, we just do it at a zillion words a minute.
It will fail if Windows can't validate the creds - they have to fail locally, and on the domain (or the domain has to be unavailable). Windows always tries to validate locally AFAIK first.
You are right though that because it happens so fast, Windows will allow a login with out of date cached creds, where if a real user was doing it, Windows might have had a chat with the DC prior to the user pressing the ok button, and might have already downloaded their new tokens.
In that situation it's quite possible to get logged on with a different password than the domain one, usually then Windows will pop up a bubble telling you to lock your machine and relogin to update the creds.
We don't provide anything to slow this down, though changing the network provider order often helps if you have a bunch of them installed. Everything is working as intended - Windows accepts the creds and allows a login, there was nothing wrong with what SSO punched in.
You can edit sbgina.ini on XP if you like and ''corrupt'' the ok button entry, then we'll punch in the user and pwd, but won't press the ok button for you. That will let you wait a few seconds before you do it manually.
So this could be our problem... except I'm not sure why it would happen after multiple reboots. Somewhere along the line you would think that windows would contact the DC and tell the user they are out of sync.
I'm going to proceed for now and hopefully if it happens again I can do more investigating before we fix it. The only way it should persist for a particular user is if it never contacts the domain controller. I would think that is odd considering the machines were on our network!