Troubleshooting: User Registration and Single Sign-on with Symantec Endpoint Encryption
search cancel

Troubleshooting: User Registration and Single Sign-on with Symantec Endpoint Encryption


Article ID: 163588


Updated On:


Endpoint Encryption Desktop Email Encryption Drive Encryption Encryption Management Server File Share Encryption File Share Encryption Gateway Email Encryption PGP Command Line PGP Key Management Server PGP Key Mgmt Client Access and CLI API PGP SDK


If you have an encrypted system with Symantec Endpoint Encryption, right after reboot, it'll start encrypting the system even without registering users.  In fact, you can install SEE, reboot and leave the system at the Windows Login screen without logging in and the system will start encrypting!

When you reboot the system where SEE has encrypted the entire system, but no users have yet logged in and automatically registered, there will be an automatic user that skips the preboot screen.  Although the system skips the preboot screen, the system is, in fact, encrypted fully.

Once a user is logged in and registers (this all happens behind the scenes), then the user will need to login and the preboot screen will engage.

This entire process all happens behind the scenes and when the user logs in, within 15 minutes the user should be registered and ready to go.

In some rare instances there have been reports where users are unable be automatically registered after Symantec Endpoint Encryption 11.x was installed or Single Sign-On will not automatically login to Windows.  This article will go over how to troubleshoot user registration issues, which can sometimes resolve Single Sign-On issues.

A symptom of this behavior is that a system will automatically reboot to the Windows logon prompt even though the system was encrypted.

In this scenario, there is something that went wrong during the user registration event, however, Administrators have been added to the disk, which will allow encryption to take place on the system.

For information on how to change your password with Symantec Endpoint Encryption 11 and Symantec Encryption Desktop, see the following article:

181178 - Changing Your Windows Password with Symantec Drive Encryption 10.4 or Symantec Endpoint Encryption 11 Single Sign-On

For information on how to Troubleshoot Symantec Encryption Desktop 10 Single Sign-on issues, see the following article:

153490 - Troubleshooting: Symantec Drive Encryption Single Sign-On


In the eedservice log of Techlogs, the following entry may appear:

[ERROR][4156][0x1938][SEDE][SYSTEM][Error when registering user: DE Error : -12368 ]


02/29/16 15:58:38][WARNING][5012][0x105C][SEDE][USERNAME][User Cache is not current][CDEALHelperImpl.cpp:284]

[02/29/16 15:58:38][ERROR][5012][0x105C][SEDE][USERNAME][(SilentEnrollmentTask::Initialize) : Stale User Cache detected. User may not be registered properly.][UserTask.cpp:141]

[02/29/16 15:58:38][ERROR][5012][0x105C][SEDE][USERNAME][(GetLoggedInUser) : GetLoggedInCachedUser() failed Error(-11984)][DERegistrationHelper.cpp:682]



Unable to register users with Symantec Endpoint Encryption  11.x with error: Stale User Cache Detected


*Check if the machine is already encrypted with Bitlocker. 
If the machine has been encrypted with Microsoft Bitlocker Encryption, Drive Encryption cannot start, and subsequently user registration cannot happen automatically.  For more information on this, see the following article:
162094 - Drive Encryption does not start automatically: DE Error -12368

*Check the following registry keys and note what is inside:


If any security software is protecting this entry point, or if a GPO is changing the Network Provider Order, the Endpoint Encryption Password Filter component (eedpasswordfilter) which would handle user registration, may not be inserted properly.

In one scenario, a GPO was changing the Network Provider Order:
Under: Policies\Administrative Templates\Desktop Settings
Change Network Provider Order
ProviderOrder = LanmanWorkstation,RDPNP,WebClient

Missing this eedpasswordfilter value prevents proper user registration.  Disable that GPO setting and adding the eedpasswordfilter item back can resolve this issue.

TIP: Starting with Windows 10, you can now copy/paste a registry location in the address so you do not have to click your way down to the registry keys.

Network Connections

  1. At the Run field (Windows + R), type: control netconnections
  2. Once Network Connections appears, press the Alt key to display the drop-down menu.
  3. Click the Advanced menu and then select Advanced Settings.
  4. Click the Provider Order tab.
  5. Under Network Providers, select the eedPasswordFilter entry, and click the Up arrow to move the SEE connection above any other third-party connections in the list.
  6. Click OK to apply the changes and reboot.

In another scenario, the ProviderOrder value started with a comma (",") (i.e. ",LanManWorkstation,RDPNP,....."). These leading commas can prevent the user from being properly registered. Deleting the leading commas form both locations can resolve the issue.

*Check System Event logs on system Symantec Endpoint Encryption 11.x was installed.  In particular, is there an event being logged which indicates the system has gone down for a reboot?

"The kernel power manager has initiated a shutdown transition"

Installing the Symantec Endpoint Encryption before this security software can allow the proper installation to occur.

*Reboot the Machine again to see if this will allow proper user registration.  In order for proper user registration to occur, it is necessary that a system has had a successful reboot.  If a reboot may have been interrupted, reboot the system again to allow for proper user registration to occur.

*Uninstall and reinstall Symantec Endpoint Encryption may resolve this issue.

*Register the user manually:

eedAdminCli --register-user --disk X -u username-here -p userpassword-here -sso --domain domain-here --au adminusername-here --ap adminpassword-here

Further Troubleshooting
If the above troubleshooting steps does not help, or if other solutions have been tested to work, please contact support.  When contacting support, obtain the following information:

*Backup of the registry of affected systems to provide for analysis

*Information in the ProviderOrder entries above

*Check to make sure the latest version has been installed.  To find out which the current version is, see the following article:

156303 - Symantec Encryption Products Current Version Available

*Review the techlogs to see if this similar event is occurring: eeduserXX.log

For information on Debug Techlogs for Symantec Drive Encryption clients see the following article:
161042 - Enabling Logging and Debug Logging in Endpoint Encryption 11.x


Additional Information

If you have some machines where the user profile has been removed from Windows, the registered account will continue to remain in SEE as a registered user.  This means they will be able to authenticate at the preboot screen successfully, even though their Windows account has been removed.  If they enter the credentials, then the automatic sign-on process will fail and will be left at the Windows login screen to login.  You will see a "PGP SSO" prompt, at which point you will switch users and login with a valid account at the Windows login screen.

Once you login to the user profile, as long as the username and credentials are the same, things should work with the previously-registered user just fine and the user should be able to login.

If you login with any other accounts, they will be registered automatically as previously done. 

If not, you can login as the user, and within 15 minute the passphrase should be synchronized.  Reboot the system to ensure things are good.  If that still isn't working, it may be necessary to delete the registered user, and then go through the process again of logging in, and waiting for the user to be registered automatically.