Important Note
Feature Deprecation
On July 6, 2018 WinMagic customers and partners were notified that the SecureDoc pre-boot authentication feature for macOS – known as SecureDoc On Top (SDOT) for FileVault 2 – would be deprecated in SecureDoc 8.2 SR1. As of this release, customers will no longer see this feature available for macOS configuration settings.
Please visit Knowledge Base Article 1760 for more information.
Before Upgrading
Prior to upgrading from v8.2SR1 to v8.2SR2 or later versions, please refer to KB article KB000001727 to follow the steps to ensure your client machine has Win7 with KB3033929. For more information on this limitation please see previous release note v8.2SR1 http://downloads.winmagic.info/manuals/Release_Notes_8.2SR1.pdf
IMPORTANT:
After upgrading SES to V8.6 and BEFORE starting SDConnex, customers that use ADSync MUST start and run a Full Sync using ADSync's Full Sync option, BEFORE starting SDConnex. This is required due to changes in how User information that is retrieved from Active Directory is stored in the SES Database. By performing a full sync immediately, it will ensure that existing AD User Records are updated efficiently before those records can become locked or busy due to SDConnex activity.
For those customers with huge Active Directories, the ideal upgrade planning would include planning to upgrade SES during a period of relatively low user activity (e.g. a weekend or holiday) in order to permit ADSync the maximum possible time to complete the update.
IMPORTANT:
Customers who have configured their Domain NETBIOS name to be different from their AD Domain name prefix should not upgrade to V8.6 or V8.6HF1 until we have a resolution for domain name resolution issues encountered with this configuration.
Details/example: Where Domain Name Prefix (e.g. a1trucks.america.local prefix is a1trucks) is different from the NETBIOS name (e.g. trucksamerica), the user information provided to SecureDoc by the windows client is based on the NETBIOS name (e.g. trucksamerica\johndoe). This can cause issues due to the SecureDoc database having synchronized the user from AD using the Domain Name Prefix “a1trucks”. These issues can include the creation of duplicate user records, as well as the failure to synchronize the users password or correctly cache the user’s credentials on the device.
If your Domain ID and NETBIOS name differ in this way, you are recommended to remain on SecureDoc 8.5 SR2 or earlier until WinMagic has resolved this issue. If your prefix and NETBIOS name match (e.g. a1trucks.america.local and NetBIOS name a1trucks), then this advisory is not applicable to your environment.
Important Feature Change:
The SecureDoc Profile settings for Number of Failed Logins at Windows has been decoupled from failed authentication attempts at Pre-Boot. These have been split into two settings. Customers should verify all Profiles after updating to V8.6 before deploying Profile changes to endpoint devices
Permanent Auto-Boot has a security feature that will protect the device against excessive failed login attempts at Windows logon. In previous versions, this setting was tied to the number of failed login attempts for BitLocker, but in this version the two configurations have been separated into distinct UI configuration elements so they can be treated/configured as separate.
For any profiles using Permanent Auto-Boot, please set the desired threshold for failed login attempts at Windows using the Profile's General Panel option entitled: "Protect Device against repeated failed login attempts at Windows Logon"
The existing Pre-Boot focused protection for failed logins at Pre-Boot remains in place, but is now focused SOLELY on authentication at Pre-Boot, rather than having a blended functionality that many customers found confusing.
Please verify that each of these settings has the desired threshold setting to ensure that your client deployments (and updated Profiles) continue to provide the desired stringency/protection against failed authentication attempts. It is possible that the values in the profile will have changed after upgrading to SecureDoc 8.6.
SecureDoc Support
WinMagic strongly recommends that you install the most recent software release to stay up-to-date with the latest functional improvements, stability fixes, security enhancements and new features.
Please visit Knowledge Base Article 1397 for more information on End of Life and End of Support timelines for SecureDoc software releases.
Customers running SecureDoc 6.5 and earlier should upgrade their server and clients to an actively supported software version. For more information on upgrading from SecureDoc 6.5 and earlier, please visit http://downloads.winmagic.info/SD8.2SR1/HF2/Release_Notes_8.2SR1HF2.pdf.
About This Release
This document contains important information about the current release. We strongly recommend that you read the entire document.
Recommended – WinMagic recommends this service release for all environments. Apply this update at your earliest convenience.
Previous Versions
|
8.5 |
December 5th 2019 |
New features, improvements and fixes (server/client) |
|
8.5 SR1 |
April 8th 2019 |
New features, improvements and fixes (server/client) |
|
8.5 SR2 |
June 11th 2019 |
New features, improvements and fixes (server/client) |
Download the latest release notes for each version listed within Knowledge Base Article 1756.
System Requirements
For server and client system requirements: https://winmagic.com/support/technical-specifications
For supported devices, drives, smartcards and tokens: https://winmagic.com/device-compatibility
Note: It is strongly recommended to initially install Full-Text Indexing feature (Full-Text Search) into the Database Engine, before performing an SES installation.
More information is available here: http://msdn.microsoft.com/en-us/library/ms143786(v=sql.100).ASPX
During the installation of SES, if Full-Text Indexing has not been installed, a message will appear indicating the absence of the Full-Text Indexing. This message will not allow the user to stop the installation of SES which will require retrofitting Full-Text Indexing into an existing SQL Server.
Note: Use of the SES Console will require the user to have at least local admin rights on the server or client device (e.g. Admin desktop) on which it runs, in order for the console to function properly
Client OS Support
This section shows supported operating systems and upgrade paths for SecureDoc Endpoint Clients.
Microsoft Windows
|
10 RS9 [2009] |
Enterprise Pro |
32/64-bit |
8.2SR1+ |
|
8.1 |
Enterprise Pro |
32/64-bit |
All versions |
|
7 |
Enterprise Pro |
32/64-bit |
All versions |
| Version | ||
|
Catalina |
10.15.X |
SDFV2 8.5+ |
|
Mojave |
10.14.X |
SDFV2 8.3+ |
|
High Sierra |
10.13.X |
SDFV2 8.2+ |
|
Sierra |
10.12.X |
SDFV2 7.1 SR6+ |
|
El Capitan |
10.11.X |
SD 7.1 SR2+ |
The KnownConfigs.XML File
Customers are strongly advised to download the most current KnownConfigs.XML file, then replace the current version (if older) in the SES Application folders and Installation Packages.
WinMagic strongly recommends that you seek out the most up-to-date version of the KnownConfigs.XML file and incorporate it into your SES implementation on a regular basis (e.g. monthly). This will help ensure your SES Version will take advantage of new client installation override settings that have been added since the version of the KnownConfigs.XML file that came with your version of SES. This will improve installation success on any new device makes/models you might purchase since installing SES, utilizing the new special settings available in newer versions of this file. Customers are advised to look to the SecureDoc Knowledge Base for a link to the available KnownConfigs.XML files, then check that document (e.g. on a monthly basis) for updates to this file, then use the new version to replace all versions of the KnownConfigs.XML file in their SES Implementation folder structure. For example:
1. Position Windows Explorer to: c:\Program Files(x8)\WinMagic\SDDB-NT, then
2. Search for files like *.xml.
3. Sort the resulting search list by name
4. In each directory where a KnownConfigs.XML file is found, replace it with the new one that you have downloaded from the WinMagic Knowledge Base article. Additional information can be found here: Installing or updating the KnownConfigs.xml file (Applies to SES from Version 7.5 onward).
The latest versions of the KnownConfigs.XML files can be found at the following links:
- SecureDoc Device KnownConfigs.XML File for SES V8.2 And Later- Download the
latest version of this here: https://na80.salesforce.com/articles/Service/SecureDoc-Device-KnownConfigs-XML-File-for-SES-V8-2-Download-the-latest-version-of-this-here
- SecureDoc Device KnownConfigs.XML File for SES V7.5 - Download the latest
version of this here: https://na80.salesforce.com/articles/Service/SecureDoc-Device-KnownConfigs-XML-File-for-SES-V7-5-Download-the-latest-version-of-this-here
The contents of the KnownConfigs.XML file are reserved to be developed and advanced by WinMagic solely. While customers might consider enhancing it, WinMagic cannot be held responsible for issues that might arise from such modifications and may (at its sole discretion) levy an additional support charge to any customers that encounter support issues that can be traced back non-sanctioned customer-initiated changes to KnownConfigs.XML. W WinMagic welcomes customer ideas and suggestions on how KnownConfigs.XML can be extended and improved, but WinMagic reserves the sole right to test, approve and to publish any changes to KnownConfigs.XML that it deems to be in the broader customer interest, and makes no commitment to act upon or publish all, or indeed any customer-recommended changes.
8.6 HotFix 1
SD-36596: Issue detected when using long domain names when installing older versions of the SecureDoc client against SES 8.6
Scenario: Installing older SecureDoc Clients using an AD-derived user account with a long domain name against an SES server environment that had been upgraded to V8.6
Issue: Where in the pre-8.6 version of SES the AD Users had been synchronized to SES, during the client software installation using the pre-8.6 SecureDoc client installation package, SES will not able to correctly identify the deploying user. As a result of this, either one of the following two issues could occur (depending on the specific set of configurations that were chosen in SES):
- Submitting SDform would fail, blocking successful installation of the SecureDoc client software. Possible error messages that can appear upon submitting SDform are: "Error 0x7810 A user with this name already exists in the database" or "User cannot be found."
- Registration will go through, however, the device will not properly be linked to the existing AD user (the deploying user) and an additional user record will be created in SES and that user record will be linked to the device.
Solution: This issue has been corrected in SES 8.6 HF1, and customers may now install SecureDoc using pre-8.6 client installers against a 8.6 HF1-version Database without any issues or errors.
SD-36727: Issue prevented users from authenticating to SecureDoc-protected devices using longer forms of AD credentials (e.g. user@domain, or user@domain.com or domain\user format)
Issue: In SecureDoc 8.6 it was found that the SDConnex Service was unable to validate AD user credentials when those credentials were not in simple user id format (e.g. "user@domain" ).
When a user attempted to authenticate using AD credentials in longer formats, SecureDoc would issue an incorrect username/password error, and the SDConnex eventlog would show a string of errors related to the following initial error message:
ActiveDirectoryService::GetDNSDomainName error.
Exception in ActiveDirectoryService::ValidateCredentials While Validating user against AD server.
Solution: This issue was corrected in version 8.6 HF1. All user name formats are supported - short (e.g. user), short- domain (user@domain), long domain (user@domain.com) and domain\user formats.
|
NOTE: The remaining items were covered in the V8.6 Release Notes and are repeated below for convenience. |
New Features & Improvements
SD-19186: Change device Owner after device has been deployed
A new option has been added that permits changing a Device's owner to a new user account, after deployment has completed and an initial owner has been assigned. The option to “Set Device Owner” is now available in the SES and SES Web console. When selected, the selected user will be replaced as the device owner, and will be reflected as such in the list of users assigned to the device.
SD-23248: Improved User Identification Creation across Multi domain and Local workstations
SecureDoc now supports device authentication and SDCC login using several alternate User ID formats, including UPN, and variations of Domain\SAM Account name.
This change is one visible aspect of on overall design improvement to fully support multi-domain environments. This design improvement will provide many benefits for multi-domain environments, including where there had always existed a risk of same-named users in two different domains being confused under the original SecureDoc short-name User ID, as well as customers who are migrating over to use UPN (typically along with an Office365 implementation).
This will further permit use of alternate Display Names for Key files, as well as alternate-form authentication at Boot Logon, SecureDoc Control Center (SDCC), and other login credential dialogs using all supported formats, i.e. SAM account Name, UPN, and domain\user.
SD-26577: Allow users to un-install SecureDoc for SDLinux from the system
New functionality has been added that permits first decrypting then uninstalling SecureDoc from Linux client devices. This operation can be performed either before encryption has started, or after encryption has completed. It cannot be performed during the encryption process.
The process is as follows:
- Run the installer to start decryption:
/usr/local/WinMagic/secdco.py uninstall [-s]
This will disable the SecureDoc service (to prevent re-encryption) and mark the system for decryption
- The system will restart and offline decryption will commence
- Once decryption is finished , the system will boot normally , since the service is disabled, the “check user” dialog will timeout , this is normal.
- Run the uninstall command again:
/usr/local/WinMagic/secdoc.py uninstall [-s]
to remove SecureDoc files; an uninstallation log will be saved to /var/log/secdoc.log
- The uninstall will not reboot at this time but it is recommended to do so for the kernel to re-read the partition information (since the SecureDoc SDSpace has been deleted)
Note that changes to incorporate the extra partition, or changes to the SWAP partition will be retained on the uninstalled drive, but the SecureDoc encrypted credential data (SDSpace) will be removed from the system
SD-28366: Additional support for SDLinux to Communicate with the SES Server
SDLinux for physical Linux Servers now includes substantial improvements, including a means to force communication to the SDConnex Server and changing the Server address(es).
Usage:
secdoc-cli.py [-h] [ -s server-list] [-c]
Without any options the command will display the list of every SecureDoc-managed volume and its encryption percentage, as well as showing the date/time of the last service communication with an SDConnex server
The options are :
-c connect/communicate with the server ( within 5 seconds )
-h displays the usage help
-s <server list separated by ;> in case one or more SDConnex Servers have moved, been renamed or changed IP address. The Server list can contain IP Addresses and/or DNS Names.
NOTE: When specifying SDConnex Servers using the -s clause above, the address list provided will become the new "default" list of IP addresses/DNS Names to be communicated with. Care must be taken to ensure the list provides legitimate SDConnex Server IP Addresses and/or DNS names, as use of a list of servers that are not running SDConnex could potentially lead to a client that cannot communicate to SES.
SD-29984: Improve the SDLinux Setup, Install and Uninstall process
This Issue refers to several improvements in the SecureDoc Client for Linux.
SecureDoc for Linux now supports decryption from client (offline supported only) which then permits the Client to be uninstalled. This item is covered in more detail in its own Release note entry - see "SD-26577: Allow users to un-install SecureDoc for SDLinux from the system."
SDLinux now offers functionality to create an offline installer with all Linux kernels for Ubuntu client devices. This solution utilizes a downloaded library containing all Ubuntu drivers, and the resulting SDLinux package can be configured to use the downloaded drivers. Please review the SDLinux documentation for instructions on how to create this installer.
SD-31432: SDLinux now supports SUSE Linux 15 and 15.1
With this version, SUSE Linux has been added as a supported Linux distribution for encryption and management by SecureDoc. Versions of SUSE Linux supported are 15 and 15.1.
SD-30375: SES Web console security has been improved
A number of improvements have been applied to further strengthen the SES Web console.
SD-31273: Improve SecureDoc installation to support OEM devices where BlockSID is in effect
Previous implementations of SecureDoc interface with the BlockSID feature by messaging the customer about the presence of BlockSID - in the event that it is active in the BIOS of their device during SecureDoc installation. This messaging prompted the user to then navigate to the BIOS to change their BIOS settings to Disable BlockSID so that SecureDoc can then resume the install process.
This process has been improved in this version. If:
- The device's Self-Encrypting Drive supports BlockSID AND
- The BIOS sends a BlockSID AND
- The BIOS supports the Physical Presence Interface for BlockSID
Then SecureDoc now has a means to smoothly continue the installation. The "Physical Presence Interface" for BlockSID has been integrated so that SecureDoc installations can proceed on a broad range of OEM devices should they have the "Physical Presence Interface" feature set.
Upon installing SecureDoc's Boot Logon on TCG OPAL drives, if the installation failed due to BlockSID being enabled in the BIOS, it will trigger the Physical Presence Interface action - disabling BlockSID in the BIOS (this change being activated upon the next machine boot-up). The user will see a pop-up message indicating this change has been made and that a reboot is required. This message is: "A configuration change is requested to disable issuing a Block SID authentication command on subsequent boots. Device reboot is required!"
Following the device boot-up, the BIOS will confirm this action with input from the physically present user. This confirmation involves the entry of a one-time confirmation code presented on the screen. When SecureDoc initial deployment resumes, it will successfully proceed with placing the TCG Opal drive in a managed state..
NOTE: Since BlockSID is a new feature, it may not be fully or correctly implemented by all BIOS vendors, therefore the behavior on various endpoint makes/models might be different. If issues arise, the recommendation is to check with the OEM for an updated BIOS for the affected device.
SD-31956, SD-32123: Add/Improve SESWeb ability to create and manage Installation Packages for specific client types/platforms
SESWeb has been improved to permit Administrators to create and modify:
- Windows CloudVM Devices
- Linux CloudVM Devices
- Linux Devices
- OSA Devices
- macOS Devices
NOTE: Editing of Windows profiles and installation packages is reserved for a future release.
SD-35209: Support macOS 11 (Big Sur)
SecureDoc 8.6 has added support for macOS 11, code named Big Sur. Please see additional release notes for details on changes with this new client.
SD-32202: Improve installation process through integrated and automatic "learning" about device specifics (where the device type is not found in KnownConfigs.XML), and store what is learned to improve the local deployments
Objective: To increase the number of successful SecureDoc client installations, particularly in environments having substantial variability in endpoint device make/model and BIOS/UEFI settings.
Solution: This version introduces further improvements into the process of "learning" about the specifics of endpoint devices, and more importantly to bring the information back into the SES environment.
As each device is installed using the SecureDoc Installer, if configured in the Profile, the SES Client installer will:
- Download a file from the server called CustomerConfigs.xml (which is parsed before the local KnownConfigs.XML file) with the most recent learned configurations from the Server
- Determine if the device type is found in the CustomerConfigs or KnownConfigs.XML file
- If yes, the installer will use the settings from the XML file to guide its installation
- If no, the installer will automatically place itself into a mode where it will try different settings until it has determined what settings the device in question needs, and will return those settings to update the learned configurations stored on the server for that make/model combination
For customers, this means that, in the ideal implementation scenario, it is recommended to:
- Gather examples of each device make/model to test early in the installation process
- Ensure that each device is able to connect to the SES Server during installation in order for the settings that are determined during this "learning" phase to be updated
In this way, the success rate during installation on similar make/model combinations will be problem-free due to improvements to the learned configuration being applied.
SD-32406: New functionality permits removal of Keyboards, Mice and other Human Interface Devices (HID) from Port Control, as well as adding functionality to block a specific port, and to block the port for a period of time
In previous versions, under Port Control settings, Keyboards, Mice, and HID devices were added automatically to the Port Control "white list" of devices, but could not be removed from this list.
In this version, new functionality permits defining that such devices can be removed from the Port Control "white list" at will. As well, specific ports can be blocked indefinitely or for a period of time. Lastly, devices can be sent a command that will permit them to re-query the list of connected devices and permit otherwise blocked devices to be used (typically for diagnosing or repairing devices that normally run with an extremely limited set of port-connected devices in their defined functions) such as IOT/Kiosk Devices.
SD-32893: SES Web console can now create and edit Apple macOS client profiles
As SES Web works its way toward feature parity with SES Console, Version 8.6 of SES now offers the ability to create and modify Apple macOS Client profiles
SD-32894: SES Web console can now create and edit Windows CloudVM client profiles
As SES Web works its way toward feature parity with SES Console, the addition in this version of the Windows Enterprise Client type is a major step forward.
NOTE: There are some aspects of this Profile type that are not yet present in SES Web. These are:
- The ability to define SDConnex Groups (this will affect customers having multiple SDConnex servers) Work-around: Open the Profile in the SES console and define SDConnex Group Numbers
- The ability to create or manage list of acceptable USB devices in Port Control
Work-around: Update the Profile using SES Console's Port Control functionality (this function is, although included, irrelevant in the context of CloudVM since CloudVM cannot utilize USB devices) - The ability to create or manage lists of Trusted Devices
Work-around: Update the Profile using the SES Console's Trusted Devices functionality. (this function is, although included, irrelevant in the context of CloudVM since CloudVM cannot utilize USB devices).
SD-33090: SES Web console can now create and modify OSA Client Installation package information
As SES Web moves toward feature parity with the SES Console, Version 8.6 of SES now offers the ability to create and modify OSA Client Installation packages
SD-33091: SES Web console can create and modify Apple macOS Client Installation package information
As SES Web moves toward feature parity with the SES Console, Version 8.6 of SES now offers the ability to create and modify Apple macOS Client Installation packages.
SD-33167: SES Web console can now create and modify Windows CloudVM Installation package information
As SES Web moves toward feature parity with the SES Console, Version 8.6 of SES now offers the ability to create and modify Windows CloudVM Client Installation packages
SD-34071: SES Web console can now create and modify Linux client Installation Packages
As SES Web works its way toward feature parity with SES Console, Version 8.6 of SES now offers the ability to create and modify SDLinux Client Installation packages
SD-33167: SES Web console can now create and modify Windows CloudVM Installation package information
As SES Web moves toward feature parity with the SES Console, Version 8.6 of SES now offers the ability to create and modify Windows CloudVM Client Installation packages
SD-34594: Ability to create and edit SES Global Settings has been added to SESWeb
As SESWeb works its way toward feature parity with SES Console, the addition in this version of the means to define and update SES Global Settings is a major step forward.
SD-29372: Improve OSA Upgrade Procedure
This is related to SD-33405, wheren the OSA upgrade procedure for systems upgrading OSA has been improved to includude multiple disk scenarios
SD-33518: Due to Apple's change in macOS 11 (Big Sur) and onward, Kernel Programming Interfaces (KPI's) have been deprecated
WinMagic is working to ensure that all macOS aspects of its SecureDoc products conform to this new development/operational paradigm, and this version contains major progress to this new methodology.
The result of this change is that macOS no longer allows kernel extensions to be installed by third party developers. This means that there are changes required to the existing Removable Media capability to automatically mount an encrypted container as a drive. Going forward, an RMCE Manager has been implemented, in order to allow for access to the encrypted container on removable media. Refer to the macOS SecureDoc client manual for details on how to use this new functionality.
SD-34112, SD-34164: The SecureDoc Client for macOS no longer supports Sector Based Removable Media Encryption, replacing it with Removable Media Container Encryption
Due to changes in macOS arising from macOS 11 (Big Sur), macOS 11 no longer supports 3rd party Kernel Extensions (KEXTs). SecureDoc used a kernel extension to support sector based Removable Media Encryption functionality. Due to the design change by Apple, SecureDoc can no longer support sector based removable media encryption starting with macOS 11 (Big Sur).
SecureDoc has previously supported and will continue to support Removable Media Container Encryption on the macOS platform without the need for KEXTs, so customers will be able to continue protecting Removable Media using RMCE. Going forward, an RMCE Manager has been implemented, in order to allow for access to the encrypted container on removable media. Refer to the macOS SecureDoc client manual for details on how to use this new functionality.
SD-34344: SecureDoc does not support multiple active instances of the SecureDoc application, therefore Switching users on macOS endpoint devices is not supported. Attempting to switch users will yield a warning message "SecureDoc for FileVault 2: SecureDoc is already running. Only one instance of SecureDoc can run at any time. This instance will be halted"; after which the second instance will be terminated
SecureDoc for macOS FileVault 2 can only run a single active instance. Where an attempt is made to switch user (fast switching by retaining the first user as logged in) it will trigger an attempt to launch a second instance of SecureDoc. The new user logging in will encounter a message indicating that SecureDoc is already running (from the previous user's login process), and that the new instance of SecureDoc will terminate.
Customers that encounter this message are requested to confirm the message by clicking OK, after which they should log out, switch back to the first user, and log out of the first user before logging back in as the second user.
SD-34235: BlackArmor-protected external self-encrypting drive support has been removed in SecureDoc 8.6
In the interest of ensuring that SecureDoc supports only current-technology equipment, SecureDoc 8.6 has removed legacy support for BlackArmor external self-encrypting devices. These SED devices have not been actively marketed by Seagate for several years and the technology is incompatible with the latest SED standards.
SD-33232: SecureDoc On Screen Keyboard behavior at Pre-Boot has been improved
Issue: Where using touch-panel type devices, when PBLU is enabled on a device where touch panel support is enabled, the On-Screen Keyboard appears by default, largely covering the lower half of the display, blocking users from seeing error messages or Challenge-Response text, whereas PBU devices do not display the on-screen keyboard until the user requests it by clicking the Keyboard icon.
Aside from the difference in default behavior between PBU and PBLU, customers found needing to click keyboard icon to minimize the defaulted on-screen keyboard to see messages was bothersome.
Solution: Now in both PBU and PBLU pre-boot environments, a profile setting will determine if the device initially displays the on-screen keyboard, or if the on-screen keyboard is hidden by default.
This behavior is configured in the profile by enabling/checking a new option in the Boot Configuration Settings: Keyboard Layout panel, entitled: Where an On-Screen Keyboard applies, it will begin minimized at Pre-Boot.
SD-34401: A new remote command has been added to the Device view in the SES Console and SES Web console, that permits the Administrator to send a command to lock all the Key Files on one or more devices, ensuring that no user can log on to the devices using regular Pre-Boot Authentication
An option has been created to permit locking devices without the complexity or finality of Crypto-Erase (which can be irrecoverable if using Self-Encrypting Drives). This command can be applied both:
- When the device is at Windows, or
- When the device is at Pre-Boot if the device is able to connect to an SDConnex server
Upon receipt of this remote command, the endpoint device will reboot itself, bypassing the Pre-Boot Authentication Logon screen and placing the user in the Recovery panel, permitting only Challenge Response recovery.
NOTE: Since the device bypasses the Pre-Boot Login screen, the device cannot be authenticated-to using PBConnex Network-brokered authentication, nor PBConnex Auto-boot to the Operating System.
This new option is suitable if a client device is lost or stolen - all access to the data in the device is blocked. However, if the device were to be recovered, it can be accessed through regular Challenge-Response recovery.
SD-34051: SecureDoc File Encryption SFE now contains the most recent file-level encryption drivers.
SecureDoc SFE has been upgraded to utilize the most current-available third-party File Encryption library elements.
SD-33815: SecureDoc for Linux now supports LUKS (Linux Unified Key Setup) volume encryption on Linux devices
With this version, SecureDoc for Linux supports LUKS-encrypted drives, including management of existing LUKS-encrypted volumes on Linux devices.
SD-34347: SecureDoc now supports Ubuntu Linux 20.04 and 20.04.1
Official support has been added in SecureDoc 8.6 for Ubuntu Linux versions 20.04 and 20.04.1
SD-33405: SecureDoc OSA Clients will now detect and protect all available Opal Self-Encrypting Drives (SEDs) added after initial installation
Issue: In previous versions, the SecureDoc OSA client will detect all available Opal drives during the initial installation and will successfully manage and protect those drives. However, after initial installation had completed, any newly-attached Opal SEDs would not be detected and protected.
Solution: In this version, the OSA client will poll all attached Opal SEDs, broadening compliance support by ensuring that all newly added Opal drives are detected and managed by SecureDoc.
By default the feature is disabled. In order to enable this feature, modify the following OSA profile setting:
Profile section name: "SDSpace"
Profile setting key name: "OSA_CONFIG"
Profile setting value: 0 or 1
Example 1 (where the feature is enabled):
[SDSpace]
OSA_CONFIG=1
Example 2 (where the feature is disabled):
[SDSpace]
OSA_CONFIG=0
When looking at migrated profiles, the setting "OSA_CONFIG=0" may be omitted. If the setting is not present, the default behavior is that this feature is disabled. Manually edit the profile using the SES console to add this setting.
OSA Supports the following SED types:
* TCG OPAL
* TCG Ruby (usually SMBR-less)
* TCG Enterprise (SMBR-less)
Supported logical sector size: 512 byte sector only (in current implementation).
SD-35312: Deprecated options have been removed from the SDConnex Configuration panel
With the improvements to the user records implemented in SecureDoc 8.6, the SDConnex options “Allow-reuse of existing user IDs” and “Allow update of information for existing users” are no longer used, and have been removed from the SDConnex Configuration user interface.
SD-34788: A new option has been added to the Profile's Boot Configuration General Panel that defines a specified number of failed Pre-Boot Linux for UEFI (PBLU) load attempts before SecureDoc Pre-Boot automatically switches from PBLU to Pre-Boot for Native UEFI (PBU) on a permanent basis
Per an earlier issue (SD-32395 applied in V8.5) it was determined that certain customers would encounter issues booting into PBLU. These issues could arise from incompatibilities with PBLU environment and the device hardware, or disk modes such as software RAID which would prevent PBLU from loading properly. In previous versions of SecureDoc, if PBLU failed to load after a fixed value of 3 attempts, the device would permanently revert to using PBU as a failsafe method.
The addition of this option improves on this failsafe behavior by offering a GUI option that permits the SES Admin to define a configurable number of Pre-Boot load attempts under PBLU, which permits technicians a number of reboot attempts during which they can resolve any issues with compatibility before the device would switch permanently to PBU mode, after which it would require the additional steps of having a user with Admin rights logging in to SDCC to switch it back and then updates boot logon to reinstate PBLU-based Pre-Boot.
SD-29703: It is now possible to override Disk Access Control (DAC) profile-based settings through use of DAC exception settings at the User level
Normally, when using Disk Access Control, it is necessary to log into the SecureDoc Control Center application in order to change the DAC "Profile", for example to change from "Read Only, Unless Encrypted" to "No Restrictions". This change requires elevated user rights that could be used to inadvertently alter other settings, as well as requires multiple clicks through various screens. In addition, it applies to the system, including if the admin user logs off and a standard user logs on.
To improve the scenario where the desire is to provide group based exemption to Disk Access Control policies, as well as provide this at a user level, not the system level, a new privilege has been added to the user and group properties. This override permits a User to be granted Disk Access Control override, such that the user is not bound by the DAC settings on the device provided by the device's Profile. This override can be applied by changing the Privileges at any of the following levels:
- At the User record-level
- At the User/Device record-level
- At the Group level
- In Global Settings (NOT RECOMMENDED, as use of this option in the Global settings will disable DAC for all users either imported from Active Directory or created ad-hoc by the SES Administrator).
Since the set of controls for Privileges is used in various contexts throughout the product, this option will be inaccessible in the Global settings context in a future version of the product.
SD-35466: The device Serial Number is now visible when using the F3 function key in the SecureDoc Pre-Boot environment
A request was made to provide more information about the specific device when accessing the F3 screen at Pre-Boot authentication. Per this request, the serial number for the device has now been added to the information shown on the F3 screen.
SD-33352: Automated functionality to rotate the SecureDoc FileVault 2 Recovery Account password on all SecureDoc-protected Apple macOS devices running SecureDoc for FileVault 2
Functionality has been included in the SecureDoc for macOS client to automatically rotate the winmagic recovery account password on a scheduled basis.
By default, this process will run every 30 days, and will automatically cause all FileVault 2 Recovery Account Passwords to be rotated on SecureDoc-protected Apple macOS devices running SecureDoc for FileVault 2. However, this option is also now configurable, and can be set between a minimum of 1 to a maximum of 365 days. This option is available in the profile via both SES and SES web consoles.
SD-36258: New "Users by Domain" Report shows users by Domain
As part of Version 8.6's multi-domain improvements, the SES Web console now includes a User report that lists domain users. It includes User information such as Domain, SAM, UPN, First Name, Last Name, Email, and Phone.
SD-36224, SD-36225: When viewing the list of users in the SES and SES Web Consoles, the users now include the UPN for AD users, and the domain (or local PC name for local users), and Search/Filter functionality permits searching and filtering based on the domain
As part of the multi-domain improvements for SecureDoc 8.6, these new columns were added to provide the ability for the SES admin to see what domain and UPN are set for each user. The agreed improvement was to add the domain and UPN after the current User ID Column.
In the SES Console, the columns now displayed under the Users section are Num, User ID, Domain, UPN, First Name, Last Name, email, Description, User Certificate
Search and Filtering functionalities (Via the right click menu in the SES Console) also permit searching or filtering the User list based on values found in these new columns.
SD-35325: SESCmd.exe has been improved to permit assigning a Device Profile
SESCmd.exe is an interface that can be used to perform administrative actions from the command line. This utility has been enhanced to allow the assignment of device profiles to devices. This can be useful when there is a requirement to assign a profile to a large number of devices that are not contained in a single SES folder.
The syntax of this command enhancement is:
SESCmd.exe AssignProfile <ProfileIndexNumber> <”Path to file”> [<"KeyfilePassword">]
The meaning of each of the command parameters/arguments is:
<ProfileIndexNumber> - database index (tblProfiles.Profile_Index) of the profile being assigned
<Path to file - CSV file path (no header, one row) containing comma-separated device names (Computers.PC_ID) of devices being updated
<KeyfilePassword> (optional) – This is the master keyfile password. If omitted, the user will be prompted for it
NOTE: Any of the above parameters/arguments that contain space(s) must be enclosed in quotes
SD-33483: SecureDoc now automatically rotates the BitLocker Recovery Key whenever it has been viewed
The BitLocker Recovery Key is sensitive information as it's a PIN that is able to by-pass BitLocker pre-boot. Due to this sensitivity, it's important that the following actions result in a new BitLocker Recovery Key being created:
- The SES administrator views the BitLocker Recovery Key in SES Web.
- The user accesses a device using the BitLocker Recovery Key.
For both above scenarios, on the next client contact to SES, the BitLocker Recovery Key should be changed. Therefore, beginning with SecureDoc 8.6, SES will now trigger the device to rotate its BitLocker Recovery Keys for all drives after it having been accessed.
SD-34364: The SES Web Console has been reworked and no longer relies upon nor utilizes SDConnex. SES Web's configuration process has been changed to no longer need the SES Web Configurator application.
WinMagic has decoupled the Secure Token Service (required for SES Web authentication) from SDConnex. As a result, SES Web no longer requires a connection to the SDConnex service, as the SDConnex service is no longer brokering traffic to the SecureDoc database.
Customers installing SES V8.6 and SES Web must read the SES Quick Deployment Guide which contains the needed guidance on how to configure SES Web.
SD-32396: A new set of registry entries indicate if endpoint devices are configured to use Boot Patching settings
This improvement permits endpoint devices to be queried remotely in order to determine if they have these SecureDoc settings, so they can be updated appropriately. The improvement adds two new registry DWORD values, located in: HKEY_LOCAL_MACHINE\SOFTWARE\WinMagic.
The DWORDs and their values are:
isUEFIBootOrderEnabled: 1 = Boot order used, 2 = Boot Patching
isUEFIProtectDrvOrdLoaded: 1 = Protection driver detected, 2 = Not detected
How Activated:
On the installation or updation of the SecureDoc UEFI preboot, the registry DWORD entry 'isUEFIBootOrderEnabled' is created with a possible value of 1, indicating that UEFI boot order is being used OR 2 where boot patching is used. This only occurs when SecureDoc Pre=Boot is being used, either with Software or Hardware encrypted drives.
On the next boot, SDService will check if the system is a UEFI system with boot logon installed, in which case it scans NVRAM for the existence of the SecureDoc protection driver.
If the driver is found in NVRAM, the registry DWORD 'isUEFIProtectDrvOrdLoaded' is created with either 1 as its value, indicating the driver was located or 2 if it was not found to be loaded.
SD-34530: RMCE for macOS has been substantially changed to utilize the RMCE Manager application to create and access the contents of encrypted containers.
Beginning with SecureDoc 8.6, Encrypted containers will be opened and updated via the RMCE Manager application. This is mentioned in more detail in the release notes for SD-33518. Please review the macOS client documentation for a deeper explanation of the changes to the User Interface.
SD-34357: SESWeb Reporting functionality now includes a new Crypto-erased Devices report
WinMagic has received requests from customers to provide a new standard report on Crypto-erased devices. Per these requests, a report has been added to the standard list of device reports, showing details such as Device Name, Status=Crypto-erased), and Date/Time of the Crypto-erase operation.
SD-35031: A new option has been added into the Device Profile to enable the Device Compatibility testing report mode functionality
A new option has been added to Device Compatibility testing that permits testing to stop after Pre-Boot Compatibility testing has completed, at which point the device will produce a report of the test results.
If chosen, this option will block the SecureDoc Client installer from completing installation and encryption of the device. Customers may find this option very useful in early new-device-model compatibility testing, or when evaluating a number of possible device make/model options during the hardware refresh purchase decision phase.
This option is found under the Profile->General->Advanced Options and requires the “Auto-Adapt” setting to be enabled. Listed under the dropdown menu is the option “Stop after Pre-Boot compatibility test and report results only”
SD-31988: SecureDoc now supports SUSAM within the Linux-based Pre-Boot for UEFI Devices (PBLU)
In addition to the existing SUSAM functionality that works for devices using Legacy BIOS under the SecureDoc Linux-based Pre-Boot (PBL), SecureDoc now also offers SUSAM for UEFI devices using the Linux-based Pre-Boot for UEFI (PBLU). This was implemented to provide additional compatibility for systems that are using disk controllers or modes that prevent PBLU from accessing the disk directly. For example, systems configured to use the intel software RAID functionality in the bios.
Note: Although the SUSAM technology has been well tested in previous versions for Legacy BIOS implementations, this new implementation for UEFI is considered to be the initial feature release. Therefore, this new feature is disabled by default, and is accessible through a new Profile option, adjacent to the existing SUSAM option. It is strongly recommended to test this feature on devices before widespread deployment. After successful customer validation, this option may become a default in a future version of SecureDoc.
SD-29594: A number of new targeted reports have been added to permit finding specific device lists that have no owners and / or no self-help questions
The specific reports are:
- Users report - FDE Users without self-help
- Device report - Devices which have no owners
- Device report - FDE Devices which have no owners
- Device report - FDE Devices which have owners and no self-help
SD-35418: The SES Web Console has been improved to generate Device Profiles in a more consistent manner
The old way of creating a Device Profile has been removed and made more consistent across all Profile types.
SD-35029: A fixed static IP address can be defined to be used at SecureDoc Pre-Boot, overriding the setting from the SecureDoc Profile, suitable primarily for environments where the IP needed at pre-boot may differ from windows
Customers have indicated that there are certain scenarios where it may be necessary to have a different IP configuration in windows vs in Pre-Boot authentication. In this scenario, even setting the option in the profile to use Static IP is not sufficient. Therefore, an improvement was made to provide a way to manually set a static IP for Pre-Boot authentication on a device.
A KB article will be added with more details on how to configure this mode. For details, please reach out to WinMagic Technical Support.
SD-35268, SD-35270: User Login options have been expanded - User ID formats added
As part of the multi-domain improvements made in SecureDoc 8.6, users may logon at SecureDoc Pre-Boot and SecureDoc Control Center logon using the traditional SecureDoc UserID format, as well as SAM (short name), UPN (UserID@domain.com), Windows Domain\UserID, and Linux Domain/UserID formats.
A new settting has been added into the General panel of the SES Console's Global settings, permitting the SES Administrator to enable this new functionality.
NOTE: In order for this to take effect, new keyfiles must be generated that include the new information. Generally, this will happen over time as users sync passwords and / or logon to new devices. If there is a requirement to force immediate update of users keyfiles, please reach out to technical support for instructions.
SD-35770: Ability to append Domain, PC or Custom string to User Name has been deprecated from the SES Console UI, but the functionality still exists through direct change to the PackageSettings.ini file
In order to keep the SES Console User Interface focused on most frequently used options, it was decided to remove the rarely-used prompts from the SES Console that relate to appending Domain, the PC (computer) name, or a Custom string to each user's User Name.
Work-Around: For those customers that still rely upon this functionality, the same effect can be achieved by opening and editing the PackageSettings.ini file, as follows:
[Package Settings] <-- Search for this section
AddDomainToUserID=1/0 (0 by default) <-- Setting this to 1 will add the Domain to the User ID
AddPCnameToUserID=1/0 (0 by default) <-- Setting this to 1 will add the Computer name to the User ID
AddCustomnameToUserID=(empty by default, if set, appended to user name after @) <-- if set to a non-empty string, this string will be appended (following a commercial at sign @) to each User ID. For example:
AddCustomnameToUserID=MYORG <-- results in users added as username@MYORG
These settings were deprecated as they no longer apply after the multi-domain design changes introduced in 8.6
NOTE: A maximum of one of the above settings should be employed in any given PackageSettings.ini file.
SD-35289: Customers will now see a warning message if attempting to over-install/downgrade-to an earlier version of the SecureDoc Windows Client
In previous versions of the SecureDoc Windows Client, there was no warning or protection provided if an attempt was made to install an older version of the windows client over a newer version. Instead, the upgrade would proceed and result in a corrupted installation.
Starting with SecureDoc 8.6, downgrades are not allowed, and the user is shown a message that indicates that a newer version already exists, and that downgrading is not permitted.
SD-36362: Due to User Record changes for Active Directory synced users, it is STRONGLY advised that customers using ADSync must start and run ADSync immediately after SES upgrade and database migration, and BEFORE SDConnex is started. Additionally, it is strongly recommended to use the Full Sync option by clicking the corresponding Full Sync button before starting the ADSync service.
After upgrading SES to V8.6 and BEFORE starting SDConnex, customers that use ADSync MUST start and run a Full Sync using ADSync's Full Sync option, BEFORE starting SDConnex. This is required due to changes in how User information that is retrieved from Active Directory is stored in the SES Database. By performing a full sync immediately, it will ensure that existing AD User Records are updated efficiently before those records can become locked or busy due to SDConnex activity.
For those customers with huge Active Directories, the ideal upgrade planning would include planning to upgrade SES during a period of relatively low user activity (e.g. a weekend or holiday) in order to permit ADSync the maximum possible time to complete the update.
SD-35073: Port Control short-term override and automated device discovery has been improved
Port Control now contains advanced options that permit devices to be deployed such that they detect and “white-list” only those human interface devices (HID) attached/connected during SecureDoc installation. This permits kiosk, ATM and other similar special-purpose devices to accept only those HID devices they are deployed with (down to the Serial number), and Port Control will prevent attachment of any other devices.
To coincide with the maintenance of a special-purpose device (e.g. an ATM/Banking Machine) by a Technician, Port Control also offers remote commands to schedule the disablement and re-enablement of Port Control. This improvement includes a configurable timer (default = 60 minutes) applied which would permit a technician to temporarily connect foreign devices (e.g. such as diagnostic tools, mouse, keyboard) after which the device will revert to scanning and permitting only the regular devices it should use, upon next reboot.
NOTE: This feature relies on technicians knowing that they must disconnect any foreign devices before the reboot, to ensure that the device returns to its “normal” operation mode, seeing only expected devices such as cash dispensers, touch screens, etc. (e.g. in the case of an ATM/Banking Machine).
NOTE: If a Mouse/Keyboard should inadvertently be left connected during the next “whitelisting” process, Technicians would be well advised to ensure that they take the mouse and keyboard away from the ATM device in question, as Port Control tracks these devices down to the Serial Number level – no other mouse/keyboard can be inserted, so if the mouse/keyboard used is not present at the device it improves security.
Resolved Issues
SD-33050: Customers encountered Error 1692 No Operating System Found on systems using OPAL Hardware Encryption
It was determined through investigation that there was a possibility of a drive failure being triggered by frequent communication from SecureDoc causing the drive firmware to stop responding. The affected drive found in testing was the Samsung PM871a. It is recommended to check with the vendor of the drive or OEM system for a firmware update.
This communication behavior has been removed from SecureDoc starting with version 8.6 so that vulnerable drives are no longer at risk from this failure vector.SD-34416: The SDRecovery Tool has been improved to correctly handle performing PSID Revert on eDrives
Issue: If a TCG Opal SED with IEEE1667 support active has Windows installed on it, there is a strong possibility that the disk will be placed under management by Microsoft eDrive.
When the above disk becomes activated as an eDrive, it was longer possible to perform a PSID-revert action with previous versions of the SDRecovery tool. The only work-around had been to use 3rd-party tools to revert the disk if the customer did not want to use eDrive management or Software Encryption.
Solution: SecureDoc 8.6 includes a new version of the SDRecovery tool which has the ability to PSID-Revert an Opal SED if it has become activated as an eDrive or has been otherwise put into an OPAL Activated state. As in the past, when performing a PSID-Revert, it requires the PSID code from the label of the disk drive. There is a corresponding PSID-Revert button on the SDRecovery main screen that can be used to perform the revert.
The functionality is also included in the command line version of SDRecovery. The syntax is:
SDRecoveryCmd -erase <-d diskNo> <-eDrive> <-s PSID> where the new option clause -eDrive is defined to "Allow PSID revert OPAL eDrive".
SD-35158: An issue has been corrected, wherein customers who have Cisco Duo installed were encountering a conflict between SecureDoc and Duo relating to Password Synchronization.
Issue: SecureDoc Password Synchronization was failing randomly where client devices also has DUO installed; It was determined that Windows will sometimes create an encrypted version of credentials (passwords) when they are passed to authentication APIs, which results in the same encrypted passwords being passed to the SecureDoc Password Synch process.
Solution: SecureDoc is now able to synchronize with this form of credential, and this correction is now integrated into V8.6.
SD-35910, SD-35162: Devices that originally did not have a shared device certificate for 802.1x assigned via a profile with the appropriate network configuration were not reliably receiving the certificate when the Profile was updated
Background: Many organizations are looking more closely at applying 802.1x network security in their environments. WinMagic has long supported PEAP authentication as certificate-based authentication was not available to pre-boot unless the private key was made available for every device certificate. This presented an issue for organizations that prefer to use certificates to authenticate. In 8.5, the ability to use a shared device certificate for 802.1x was introduced. This allows an organization to use a fixed user account that is protected by certificate, not password, for EAP-TLS 802.1x authentication at pre-boot.
Issue: It was discovered that for devices that originally did not have a certificate assigned via a profile with the appropriate network configuration, that once the new profile was assigned, the certificate would not reliably propagate. This was determined to be an issue with device communication logic, and it was found that the certificate was not being requested on communication with the SES server.
Solution: SES V8.6 (and earlier HotFix 8.5 SR2 HF2) now include improved logic for communication to the SES server that will confirm the certificate is loaded and make a new request to retrieve it, should it not be found. In addition, if the certificate is changed (Eg: to replace an expired certificate) the new certificate will propagate successfully.
SD-34533, 35195: Password Synchronization would fail on certain client devices where personal key files are being automatically created for users, and / or user devices had all boot slots full (40 by default).
This issue comprised multiple root causes and resolutions:
1) It was found that an issue existed which involved Case Sensitivity when creating the personal Key File for a user. The personal Key File is used for RME / RMCE encryption. In the rare case where a user would have an upper case user id, the client would create the personal key using a lower case userid. This would cause an issue where the client incorrectly invalidated the userID due to the case sensitivity mismatch. The underlying result was that the cached credential could then become duplicated in SDSpace, thus preventing password sync from working as designed. This would result in the user not being able to login offline at Pre-boot.
2) It was found that in the case where a shared system (such as a loaner machine or a machine in a call center) contained many user accounts cached in windows (in some cases could be many hundreds) the system (if configured in the profile) would fill up the available boot slots with as many users as it can during registration. The default is 40 boot slots. The issue that was found, was that as new users logon to the system, the expected design was that new users would replace the oldest users in the boot slots, thus enabling the new users to authenticate at pre-boot. This design was not functioning, and new users were not getting cached on the system.
3) It was found that in a specific situation where the user is offline at pre-boot, and offline at windows until they connect via VPN, that the client was only trying to cache the user at the initial start of windows. If the user took some time to connect to the VPN, the user would not get cached. This issue has been resolved and the system will continue to check for a connection to the SES server in order to cache the user.
Solution:
All issues have been resolved and a HF was made available on request for 8.5 SR1. This release note is to notify that this fix has also been fully incorporated into Version 8.6.
SD-35419: An issue was identified that prevented a device from rebooting via remote command if automatic reboots were disabled during the initial installation.
Issue: Where an installation package has the setting: "Wait for the distribution software to reboot the system" had been selected, the intended behavior was that this setting would prevent the automatic restart of the computer during various parts of the SecureDoc Installation process. However, it was found that this also was preventing the later processing of a remote “Reboot Device” command if sent by an SES Administrator.
If the Administrator sends a command to reboot the device, once the device has communicated with the SES Server, the SES command's status will show as "executed", but the device will NOT be restarted in response to that command.
Solution: This issue has been resolved, and the client will now correctly respond to remote reboot commands after the initial installation process is completed.
SD-33443: Certain customers using HP Z-Series G4 workstations (typically configured with multiple display cards) have encountered a black screen when using SecureDoc Linux-base Pre-Boot for UEFI.
Issue: On HP Gen4 Z-Series workstations, PBLU would fail to load with a black screen. Attempts to mitigate this on earlier SecureDoc versions using boot parameters: wmsd_prompt=1 and/or nomodeset had no effect.
Solution: This issue has been corrected in V8.6 PBLU. Customers using such devices should upgrade to V8.6 as soon as possible.
SD-35194: Improve hardening against potential IIS vulnerabilities in SES Web
In SecureDoc 8.5, improvements were made to the SES Web config file to remove certain "verbs" that could be used as part of an exploit. However, for customers who already removed these verbs at the server level, due to propagation removing at the site level would cause a failure to start the website.
This issue has been resolved and SES Web config has been adapted to no longer conflict with the server rules.
SD-36172: Loud Beep emitted when the idle timer powers off a machine from PBLU
Issue: Some systems were found to emit a loud beep when configured to shutdown from idle or restart from the PBL or PBLU environment. While not impacting functionality, it was found to be annoying.
Solution: This has been resolved in this release. The systems will no longer emit a beep noise when shutting down or restarting from the Pre-Boot Linux environment.
SD-34553: An issue in which the SDService log could contain unrecognizable / meaningless characters if initial encryption is interrupted on RHEL 7.8 devices that use the XFS File System has been corrected
This issue had been a limitation in SecureDoc 8.5 SR2, but has been corrected in version 8.6, and the SDService log will no longer contain unrecognizable/meaningless characters due to this previous issue.
Limitations
SD-33066: The Aladdin eToken Pro 32k is only supported on 64-bit PBU and PBL/PBLUx64
Issue: Since the SecureDoc PBL and PBLU pre-boot environments are 64-bit only, the Aladdin eToken Pro 32k is no longer supported, as it works only in the context of a 32-bit Pre-Boot (which is no longer supported by SecureDoc).
Solution: Please transition to a different token that is compatible with 64-bit Pre-Boot.
SD-33466: An incompatibility has been found that prevents the use of the SecureDoc Surface Installer on Microsoft Surface Pro 7 devices
Issue: Having installed SecureDoc using the specific Surface Installer and configured for PBLU on a Windows Surface Pro 7 device, PBLU will not load and the screen will remain black.
Work-Around:
Until a more robust solution has been found, please:
- Use the "regular" SecureDoc 8.6 client software installer to install SecureDoc V8.6 on Microsoft Surface 7 devices when configured for PBLU.
- Customers must connect a mouse and external keyboard to the Surface Pro 7 device in order to be able to use the device at pre-boot as the touch-screen is not supported in PBLU
WinMagic will continue to pursue a solution to these limitations, which may require a kernel update for PBLU in a future SecureDoc version.
SD-33726: When using WPA2-Personal Networking, the Passphrase cannot exceed 32 characters in length
Issue: SecureDoc's Pre-Boot Network configuration only accepts WPA2-Personal network passphrases that are up to a maximum of 32 characters in length.
Work-Around: Change your existing network (or Set up a parallel Wireless Network) to utilize WPA2-Personal protection for which the passphrase is no longer than 32 characters, and reference that network in your SecureDoc Profile settings where PBConnex Network Authentication is a requirement.
WinMagic is working to improve this in a future version.
SD-33805: A field-size limitation of 64 characters for SecureDoc User Names may cause partial synchronization of User Names synced from Azure AD
Issue: Normally when synchronizing with on-premises AD, the limit of 64 characters on SecureDoc User Names does not have a negative impact since sAMAccountName is generally 20 characters or less and that is typically mapped to the User Name field in SES.
However, for Azure AD the default is to map UPN (which can easily exceed 64 characters) to the User Name field in SES. WinMagic is looking to provide a resolution to this issue in a future version.
SD-34059: Rapid insertion and removal of USB Media during the 60-second countdown to system shutdown can result in a system halt on systems configured to use Port Control
Issue: Due to the SecureDoc Kernel Driver being loaded on-demand (to avoid the need to reboot the device upon first time installation), if a USB media is inserted and removed multiple times rapidly during the 60-second countdown period while the system is about to shut down, it can cause Windows to enter into a BSOD/Blue Screen state.
Work-around: Avoid rapid insertion/removal actions during this countdown period.
SD-34318: When presenting SDForm (where user can fill in information relating to self and device), SDForm is unable to obtain the user's name in UPN format if the user logged into the device using a UPN-format User ID at Windows Logon
Issue: It appears that a SYSTEM-level process like SDForm is unable to request the logged in user's information when that user logged in to the device via UPN name.
Solution: It is recommended to manually enter the UPN. This should not pose a substantial problem over the life of the device installaiton, as the UPN form of the user name will be made available via ADSync.
SD-35024: When encrypting or decrypting Linux devices using offline encryption, the device's encryption status is not updated in the SES Console as regularly as applies where the device is encrypting online
Issue: When encrypting or decrypting Linux devices using offline encryption, the device's encryption status is updated only after each volume completes encryption (or decryption). As a result, using offline encryption / decryption, such devices can never show an Encrypting or Decrypting status.
At this stage, this limitation is not avoidable, since the device does not utilize an ongoing communication model back to the SES Server. WinMagic is researching options to improve on this.
SD-35365: Customers using SecureDoc-managed BitLocker Full Disk Encryption (FDE) must switch over to use of Removable Media Container Encryption (RMCE) for encrypting removable media
Due to changes in the placement of functionality within the SecureDoc service, for those devices that utilize the combination of BitLocker FDE protection plus Full Sector Removable Media Encryption for protecting removable media, use of RME with BitLocker FDE will no longer be available. This is only applicable to BL + RME. SecureDoc FDE Engine + RME continues to perform well as in previous versions.
Work-Around: Change any profiles that utilize the combination of Bitlocker Full Disk Encryption + RME to utilize Bitlocker + RMCE (Removable Media Container Encryption) instead.
NOTE: Any existing media that had been RME-encrypted will continue to be readable and capable of being updated, but for BitLocker-encrypted devices it will no longer be possible to create NEW RME-encrypted media, so customers running BitLocker should create RMCE-encrypted media instead.
SD-35430: SES Web Console Support for Port Control does not include a means of defining an acceptable USB-connected devices list
The SES Web Console in SecureDoc 8.6 does not include a means of creating or maintaining a list of acceptable device types applicable to the Port Control feature, that can be communicated to endpoint device through the Profile. This functionality is relatively rarely used.
Work-around: For customers that do create and define a list of acceptable USB devices, if configuring a Profile using SES Web, save it, then open the Profile using the SES Console, then navigate to the Port Control panel and create the list of VID (Vendor ID) and PID (Product ID) information for those devices that are to be considered acceptable.
NOTE: While the SES Console does permit the console to query the server's USB Bus history (or the USB Bus history of the Administrator's device if the SES console is installed on the Administrator's Laptop/Desktop computer), it will not be possible to emulate access to USB Bus history within the SES Web console, due to the natural limits that web applications have to the hardware on which the Web server is running.
WinMagic will be seeking an alternate way to handle importing a list into SES Web, which will be announced in a future version.
SD-35708: The Compatibility Tool Report does not support Multiple Languages
Where customers have translated certain messages, those messages will not appear correctly in the Compatibility Report. WinMagic is seeking a solution to this issue.
SD-35886: Existing / previously-deployed Client devices will not permit users to log into SecureDoc Control Center with alternate-format Credentials, even after updating the SecureDoc Client software on the device
SES 8.6 permits defining that User Credentials can be entered in a number of alternate formats. Note that, in general, upgrading existing client devices to handle these alternative logon methods will not necessarily mean that the users can immediately use these new login formats at the SecureDoc Control Center.
Underlying Cause: For the new logon methods to work, existing on-device key files must be updated to have the relevant attributes. There is at present no means of automatically sending updated key files to client devices. The key files will get updated as passwords are synchronized or as users logon to windows with alternate formats.
WinMagic is investigating ways to potentially script an update to all key-files. If this is needed in your environment, please contact WinMagic Technical Support.
WinMagic is working to find a solution for this issue.
SD-35951: Certain aspects of Network Access Control are not yet implemented in SES Web for CloudVM Windows Enterprise client types
Issue: 2 options: "Hide wireless configuration at pre-boot" and "Do not reveal passwords at pre-boot" are missing from the SES Web User interface.
Work-Around: if these features are required in the Profile you are creating, save your profile in SES Web, then open and modify it using the SES Console application.
SD-35949: The SES Web editor for OSA Device Profiles does not permit definition of Web Browser support at Pre-Boot
Issue: If creating a Device Profile for OSA (OS-Agnostic) devices using SES Web, the SES Web OSA Profile configuration panels are missing the options required to define the use of a Web Browser within the SecureDoc Pre-Boot.
Work-Around: If your OSA Device Profile requires Web Browser functionality at Pre-Boot:
- Save your OSA device profile after configuring all other options, then
- Open the completed OSA profile using the SES Console, and
- Apply the missing Browser settings, then
- Save your Profile in the SES console.
At this point you may use either SES Web or the SES Console to create an Installation Package using the now-updated Device Profile.
WinMagic plans to have a correction to this issue in a future version.
SD-36031: Configuration of ADSync domain parameters wherein the User ID mapping is either different from the default, or includes a modification to append the domain name to SAM account will limit the user's ability to enter alternative logon names for authentication via PBConnex
In particular, use of SAM-name only is not supported for such a scenario.
Work-Around: Users who do not have local accounts will have to either enter the full User ID matching the ADSync mapping or use a logon name format that includes domain/device name.
SD-36050: Once a CloudVM Package has been created from a Profile using SES Web, the Package's version of that Profile does not change if the Profile is subsequently changed
In SES Web, Device Profiles are created, then Installation Packages are created from the selected Profile. From this point onward, the Administrator can then modify the profile.
Issue: Once the profile is modified, SESWeb does not re-check for parameter contradictions in the package, nor does it regenerate the package to reflect the new profile parameter values.
This is a limitation in SES V8.6 and will be fixed in V8.7.
Work-Arounds: Create a new Installation Package from the same (now changed) Device Profile (and duplicate the Package settings used in the original Installation package). For ease of tracking, either change the original package description to indicate it was obsoleted by the new Package or delete the original installation package.
SD-36137: When installing a SecureDoc Pre-Boot for Native UEFI (PBU) profile on a Microsoft Surface Pro 3 device, the device BIOS cannot determine if the on-screen keyboard should be displayed
WinMagic is working on a solution to this that will be implemented in a future release.
SD-36022, SD-32361: Windows RMCE Viewer application will show "Not Responding" status when using Container-encrypted exFAT USB Media created on macOS Big Sur devices
Issue: Under Windows, when the RMCE Viewer attempts to open the container, it determines the file is not fully valid (file valid data size is much less than file size). On closing the media, the Windows exFAT driver writes zeros to make file valid data size equal to file size, which can consume a lot of time. During this process, the USB media cannot be unmounted (unless physically detached) until Windows has completed writing zeroes and releases the file.
This issue occurs only when using the Media Viewer Application in Windows to access exFAT-formatted USB media created on macOS Big Sur (and Catalina) devices, because only exFAT supports files having these two (possibly different) file size properties: "file valid data size" and "file size".
A warning of this behavior will appear when SecureDoc creates a Container-protected USB media and it detects it is running on a device running macOS Big Sur/Catalina.
NOTE: This issue does not occur when using macOS-created exFAT Container-protected USB media on Windows devices that have SecureDoc installed.
NOTE: macOS Mojave works fine - and no issues detected on Windows when using Container-based encryption created on macOS Mojave
Detailed symptoms:
On a macOS device:
- Renaming a container file takes milliseconds
- Changing password using the RMCE Viewer takes milliseconds (new data is written within valid data range)
- Adding files to the container using the RMCE Viewer takes seconds, new data is written right beyond valid data range.
On a Windows device:
- Renaming a container file using the RMCE Viewer takes a lot of time - Windows starts writing zeros right beyond valid data range until reaches file size.
- Changing password using the RMCE Viewer takes a lot of time, despite new data being written within valid data range. On closing the container file, the Windows driver will start writing zeros right beyond valid data range until reaches file size.
- Adding files to a container using the RMCE Viewer takes a lot of time; new data is written right beyond valid data range, but again on container file close Windows starts writing zeros right beyond valid data range until reaches file size.
Work-Around:
The customer should physically remove the USB media from a Windows device after closing the Windows RMCE Viewer application.
SD-36255: Notifications are not being posted into the SDNotify.log file where UI language is Japanese when DebugEnabled is enabled
Reason: Japanese is a non-Latin language and can't be written to a plain ASCII file (like a log file).
This will be a limitation until a solution is found.SD-36165: A change in Password strength/composition rules (defined in Global Settings) will not apply to Removable Media passwords
Issue: If one had started with a particular set of Password strength/composition rules in the Global Settings, the original rules will continue to apply for Removable Media (e.g. RME or RMCE) even after a new key file has been sent to the device from the SES Server.
There is no work-around for this at this time. WinMagic is seeking to correct this issue in a future version or Service Release.
SD-36191: Users using SES Web to create/update Profiles may encounter slow population of drop-lists or update of User Interface elements on-screen
Issue: Due to the complexities involved in hiding/un-hiding on-screen elements, or in conditionally populating on-screen elements such as drop-lists based on previously selected options, users may encounter delays of 2-3 seconds when navigating through SES Web screen panel elements.
WinMagic is researching how this can be improved to provide a faster user experience and hopes to have a solution in a future version.
SD-36221: HP EliteBook 755 G5 Touchpad does not work in Pre-Boot Linux for UEFI (PBLU)
For HP EliteBook 755 G5 devices provisioned with the SecureDoc Pre-Boot Linux for UEFI, 64-bit, the touchpad will not work at Pre-Boot. At present, SecureDoc does not have a driver that can communicate with these touchpad models.
Work-around: If it is necessary to use a mouse to navigate the Pre-Boot screen, either plug in an external USB mouse, or you may be able to navigate between on-screen objects using the tab/back-tab keys. Alternatively you may elect to install the Native Pre-Boot for UEFI (PBU) on this model.
SD-36249: The smartcard reader built into the Dell Precision 7740 (and potentially other Dell models) is not compatible with SecureDoc's Pre-Boot, either under PBL or PBLU 64-bit
Issue: The card reader built into the Dell Precision 7740 (and potentially other Dell models) is not compatible with SecureDoc's Pre-Boot either under PBL or PBLU 64-bit. If Smartcard based Key Files have been deployed, such devices will not permit authentication using a smart card.
Work-Around: Revert key-files to using a password or perform Challenge Response authentication. Then the SES admin must send down password-protected Key Files to any affected devices.
SD-36325: SecureDoc Control Center application is not accessible after excessive failed login attempts unless the machine is restarted. This affects devices configured to use fast startup
The root cause is that the encryption engine will lock after many failed login attempts to prevent hammering attacks. When Fast Boot is configured, windows does not shut down but instead hibernates. This prevents the encryption engine from being able to unlock. In this scenario, only an actual “Restart” will provide a fresh boot.
Work-Around: Restart the machine, then re-attempt access to SecureDoc Control Center (SDCC).
SD-36344: Microsoft Usbccid Smartcard Reader device installed in certain new computers is not compatible with SecureDoc Pre-Boot, barring such devices from using Smart Cards at Pre-Boot
WinMagic has found that a new Microsoft Usbccid Smart Card reader device - seen in certain new Dell models (though there may be others affected) are not accessible at SecureDoc Pre-Boot and therefore affected devices will not be able to use Smart Cards at Pre-Boot.
Work-Around: Key Files on such devices should be password-protected until a solution is found.
WinMagic is researching a solution to this, and hope to have that in a future version.
SD-36355: Under macOS Big Sur, if encrypting an item of media with option "Encrypt entire space and move files into container" enabled, the resulting media is not dependably accessible using a Windows Device
After logging into the media and accessing it using the Windows RMCE Viewer application, the contents of the media appear incorrectly - in some cases folder names are not consistent with what was created under macOS, and folders may appear to be in the wrong location, folder contents can't be extracted, folders cannot be renamed, and nothing happens if deleting a folder.
At present there is no work-around for this (aside from avoiding sharing media created on a macOS Big Sur device with Windows clients), but WinMagic is researching to find a solution which we hope to have in a future version.
SD-36375: CloudVM Packages installed on Citrix Xen Servers in Legacy mode become incapable of booting into Windows and beginning initial Encryption
Issue: CloudVM Packages installed on Citrix Xen Servers in Legacy mode become incapable of booting into Windows and beginning initial Encryption.
Pressing 'a' to bypass pre-boot does load the Operating System but initial encryption does not begin, intentionally as pre-boot failed to load. Inspection of sdjob.log shows the following error: "Encrypt with standard mode <date and time > Missing SES connectivity at pre-boot (0x7024)"
Workaround: Until a solution has been found, if an attempt has already been made to install a SecureDoc CloudVM client installation package on a Citrix Xen device, remove SecureDoc as follows:
- On start-up press 'a' to bypass pre-boot authentication
- The OS will load
- Sign in to Windows
- Log into SecureDoc Control Center using an Admin-level Key File
- Remove Boot Logon from the device
- Reboot the device
- Uninstall SecureDoc
SD-36431: SecureDoc is unable to be installed on Azure Windows Server - Gen 2 (UEFI) Virtual Machine images
Issue: Since current versions of the Microsoft Azure Server VM BIOS do not support UEFI Binding (which is part of the UEFI standard), WinMagic must work with Microsoft to implement this. Microsoft UEFI Bios appears to no longer support our legacy method of performing key transfer (Driver Hook).
The Gen 1 (Legacy) images of the Windows Server are still be supported on Azure.
SD-36506: Under macOS Big Sur, the Directory tree of an encrypted USB removable media seems to become corrupted if there is a great number of files in the directory
WinMagic is investigating this issue and hopes to have a resolution in a future version.
SD-36512: Under macOS Big Sur, customers may encounter slow movement of files into Encrypted Media containers
Issue: When moving large numbers of directories and files within them into an encrypted container, customers may encounter slow copy progress of those folders / files into the container. This issue was encountered when the option "Encrypt entire space and move data into container" was used.
A warning message will appear in this scenario: "SecureDoc for FileVault2: Warning: use of this media on a windows device by SecureDoc applications and services may require significant time for some operations, and therefore is not recommended".
No work-around is available at this time, but WinMagic is investigating the causes of this and hopes to have a solution in a future version.
SD-36526: When attempting to install SecureDoc Server Client on a Windows Server 2004 Core (Feature on Demand) hosted in the Cloud, the client fails to complete the installation
Issue: Upon installing SecureDoc on Windows Server 2004 Core (Feature on Demand) hosted in the Cloud, nothing happens following the installation. Boot-Logon fails to install.
Workaround: Manually open Windows File Explorer by running explorer.exe from the command prompt. Once explorer is started, SecureDoc Boot Logon is able to be installed, and the machine will be rebooted after the installation has completed.
SD-35634: The Encryption Status appears incorrect on SecureDoc devices running Linux following uninstallation.
Issue: The SecureDoc Pre-Boot does not update SES, it is the SDService process that updates SES, or in special cases like offline encryption there could be an update after an operation is complete (also full uninstall).
This results in a possible race condition when SDService performs an update right before it is disabled (to decrypt, SDService is disabled so that it will not restart encryption on the next system boot). Decryption change of status happens when decryption is about to run. Offline encryption does not update SES until after each volume encryption status has changed, so the status here should change from partial to plaintext (not encrypted)
This is a known environmental limitation.
SD-36566: Installing SES Web Console on a separate server without also installing SecureDoc Enterprise Server elements will result in SES Web server that cannot update/save its Key File
Issue: If SES Web is installed without SES Console functionality into a separate server, even if the Key FIle is copied from the primary SES Server, upon opening the browser to URL: https://localhost to configure SES web, once the expected valid options are entered in the form presented, a message "Failed to save keyfile" is displayed, indicating that the configuration has failed.
Work-Around: Install (but leave idle) the remainder of SD Enterprise Server. There is no need to start or configure any services or the SES console.
WinMagic is researching this issue and plans to have a solution in a future version.
SD-36565: Blocking a user's access to a device will require defining all formats of that user's ID if alternate login User ID formats are defined in Global options
Issue: Now that SecureDoc supports other login User ID formats (e.g. SAM, UPN, user@domain) as enabled in Global options, all user formats are stored, and at present a user whose one ID format is blocked could still be cached with one of the other formats. If an admin logs into SecureDoc Control Center and locks out a specific user by enabling the locked user list, if adding only one format to the list, it will not block other formats from still being allowed.
Solution: In order to disable access to a device through SecureDoc Control Center, the to-be-blocked user account must be defined using all login formats in the locked users list. This feature is not commonly used, and therefore WinMagic will provide a solution in a future version or service release.
SD-36589 BitLocker Recovery Key rotation does not work within SESWeb
Issue: If requesting BitLocker Key Rotation in SESWeb, it does not result in automatic key rotation for the device.
Work-Around: Please use the SES Console to submit this command until WinMagic as developed a solution for this limitation in SESWeb, which is anticipated to be included in a forthcoming release.
Customers with an active support plan should contact support@winmagic.com to receive the latest download link for their SecureDoc upgrade.
| WinMagic 5770 Hurontario Street, Suite 501 Mississauga, Ontario, L5R 3G5 Toll free: 1-888-879-5879 Phone: (905) 502-7000 Fax: (905) 502-7001 |
Sales: sales@winmagic.com Marketing: marketing@winmagic.com Human Resources: hr@winmagic.com Technical Support: support@winmagic.com For information: info@winmagic.com For billing inquiries: finance@winmagic.com |
This product includes cryptographic software written by Antoon Bosselaers, Hans Dobbertin, Bart Preneel, Eric Young (eay@mincom.oz.au) and Joan Daemen and Vincent Rijmen, creators of the Rijndael AES algorithm.
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.OpenSSL.org/).
WinMagic would like to thank these developers for their software contributions.
©Copyright 1997 - 2020 by WinMagic Corp. All rights reserved.
Printed in Canada Many products, software and technologies are subject to export control for both Canada and the United States of America. WinMagic advises all customers that they are responsible for familiarizing themselves with these regulations. Exports and re-exports of WinMagic Inc. products are subject to Canadian and US export controls administered by the Canadian Border Services Agency (CBSA) and the Commerce Department’s Bureau of Industry and Security (BIS). For more information, visit WinMagic’s web site or the web site of the appropriate agency.
WinMagic, SecureDoc, SecureDoc Enterprise Server, Compartmental SecureDoc, SecureDoc PDA, SecureDoc Personal Edition, SecureDoc RME, SecureDoc Removable Media Encryption, SecureDoc Media Viewer, SecureDoc Express, SecureDoc for Mac, MySecureDoc, MySecureDoc Personal Edition Plus, MySecureDoc Media, PBConnex, SecureDoc Central Database, and SecureDoc Cloud Lite are trademarks and registered trademarks of WinMagic Inc., registered in the US and other countries. All other registered and unregistered trademarks herein are the sole property of their respective owners. © 2020 WinMagic Corp. All rights reserved.
© Copyright 2020 WinMagic Corp. All rights reserved. This document is for informational purpose only. WinMagic Inc. makes NO WARRANTIES, expressed or implied, in this document. All specification stated herein are subject to change without notice.
