Symantec Endpoint Encryption Autologon disables at preboot after upgrade or other scenarios
Article ID: 174999
Updated On:
Products
Issue/Introduction
Symantec Endpoint Encryption uses a Preboot Authentication Screen (PBA) such that before a system will even boot, a passphrase must be entered and authenticated successfully. There are some scenarios for when the PBA screen should be skipped, such as when performing Major Windows Feature Updates where an unattended process may be used. Symantec Endpoint Encryption includes Autologon functionality, which means the Preboot Authentication screen will be skipped when a system is booted up. In a scenario such as a Windows Feature Update (requires three reboots), the preboot screen can be skipped allowing the system to be upgraded seamlessly.
There are some scenarios that can disable this autologon functionality and this article will discuss these scenarios.
Tip: See the "Additional Information" section of the article below for links to some of these articles.
Resolution
There were many fixes included in SEE 11.3.1 to address Autologon issues. Although autologon works in most scenarios, for best results, Symantec strongly recommends upgrading to SEE 11.3.1 or above.
Table of Contents
- Scenario 1 - TPM and Autologon - TPM PCR Events
- Scenario 2: Weak Cipher being used with TPM 2.0 systems
- Scenario 3: Upgrading from a TPM-YES SEE Client to a TPM-NO SEE Client
- Scenario 4: GPO Policy downloaded from machine is older than the SEE Client
- Scenario 5: Upgrading from 11.3.0 GA to 11.3.1 MP1 while having no network connectivity to the SEE Management Server
- Scenario 6: Using the incorrect policy for the wrong version
- Scenario 7: Autologon Infinite (Always Autologon)
Scenario 1 - TPM and Autologon - TPM PCR Events
Autologon can use TPM, if you have the TPM feature enabled within the SEE Client for Autologon, you will need to ensure TPM is up and running on the system itself.
If TPM is enabled in the Autologon client, but TPM is not configured for the system, the Autologon will not enable.
In addition to having TPM properly configured for the machine, if you have a "TPM Event", such that the TPM Platform Configuration Register (PCR) is changed, for security reasons, the Autologon functionality will disable. This means that you will see the Preboot screen when you turn the machine on and a passphrase must be entered here.
TPM Events can be triggered if there are any changes to the system related to the following areas:
Firmware/BIOS changes - PCR 0
If the BIOS is ever updated to a newer version, this PCR value can be triggered and cause Autologon to disable until the next reboot when TPM values are re-established.
Hardware changes - PCR 2
If hardware is replaced, such as a video card on a system, Autologon can disable until the next reboot when TPM values are re-established.
Bootloader Changes PCR 4
If the bootloader changes, this can also cause Autologon to disable until the next reboot when the TPM system has been re-established.
In the policy of Symantec Endpoint Encryption, check which PCR values are enabled so that you can anticipate potential behaviors should one of the TPM events be triggered.
(EPG-27007)
Before you go through the various troubleshooting scenarios, first check to make sure TPM is enabled and working on the system.
Open Powershell as administrator and run the following commands:
get-tpm
As you can see above, all values are "True" where this is enabled. This is a UEFI system, and for these systems, only TPM 2.0 will use TPM with Autologon.
If you are using older Legacy BIOS systems, TPM version 1.2 is needed. To find out what version you are using, run "tpm.msc":
As you can see above, "The TPM is ready for use" indicates the TPM is setup properly and should work with Autologon.
Additionally, if you run the following powershell command, check that "IsReady" is affirmative:
powershell.exe -command "(Get-WmiObject -Namespace "root\CIMV2\Security\MicrosoftTpm" -Class Win32_TPM).IsReadyInformation()"
If you have run through the above and it all looks good, proceed to review the scenarios below to see what may be going on with your systems.
Scenario 2: Weak Cipher being used with TPM 2.0 systems
It was discovered that systems that use TPM 2.0 but use the lesser SHA1 algorithm will run into this issue with the "TPM" option configured for Autologon. SHA1 is not considered secure and SEE will therefore stop autologon. In order for Autologon with TPM to be considered valid, the system must use TPM 2.0 and use SHA256.
Solution: If you have systems that exhibit this behavior and uses TPM 2.0 with SHA1, disable the "Use TPM if available" option and create a new SEE Autologon client and the issue should go away. Systems that use SHA256 are fine and should be compatible with this TPM integrity check. This can happen even if using the "Autologon Infinite"
Scenario 3: Upgrading from a TPM-YES SEE Client to a TPM-NO SEE Client
Symantec Endpoint Encryption 11.2 introduced a TPM integrity check feature that disables the Autologon functionality at preboot if TPM has been tampered with as a security measure.
Terminology:
When creating a client with the TPM option checked we will refer to this as a "TPM-YES" Autologon client.
When creating a client with the TPM option unchecked we will refer to this as "TPM-NO" Autologon client.
For example, in the screenshot below, this would be considered a TPM-YES client Autologon client.
If a system has been installed with a TPM-YES Autologon client (with SEE 11.2) , and later is installed with a TPM-NO Autologon client (with SEE 11.3), this can also cause the autologon client to fail.
Note: This issue has only been observed in an upgrade scenario from SEE 11.2 to 11.3. This can happen even if using the "Autologon Infinite"
After upgrading to a version that included this feature, the machine would stop at the Preboot Authentication screen. In scenarios where users have not logged in to register with Symantec Endpoint Encryption, authentication will not be possible.
Solution 1: In order to avoid this issue, upgrade a TPM-YES system with a TPM-YES client and this will avoid the issue.
Solution 2: If systems have already been affected by this issue and were upgraded from TPM-YES to TPM-NO, follow these steps:
Step 1: Run the following command to see the "TPM Usage" status and make note of this on the machine:
eedadmincli.exe --check-autologon --disk 0 --au "admin-username-here" --ap "admin-passphrase-here"
This will display "TPM Usage" and if TPM is enabled, the status will show "Yes".
Step 2: Before the system has been rebooted, move the machine into a policy on the Symantec Endpoint Encryption Management Server (SEEMS) that disables autologon.
Step 3: Click the "check-in" button in the SEE Management client, and then move the machine back into a policy where autologon is enabled, and click check-in again.
This will show the correct status and should avoid the issue.
TIPS
If you're not sure if a machine is using TPM 2.0, the following command can help you understand this (Run as admin):
wmic /namespace:\\root\cimv2\security\microsofttpm path win32_tpm get * /format:textvaluelist.xsl
The "SpecVersion" shows the version of TPM being used. In this example, "2.0, 0, 1.16" is being used, and is thus TPM 2.0.
In order to find out if a system is using SHA1 or SHA256, open the registry and look at the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\IntegrityServices
On the right pane, look for "TPMDigestAlgID" and note the result.
SHA256:
Hex = b
Decimal = 11
SHA1:
Hex = 4
Decimal =4
If going through this article did not help, please contact Symantec Enterprise Support for more information.
Note: If your autologon client was disabled and you forgot to include the TPM option or forgot to disable the TPM option, it was required to uninstall and reinstall the client. If you are on SEE 11.3.1 or above, you can now perform a reinstall of 11.3.1 and the TPM option will be enabled or disabled as expected. Symantec recommends upgrading to 11.3.1 or above for best performance with upgrades.
Scenario 4: GPO Policy downloaded from machine is older than the SEE Client
The following is noted in the Release Notes for version 11.3.1 GA:
*After upgrading, the Autologon GPO policy updates are not synchronized on the client systems: After upgrading the Symantec Endpoint Encryption clients to version 11.3.1, the Autologon GPO policy settings are not applied on the client systems instead they fall back to Autologon install-time policy settings. [EPG-19981]
If you are not using the "Autologon Infinite" installer, this can disable Autologon due to incorrect policy, which may cause a mismatch, which will use local policy.
Solution: To resolve this issue, after upgrading the server ensure that the GPO policy is applied on the client systems and only then upgrade the Symantec Endpoint Encryption clients. Generally the GPO policy is automatically applied on the client systems as per the configured GPO synchronization interval. Therefore, it is recommended that you upgrade the clients after the GPO policy is applied on the client systems.
For example, if you have SEE 11.3.1 MP1 installed on the SEE Management Server, then before the SEE 11.3.1 MP1 client is deployed to systems, make sure the 11.3.1 MP1 policy is downloaded via Group Policy Updates before the client is deployed. If a SEE 11.3.1 MP1 client is installed and gets Group Policy updates for the 11.3.0 Autologon policy, the Autologon could get disabled.
Group Policy updates typically happen every 90 minutes by default, so the likelihood of this happening is fairly low. Note: This issue will no longer be applicable if the GPO is already on 11.3.1 and beyond. This happens only when coming from 11.3.0 and older.
Scenario 5: Upgrading from 11.3.0 GA to 11.3.1 MP1 while having no network connectivity to the SEE Management Server
Autologon could become disabled if you are upgrading from 11.3.0 GA to 11.3.1 MP1 using the Autologon "Admin Only" (aka "noautologon"). The Admin-Only client means that Autologon is disabled by default upon install, until it is enabled either via SEE Client Admin commands, or via Policy. After installation, and before reboot, the SEE Client can check in with the SEE Management server to get this feature enabled right away in most cases.
If you have a SEE Client on version 11.3.0 with Autologon enabled via policy, and then you install the SEE Client 11.3.1 MP1 version that uses the Autologon "Admin Only" option, and while you are doing the upgrade there is no connection back to the SEE Management Server, this could disable the Autologon client until the client checks in with the server. SEE 11.3.1 MP1 included full Autologon functionality in a single installer, which is what causes this, so similar to Scenario 3 above, if you don't have the proper policy, Autologon will disabled and is expected behavior.
Solution: To make sure Autologon remains enabled during an upgrade, ensure the SEE Client has a connection to the SEE Management Server at all times.
Alternatively, if you use the Autologon "Infinite" client, this means the Autologon never disables unless the policy is configured to disable it. Running commands to disable Autologon for the Infinite client is not possible.
Once the upgrade has completed to 11.3.1 MP1, the Autologon client will get enabled again once it checks back in to the SEE Management Server.
Important Note: Once the clients are on 11.3.1 MP1 and Autologon "Admin-Only" client has enabled Autologon policy, this issue will not happen during future upgrades, such as going from 11.3.1 MP1 to 11.4 with no network connection. This happens due to the inclusion of the Autologon client in 11.3.1 whereas previous versions had a separate installer.
Scenario 6: Using the incorrect policy for the wrong version
If you manage Group Policy separately, such as using a third-party tool to manage GPOs, then you will potentially create the GPO Templates on a separate Windows server using a different SEE Management Server, export the template, and then upload to your third-party management tool to manage GPO. If you use this method, there is potential to run into issues if the incorrect version of SEE policy was created. For example, your GPO was created using SEE 11.3.0, but you have deployed the SEE 11.3.1 MP1 client. Because 11.3.1 uses a new Autologon policy, this will revert the policy to "local". If you are not using the "Autologon Infinite" installer, this can disable Autologon.
Solution: If you do use a separate Windows server and different management server to create a GPO Template and then export these settings, make sure you do so with the newer version deployed. For example, if SEE 11.3.1 MP1 client is the version you want to deploy to your endpoints, first make sure you create and apply the GPO to your policy tool so the 11.3.1 MP1 clients do not get the 11.3.0 policy. Upload the new 11.3.1 MP1 Autologon GPO to your policy tool, and once this new GPO has been applied to endpoints, then deploy the SEE 11.3.1 MP1 clients.
Note: This issue will no longer be applicable if the GPO is already on 11.3.1 and beyond. This happens only when coming from 11.3.0 and older.
Scenario 7: Autologon Infinite (Always Autologon)
Autologon Infinite Policy, or "Always Autologon" are enabled in the client and policy, and it does not enable after install
Solution: If you are seeing this, please contact Symantec Enterprise Support for further guidance with the following information so we can review this further:
Item 1: Techlogs (Enable Debug mode via the installer if possible (msiexec /i SEEClientInstall.msi /l*vx c:\SEEInstall.log MALOGLEVEL=debug).
For the path above, specify an appropriate location for the installer log file. The MALOGLEVEL parameter will put the SEE Client into debug mode during install. For more information on debug, see the following article:
161042 - Enabling Logging and Debug Logging in Endpoint Encryption 11.x
Item 2: Full SymDiag Dump. See the following article for information on SymDiag:
155115 - Download SymDiag to detect product issues
Item 3: Full Registry dump of the system while the system is in the broken state.
Item 4: Event Logs
Item 5: Installation File for the failed install of 11.3.1
By default, the installer log is in %tmp% and has a randomized name of SEE*****. To force a filename, you ca use the following command:
msiexec /i SEEClientInstall.msi /l*vx c:\SEEInstall.log MALOGLEVEL=debug
Item 6: Attempt to run the "check-autologon" command to see if Autologon appears to be in Windows, but not at preboot and note the output.
This scenario is extremely rare and may happen only 1 out of thousands of deployments, if at all.
Contact Symantec Support with the above information (Reference EPG-25292).
Additional Information
Feedback
