Troubleshooting Symantec Endpoint Encryption for BitLocker
Article ID: 173846
Updated On:
Products
Issue/Introduction
Symantec Endpoint Encryption (SEE) has multiple Encryption clients that can manage Drive Encryption recovery:
- SEE Native Drive Encryption
- SEE File Vault Encryption
- SEE Bitlocker
Starting with SEE BitLocker (SEE BL) 11.2.0, there are multiple configuration options that can be used including:
- AES encryption Strength 128-256 Bit encryption
- XTS-AES encryption mode
- Trusted Platform Module (TPM)
- TPM and PIN
- Fall back to password if TPM is unavailable for Windows 8 or above
- Decrypt all volumes
Note: General Information on SEE Bitlocker and other topics are available via the Symantec Encryption portal. Searching for keywords will provide additional detail on Symantec Endpoint Encryption.
Symantec Endpoint Encryption Bitlocker General Flow
1. SEE Bitlocker (SEE BL) is installed on a machine.
2. SEE BL will check whether the system is encrypted or not.
If a system is not encrypted, SEE BL will check for connectivity to the Symantec Endpoint Encryption Management Server (SEEMS) and if there is connectivity, will invoke Bitlocker to encrypt the machine. Connectivity must take place within 60 seconds and if no connection is made, SEE Bitlocker will timeout and the system will not encrypt. SEE Bitlocker will then capture the recovery key and machine information and send to the server as part of this operation.
If a system is already encrypted, SEE BL will check for connectivity to the SEEMS and if connectivity happens within 60 seconds, SEE Bitlocker will then capture the recovery key and machine information and send to the server as part of this operation.
3. Once the System has been encrypted, if a user forgets his/her PIN (Or if TPM no longer works, nor if a machine has entered a Lockout state), it is possible for a Helpdesk admin to provide the recovery key to the end user.
PIN VS TPM
As mentioned in the flow above, SEE BL can enforce either PIN authentication or TPM authentication In order for SEE BL to use TPM, the TPM chip must be provisioned and ready for use, otherwise, encryption will not take place (this document describes how to troubleshoot TPM with SEE BL).
Recovery experience
Bitlocker using a PIN requires the end user to enter a numerical PIN at preboot. This PIN is shared among all users on the machine and is not the same as the Windows login. When the PIN is forgotten, the end user contacts Helpdesk to request a recovery PIN. The user enters the recovery PIN at preboot and at this point boots into Windows. Upon logging into Windows, SEE BL will invoke a "reset" operation where a new PIN is established. Once a new PIN is established, the new PIN will then be used at the preboot screen.
If SEE BL has been configured to use only TPM, then when a recovery key is used, the resetting of the TPM occurs in the background.
SEE Bitlocker Lockout
SEE BL can be configured to enforce lockout periods so if a system has not contacted the server within a certain amount of time, the system will enter a "Lockout" period. The system will boot up, and the user will login to the system and upon logging in, SEE will display a notification that the system has been locked out. Upon reboot, the user must enter a recovery key (managed by SEE BL) in order to "unlock" the system. Once a recovery key has been used, and the user logs in to their account, SEE BL will contact the server and will then reset the lockout duration and the system will no longer be locked out.
When SEE BL is deployed to a machine, there are no additional steps to take for the machine to be encrypted. No Group Policy Objects (GPOs) need to be configured, Symantec Endpoint Encryption for Bitlocker will initiate encryption automatically. In some cases, automatic encryption will not start immediately.
Resolution
Troubleshooting
Scenario 1: SEE Bitlocker does not automatically Start Encryption when TPM Chip is not provisioned
The SymBitLockerService00.log can be used to help diagnose some of the encryption issues. In one scenario, where TPM ownership has not been taken, the following errors can appear in the logs:
[12/08/18 15:42:38][DEBUG][5848][0x2F80][SymBitLockerService][SYSTEM][TPM is not Ready][SymBitLockerPolicyApplier.cpp:1062]
[12/08/18 15:42:38][INFO][5848][0x2F80][SymBitLockerService][SYSTEM][TPM is Enabled][SymBitLockerPolicyApplier.cpp:1068]
[12/08/18 15:42:38][INFO][5848][0x2F80][SymBitLockerService][SYSTEM][CheckAuthenticationPolicyCompliance::Got Authentication Type TPM][SymBitLockerPolicyApplier.cpp:687]
[12/08/18 15:42:38][DEBUG][5848][0x2F80][SymBitLockerService][SYSTEM][Key protector type = 1 not found][SymBitLockerPolicyApplier.cpp:155]
[12/08/18 15:42:38][VERBOSE][5848][0x2F80][SymBitLockerService][SYSTEM][CheckEnforceAuthPolicyRequired:: Key protector type = 1][SymBitLockerPolicyApplier.cpp:592]
[12/08/18 15:42:38][DEBUG][5848][0x2F80][SymBitLockerService][SYSTEM][Authentication policy enforcement required][SymBitLockerPolicyApplier.cpp:1139]
...
[12/08/18 15:42:38][ERROR][5848][0x2F80][SymBitLockerService][SYSTEM][AddTPMKeyProtector succeeded with null protector. TPM key Protector not added.][SymBitLockerPolicyApplier.cpp:1585]
[12/08/18 15:42:38][ERROR][5848][0x2F80][SymBitLockerService][SYSTEM][EnableAuthentication::EnableTPMAuthentication failed, Error = 775][SymBitLockerPolicyApplier.cpp:789]
In order to ensure automatic encryption succeeds with SEE BL, ensure the client has connectivity to the SEE Management Server (SEEMS). SEE BL encryption will not start if the Recovery Keys are unable to be sent to the server.
In reference to the errors observed above, we can see TPM issues are taking place. In this case, ensure TPM Ownership has taken place.
To do so, open the TPM.msc snap-in from the start menu, and check the Status. Typically, when TPM ownership has taken place, the status will state "The TPM is ready for use".
It may be necessary to reboot the machine after TPM ownership has taken place, but this is a good check to ensure TPM Ownership has taken place.
There are some other useful Powershell commands to check TPM status that will help indicate TPM ownership has taken place, including the following:
TIP: Run Powershell as Admin to run these commands.
get-tpm
This command will provide some good overall information on the TPM status, including the "TpmReady" option. TpMReady should always be set to "True" in a working system.
An additional command that can help cross reference the TPM status is the following, which will also give the "IsReady" value, which should be set to "True":
powershell.exe -command "(Get-WmiObject -Namespace "root\CIMV2\Security\MicrosoftTpm" -Class Win32_TPM).IsReadyInformation()"
There are some scenarios where pre-provisioning has taken place where a user has never logged in to a machine before. For these types of scenarios SEE Bitlocker can be deployed once TPM ownership has taken place to manage the recovery keys.
To find out the version of TPM that is being used, run the following command:
wmic /namespace:\\root\cimv2\security\microsofttpm path win32_tpm get * /format:textvaluelist.xsl
Scenario 2: SEE Bitlocker clients are not communicating with the SEE Management Server
If this is happening, ensure that the communications URL is properly configured.
Browse to the communications URL for this
Registry Path to validate communications URL:
HKLM\software\encryption anywhere\framework\client database\serverlocation
Open this serverlocation value and make note of the FQDN being used. In this example, it is https://see.domain.dom:443/GECommunicationWS.asmx
Now open this in a browser to see if you are prompted for credentials. If you are prompted, enter the same credentials that were embedded into the client.
Scenario 3: After upgrading to Symantec Endpoint Encryption 11.3.1 from 11.3.0 or previous, the SEE Client no longer communicates.
If you have upgraded to 11.3.1 from 11.3.0 or older versions, please contact Symantec Encryption Support for further troubleshooting if the above items for Scenarios 1 and 2 have already been followed and are properly validated.
References:
https://docs.microsoft.com/en-us/windows/desktop/secprov/setphysicalpresencerequest-win32-tpm
Scenario 4: Corrupted GPOs on systems causing SEE Bitlocker client to not check in.
For more information on this, see the following article:
206408 - Symantec Endpoint Encryption Management Agent crashing on some systems where local GPO is corrupted when using SEE Bitlocker
ISFR-1573, EPG-25286
Scenario 5: Some systems have high CPU, but happens on so few machines overall
There has been a report where some systems are seeing high CPU utilization on only a small amount of systems. When this happens, a reboot fixes the issue, or even restarting the SEE Bitlocker services.
Additionally, some improvements have been including in Symantec Endpoint Encryption for Bitlocker version 11.4.
Due to this issue being so rare and that a reboot fixes the issue typically, the best course of action is to upgrade to 11.4.
If an upgrade is not immediately available, rebooting the system will also fix this issue.
(EPG-26021, EPG-26981).
Fix included in 11.4 HF1 - Release notes here.
Scenario 6: SEE Bitlocker Check In Value for Client Lockout
If you would like to check the registry for the Last Check in Value, you can look in the following location:
HKEY_LOCAL_MACHINE\SOFTWARE\Encryption Anywhere\Framework\Client Database\LastContactTimestamp
This value is in EPOCH time, and you can convert it to what the last check in date was.
Keywords:
Symantec Endpoint Encryption TPM
Encryption not starting
Bitlocker TPM
TPM Bitlocker
Additional Information
ISFR-2262
Feedback
