I just deployed EEPC 5.23 in the testing environment. EEM and EEPC installed perfectly without any error. AD has been synchronize with the user database. I deployed the EEPC agent to my Windows XP and it run successfully.
But I do have a problem with SSO. It seems does not works. I've tick the option "attempt automatic windows logon" but windows login screen still apear.
EE username&password is exactly the same with AD username&password.
Is this possible because some kind of bug? or do I skip any configuration to enable SSO.
Other than deploying in Windows XP. I also tried to deployed in Windows 7 with different EEM installation but SSO funtion still not running.
I do really appreciate any kind of help.
What GINA are you using? I don't see anyone else reporting this kind of problem. Are you using UPN's or SAM account names?
Tick ALL the Windows Login options to start with to prove things work - some are interrelated.Message was edited by: SafeBoot on 2/23/10 9:05:17 AM GMT-05:00
How do actually I know which GINA that I am using? I am suing SAM account name. I tried to used UPN as well, but it still does not work.
is there any specific configuration to enable SSO?
look in the winlogon key of the registry I guess?
As to how to make it work, just tick all the Windows Logon boxes until you decide which exactly to use.
from the registry, it shows that I am using GinaDLL that stored in C:\Program Files\McAfee\Endpoint Encryption for PC\SBGINA.DLL..
OK, I ticked all the option and the SSO process go through. finally, I ticked only "Attempt automatic Windows Logon", "Automatically logon as pre-boot user", "Set Endpoint Encryption Password to Windows Password"..
I realize that the option "Automatically logon as pre-boot user" that makes the SSO working. But shouldnt the EEPC stored Windows credentials for SSO login already? Thus, It does not have to use EE credentials. CMIIW
I have deployed EEPC 5.2.3 in the production environment and SSO works. The problem you're facing may be due to you GINA or other strings (check wireless drivers) in WinLogon that may force an interactive logon process. In our case, we had a legal notice string, that prompted the user to press Ctrl+Alt+del (irrespective of SSO being enabled). Once we removed the string, SSO worked without any problem.