SecureDoc V8.5 Release Notes

Alles anzeigen

Important Note

Feature Deprecation

The SecureDoc CloudSync product/feature has been deprecated in this version, as well as support for SecureDoc FileViewer (through which authorized users could securely access such EFSS cloud-stored protected documents in clear-text).

In SES Version 8.5, WinMagic has terminated support for SecureDoc CloudSync, its Enterprise File Sync-and-Share encryption product, plus the FileViewer application that permits secure access to such encrypted files in clear-text.
CloudSync protected documents stored in the cloud in EFSS products including Box, DropBox, Google Drive, and similar.

Note that the relevant sections of the SES Administrator's Guide have been removed in this version, covering CloudSync for Windows, CloudSync for Mac and FileViewer.


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

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

Version

Release Date

Details

8.3 SR1

May 15th 2019

New features, improvements and fixes (server/client)

8.3

February 5th 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://www.winmagic.com/support/technical-specifications
For supported devices, drives, smartcards and tokens: https://www.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

Version

Editions

Architecture

SR/Update

10 RS5 [1809]
10 RS4 [1803]
10 RS3 [1709]
10 RS2 [1703]
10 RS1 [1607]

10 T2 [1511]
10 T1 [1507]

Enterprise Pro

32/64-bit

8.1 SR1 HF2+
SD 7.5 SR1 HF8 / SD 8.2 HF1+
SD 7.5 SR1+
SD 7.1 SR6+
SD 7.1 SR4+
SD 7.1+

8.1

Enterprise Pro

32/64-bit

All versions

7

Enterprise Pro

32/64-bit

All versions

Apple macOS

Version

Editions

SR/Update

Catalina

10.15.X

MAC 8.5+

Mojave

10.14.X

MAC 8.3+

High Sierra

10.13.X

SD 8.2 DMG

Sierra

10.12.X

SD 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.

 

Advisories

SD-31929 SecureDoc for FileVault 2 cannot enable FileVault 2 successfully using a Standard User Account.

Issue: This is a limitation from Apple, which requires an Admin Account's elevated rights to be able to press OK on the fdesetup prompt.

Reason: Attempting to enable FileVault 2 using a Standard User returns an error message: "Operation was denied because the current credentials do not have the appropriate privileges."

Solution: Log on with an Admin account (create one if none exists) and proceed through this process, which will permit FileVault 2 to be enabled successfully.

 

What’s New

New Features

SD-30123:  SESWeb has been substantially improved to include a new Notification Center.

The Notification Center functionality permits the Administrator to see a list of current and past notifications, with the ability to mark notifications as read, and mark notifications as high importance (triggering a more direct form of notification such as being sent by email). Notifications regarding deletion of keys can be set to a high importance so that Administrators can validate that the action was expected.
Configuration of notifications is included in this new feature, including: definition of which events trigger notifications, which Administrators receive notifications, which types of notifications apply to various Administrators, configuration of how notifications can be delivered (e.g. email, SMS) as well as ability to mark notifications as read.


SD-30280:  SecureDoc now offers the ability to TPM-protect Auto-Boot Key Files

Issue: Auto-Boot Key files (being stored within the device's disk drive) have traditionally permitted a device to be auto-booted to its operating system; regardless of in which computer the disk drive is installed.

This feature now permits the ability to protect the Auto-Boot Key File with the device TPM so that the pre-boot will only Auto-Boot when in the device with the TPM chip used during installation.  Since no two TPM devices will ever render the same cipher, the Auto-Boot Key File is "bound" to its original device and will not permit Auto-Booting if the drive is ever moved to another device.


SD-30905:  Add Support for macOS 10.15.x Catalina

This version of SecureDoc offers support for macOS 10.15.x Catalina


SD-30989:  New ability added that permits the SES Server to move a device into the Exempt Device folder (which does not support SDConnex Network-Brokered Auto-boot) if the device has failed to communicate to the SDConnex server for a specified number of the device’s normal communication cycles.

Issue: Client devices that rely on SDConnex to Auto-Boot the device, and which are otherwise in use 24x7, should normally be communicating on a regular basis with the SDConnex server while in Windows. This new feature permits SES to prevent devices from utilizing Network-Brokered Auto-Boot if the devices have failed to "call in" to SDConnex for a defined number of communication cycles.

To Configure: In the device profile, communication settings page, the Administrator selects a number of missed communication cycles – For example, if the computer is set to communicate every 60 minutes, this is one cycle.  Setting this new option to 10 would move the device into the Exempt Folder after 10 cycles or 600 minutes (10 hours). Devices in the Exempted Devices folder will never be sent an Auto-Boot key File, and thus cannot perform PBConnex network-brokered AutoBoot or PBConnex user-based authentication.

This solution will help ensure that PBConnex Auto-Boot devices that have "gone silent" (and therefore might be at risk of insertion of attack software) cannot be restarted and rebooted to the OS by the would-be attacker.
 
If the Administrator, having earlier configured this setting, later wishes to stop using this feature in a given Device Profile, they can do so by removing the number of cycles (Setting this option to Zero).  Once the updated profile is applied, this will allow the devices to auto-boot via the network without any requirements for communication (behavior as in previous SecureDoc versions)
If a device is removed from the Exempted Devices Folder, it will also resume Network-Brokered Auto-boot.


SD-30333:  SESWeb now includes functionality to permit creation of Device Profiles for hardware Linux devices. 

SESWeb Documentation has also been fully re-written as well, covering numerous changes that have come into the SESWeb browser-based console.


SD-29490:  New DMZ-hosted "Gateway" service permits remote endpoint devices to access the full functionality of SDConnex servers located inside the LAN, while isolating remote device workload onto dedicated SDConnex Server(s) and providing additional authentication for DMZ communication to SES.

New Feature: SES V8.5 introduces a new DMZ-hosted "Gateway" service which permits remote Client devices to communicate across the internet to a validating Gateway service, which authorizes the device for valid communication, and only if authorized then passes validated/acceptable workloads to a dedicated SDConnex Server hosted inside the customer LAN.  This dramatically simplifies and improves the range of SDConnex/PBConnex functionality (e.g. AD-based authentication) available to client devices that communicate from outside the LAN, while remaining secure and isolating remote device communications from local device transaction volumes.  In addition, it removes the need for SDConnex to communicate from the DMZ to the SQL database.

Note: This service requires isolating such remote device traffic by configuring a specific SDConnex server that will "listen" for Gateway-sourced traffic on a different port (e.g. 8000).  This is different than would be typical for an SDConnex server (on default port 7300) servicing in-LAN (local) device workloads. The Gateway itself will listen for inbound client traffic on the normal (default 7300) port but will then port-translate the traffic so that it is acceptable to the dedicated SDConnex server that is “linked” to the DMZ Gateway.


Improvements

SD-32483:  SecureDoc now reflects a list of user accounts that are cached locally and capable of logging into a device offline, early in the Provisioning/Deployment cycle.

This improvement alleviates the previous need to check SecureDoc Control Center -> Boot Control -> User Management, a method only accessible via manual logon, and not reportable or accessible programmatically via script or other method.  It also alleviates ambiguity surrounding whether each member in the list of users shown in SecureDoc Control Center actually has a keyfile with a password that could be used to authenticate at pre-boot.

This improvement provides clarity regarding which users have complete credentials for offline authentication at pre-boot, visible via a list in the windows registry.


SD-32395:  A new option has been added to the Profile .spf file which permits defining a specified number of failed Pre-Boot Linux for UEFI (PBLU) boot attempts before SecureDoc Pre-Boot automatically switches from PBLU to Pre-Boot for Native UEFI (PBU) boot processing.

Issue: Certain customers would encounter issues booting into PBLU where they either did not have an attached monitor connected to an enabled port, or their devices have had certain ports disabled to work around a known issue with Intel GFX combined with Sleep mode, which can cause system freezing when using PBLU using all display ports.  This would cause the device to need to be manually shut off, which would register this as a “Failed” boot attempt.  After 3 failed attempts, the pre-boot authentication will permanently revert to PBU.

Solution: This option permits the SES Admin to define (in the Profile's .spf file) a more lenient number of Pre-Boot attempts under PBLU, to permit technicians to resolve any issues with monitor connections 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 update boot logon to reinstate PBLU-based Pre-Boot).

How to Apply: To enable this (optional) override, manually add the following to the SecureDoc Profile for the device(s):

Section name: "SDSpace"
Key name: "PbluFailureCounterMaxValue"
Valid key values: 0...255
Key value meanings:
* 0 - PBLU Failure counter is disabled (never switch to PBU)
* 1...255 - This new PBLU Failure counter may take a value between 1 and 255.

NOTE: If the above override is not applied to the Profile's .spf file, the client continues to be hard-coded to default to 3 failed PBLU load attempts before auto-switching to PBU, as before.


SD-32124:  SecureDoc v8.5 now offers support for CentOS 7.7 Linux


SD-32125:  SecureDoc v8.5 now offers support for CentOS 8 Linux


SD-32301:  SecureDoc File Encryption (SFE) has been updated to use the most recent third-party encryption library, upon which it is based.


SD-28075:  SecureDoc for Windows now offers Removable Media Container Encryption (RMCE) protection for CD/DVD optical media.

Issue: WinMagic's legacy CD/DVD encryption solution is not supported in Windows 10 and newer operating systems.  However, certain customers still have a need to protect data being copied onto CD/DVD, thus a solution has been developed to continue to offer this ability.  WinMagic has determined that using Container Encryption on CD/DVD media will provide Optical media encryption that is in fact more flexible than the current full-volume encryption for these media types.

A new document has been prepared that discusses how to utilize RMCE for Optical media; this documentation will be integrated into the SES Administrator's Manual in a future full release.


SD-31986:  The SES Installation Package Provisioning panel has been changed to permit defining a specific User Account that will be used to install the SecureDoc Client software

Issue: Many large customers have found that relying on the default behavior where the SecureDoc client uses the "last logged in user" can yield problems during installation, particularly if the last logged in user account is in the recycle bin in SES, invalid, deleted or otherwise unavailable.

Solution: A new set of controls have been added to the Provisioning panel that permit selecting a specific User Account to be used during installation of the SES Client software as the "deploying user".  This user account must exist as a valid user in the SES database, but does not need to be a valid windows or AD user.

SD-31904:  SESWeb will display a new notification message whenever an SES Admin user performs a Challenge Response device-access recovery operation

SESWeb will now display a notification message whenever an SES Admin user performs a Challenge Response device-access recovery operation, regardless whether this is done using the SES Console or SESWeb.


SD-31838:  A new option has been added that permits Devices that remain idle at Pre-Boot for a set amount of time to be able to restart/reboot instead of shutting down

Issue: Customers have brought to our attention the need to have devices (many of which may use PBConnex network-brokered AutoBoot to authenticate via the network) re-try AutoBoot, if (for example) the device is unable to reach an SDConnex server due to the network being unavailable at the initial boot time.

In previous versions, the only option was to define a timer value in minutes for devices which remained idle at Pre-Boot, and once the defined timer period had elapsed, the devices would power off.

Solution: A new setting can be manually added to the SecureDoc profile, under the “SDSpace” section called "BootIdleActionRestart". If BootIdleActionRestart=1, it will cause the device to reboot itself once the idle device timer period has elapsed, and thereby the device will be able to retry PBConnex Auto-Boot.


SD-31670:  Some customers who are using the UEFI Boot "Patching" method (to patch windows boot manager in order to load preboot) reported that windows updates had the potential to overwrite the patch.

Issue: SecureDoc has the ability to load pre-boot by patching windows boot manager, such that the bios will launch SecureDoc pre-boot authentication when it thinks it is launching windows.  This method is normally used for devices where the alternate method of adjusting the bios boot order is not properly supported.  It was found that when Windows updates the boot files, this patch could be removed and not restored before the system reboots.
Normally, WinMagic SecureDoc implements additional protection at the BIOS level, however in some cases this protection is unavailable.

Solution: WinMagic has developed additional protection at the windows level to protect the boot patch from being overwriting by a Windows update or upgrade process.


SD-31620:  Correct issue where devices that cannot support Boot Order are also unable to boot to pre-boot when SecureDoc uses a "patching" method to install boot logon.

Issue: When SecureDoc "patches" Windows boot manager, specific files are replaced in the \efi\Microsoft\boot directory.
An issue has been identified with this approach; in the case where the BIOS is missing "Windows Boot Manager" the BIOS (on problematic devices) is hard-coded to try to boot to the first bootable disk drive. If the BIOS finds a disk drive in GPT format, it will look to the system partition and try to boot \efi\boot\bootx64.efi

Since SecureDoc previously would not patch this file, pre-boot fails to load and Windows will load instead, which results in either an error 0x776d, as expected since this error is indicating that pre-boot failed to load, or a BSOD if the disk is already encrypted.  If pre-boot fails to load, there is no Encryption Key available to interpret the encrypted disk contents or to start encryption on a new installation.

Solution: When using the "patching" method, SecureDoc will now patch \efi\boot\bootx64.efi.  This will result in pre-boot successfully loading in the event that the UEFI bios is missing the “Windows Boot Manager” boot entry.  If the device defaults to using bootx64.efi, pre-boot will load instead, and will subsequently load windows after successful authentication.


SD-31460:  SES adds support for RedHat Enterprise Linux 7.7 version

In version 8.5, WinMagic has added support for RedHat Enterprise Linux 7.7 on physical servers


SD-31458:  SES adds support for Ubuntu 18.04.3 LTS version

In version 8.5, WinMagic has added support for Ubuntu Version 18.04.3 on Desktop, Server and Cloud-hosted Server platforms.


SD-31659:  Improve Key File "Slot" system in Windows client to ensure most-recent user Key Files remain on computer when new key files need to be added to a device where all slots are occupied.

Customers generally expect that the most recent users of a given SecureDoc-protected device will still be able to login to a given workstation using offline cached credentials.  Once the available Key File "slots" in SDSpace are used up (whatever the count), an issue was found where new Key Files were not being properly added or cached for offline use.

In this version, SES has improved this process, and this improvement will handle such situations as follows:

On the SES server, the "last logged on date/time" of each user is used to determine activity by that user on that device.  Once all slots have filled up and a new user needs to be added to the device, the new user's Key File will replace the Key File of that user who used the device the longest time ago (i.e. the user who used the device least recently) and is not in the first 10 slots.  "Preconfigured users" such as Challenge / Response accounts or permanent admin accounts will utilize the first 10 slots which are protected from being overwritten.


SD- 31216, SD-31415:  The OSA profile now permits use of a device Static IP address at Pre-Boot (similar to setting in Windows Device Profiles).

The communication settings in the OSA Device profile type now permits the Administrator to define that the OSA device may store and use the static IP address of the device when communicating with SDConnex at Pre-Boot. This has been an option in Windows Device Profiles for a while, and is now available for OSA device profiles.


SD-31380:  New Role-based Functionality has been added to SESWeb to permit Administrators to export Key Files to physical files.

A new Role Right has been added to match this new functionality.

NOTE: In order to ensure that upgrading SES does not provide lower-rights SESWeb administrators with rights they did not have before, this new right is disabled in all existing roles.
To provide this right to the desired Roles, enable the new right (called "Export Keyfile") in the Role's Rights Section.

NOTE: This new right is ENABLED by default for the top-level administrator role.


SD-31270:  SES V8.5 adds ability to search for devices by Bitlocker Recovery ID

As an aid when assisting users to unlock devices that are encrypted with Bitlocker managed by SecureDoc, a new search option has been added into the Device Search functionality that permits the Administrator to enter a portion (up to the first 8 characters) of the BitLocker Recovery ID, in order to more rapidly locate the desired device, in turn to access the Bitlocker Recovery Key.

This information is presented to the user when there is a recovery event, and by providing this information to the Help Desk it will expedite device recovery.


SD-31182:  SecureDoc for Mac FileVault 2 now adds Challenge-Response Recovery for RMCE-protected media and will prompt user to enter a new password.

Just as has existed in previous versions for the Windows version of the RMCE Viewer application, the Apple Mac version of this application now similarly permits users to perform Challenge/Response-based access recovery against Removable Media Container-Encrypted (RMCE) media in scenarios where they do not know the password that protects the media.


SD-31163:  SES V8.5 increases the number of Self-Encrypting Drives that SecureDoc OSA supports to 128

The number of supported Self-Encrypting Drive (SED) disks has been increased to 128 in SecureDoc OSA (OS-Agnostic) Client devices.

NOTE: Any non-SED drives detected will continue to remain unprotected since OSA has no software-based encryption functionality.


SD-31006:  New support tool has been added that clears all NVRAM-maintained SecureDoc Boot settings to ensure there are no NVRAM entries of a previous SecureDoc installation remaining in the device BIOS following a "bare metal" re-imaging of the device.

This tool cleans all SecureDoc NVRAM variables including, FBO, boot entries and drivers (SDDRV) so that after running, they can be sure that the BIOS NVRAM is "clean" prior to reinstalling SecureDoc.


SD-30838:  SecureDoc Pre-Boot Environment now shows what kind of Pre-Boot handler technology is being used on each device.

Issue: Customers may have devices that are not compatible with - or fail to launch - SecureDoc’s Linux pre-boot authentication (PBLU) and revert to using our UEFI native pre-boot authentication. It can be difficult for support personnel to know which is enabled on a device.

Solution: The Linux Pre-boot will now contain a text label of PBL or PBLU at the bottom left corner of the screen, indicating that the Linux based pre-boot authentication is enabled.


SD-30427:  Device Compatibility Test mode has been improved to automatically apply "Transfer Key using Persistent Storage" option if it detects that the default key transfer mode fails.

If the default key transfer mode fails, it indicates that transferring the key from Pre-Boot to Windows can only be achieved using Persistent Storage. The Compatibility test report will indicate that such a transfer must be included in the recommended settings for those devices where this solution is required.


SD-30821:  Improved method for collecting Pre-Boot Logs so that it does not require the use of USB media.

Issue: Complexities surrounding the capture of Logs during a PBU Pre-Boot (Pre-Boot for Native UEFI devices) had become a concern for customers, particularly where the only way to get the logs was through use of a USB stick.
Customers requested that it be possible to retrieve the pre-boot logs in windows where possible.

Solution:  PBU (Pre-Boot for Native UEFI) has been improved to save its log (defined at the logging level set in the SecureDoc Control Center) in the drive's system partition, and following boot to Windows the device will copy the logs to the UserData folder, where they can be aggregated (at the defined detail level) with the other logs when Support runs the log aggregation script.  For devices that possibly are failing to boot to windows, the process to obtain the log via USB memory stick remains the same, and in the case where a USB media is inserted with the WMUEFI.INI file present, the log will be saved to USB and not the system partition for that boot.

NOTE:  At this time, this solution is considered stage 1, affecting only PBU Pre-Boot on devices using software-based encryption.  WinMagic will continue to work on developing a similar improvement for PBL, PBLU and Hardware-encrypted drive logging in a future version.


SD-30491:  Support has been added for RedHat Enterprise Linux 8 (RHEL8) into the SDLinux installer.

This change will support RHEL8's new grub config (BLS), cryptsetup 2.0, and Python3 as the default version of Python language in RHEL8, which this improvement now supports.


SD-30091:  Protection has been made stricter for the contents of the UserData folder, barring users from deleting, moving or renaming files from this folder required by SecureDoc Client software.

In SecureDoc 8.5, permissions and file verification have been made stricter on all files in the userdata folder.
Users are still allowed to create and modify files in that folder, but they will not be able to rename/move/delete them. In addition, modifications for SD configuration files are still restricted for users and optionally (based on settings) for admins per profile configuration.


SD-SD-30057, SD-23822:  Add granular FileVault 2 un-installation options into the SES Device Profile to define behavior if FileVault 2 is uninstalled from a SecureDoc-protected device.

This new set of options (located in the macOS Enterprise Client Device Profile), defines how a SecureDoc-protected device should uninstall FileVault 2 if that operation is performed by an SES Administrator.
Please see the SES Administrator Guide for information on how to use these new options.


SD-29894:  SecureDoc for FileVault 2 on macOS can now suppress installation messages

Issue: Some customers indicated the number of messages that would appear during SecureDoc Installation on macOS client devices was excessive, and requested a means to suppress these as exists in the Windows client installer.

Solution: This improvement is included in this version, and installation messages can be suppressed by setting a new Profile value named “Suppress SecureDoc notification messages”


SD-29682:  The SecureDoc Profile and SecureDoc Client Control Center settings have been simplified, and now assume that where performing Password Synchronization, such synchronization will only apply where the User ID in Windows matches the User ID in SecureDoc.

The option to define that Password Synchronization would apply only when the Pre-Boot User ID information was the same as the Windows User identification previously was a separate checkbox in the Profile user interface in the SES Console.  Despite being a separate option, this option was the recommended option and one which virtually all customers opted to use.  This version eliminates the need to check a second checkbox; it now internally applies the same assumption of User ID equivalency for Password Synchronization to be applied.


SD-29389:  The RMCE Viewer application for macOS has been redeveloped in QT as a 64-bit application

The reworking/re-design of this application permits a more consistent user experience across Windows/Mac platforms, and will permit dynamic translation of the application into local languages. Please see also the details of the Windows improvements to RMCE Viewer.


SD-29311:  Add new Report View that shows Devices across Folders

Issue: Certain customers reviewing a large number of devices would benefit from a reference to which folder a given device resides in (particularly where devices can be placed in the Exempted devices folder for exceeding non-communication parameters).

Solution: Folder ID has been added to the Device reports.


SD-28487:  The speed of formatting USB Media using exFAT (to prepare it for RMCE Container Encryption) has been dramatically improved wherever creation of Encrypted USB Media involves formatting the media.

Note: This applies to Apple macOS devices protected with SecureDoc's management of macOS FileVault 2.

Issue: Customers needing to reformat USB Media using exFAT format had encountered delays in completing the exFAT format on devices protected with FileVault 2, such delays becoming particularly troublesome when using larger-capacity media.

Solution: In this version, WinMagic has dramatically improved this formatting process, reducing the USB device format time by approximately 90%, saving many minutes over previous times.

SD-28473:  SecureDoc for Mac FileVault 2 now adds Challenge-Response Recovery for RMCE-protected media

Just as has existed in previous versions for the Windows version of the RMCE Viewer application, the Apple Mac version of this application now similarly permits users to perform Challenge/Response-based access recovery against Removable Media Container-Encrypted (RMCE) media in scenarios where they do not know the password that protects the media.


SD-25648:  SESWeb now includes an Analytics Dashboard feature.

The bar graph representations for Devices have been replaced with a number of Pie-Chart and other graphics that customers should find to be more useful, in aggregate, than the old presentations had been.
NOTE:  This is preparatory to future updates to the reporting framework in SES Web.


SD-23290:  SecureDoc's EFI-based Pre-Boot now supports tabbing backward within the screen controls (fields, buttons) in the Pre-Boot Logon screen.

Earlier versions of SecureDoc's EFI-based Pre-boot (PBU) permitted tabbing forward between controls on the screen, but did not permit Shift+Tab to navigate backwards to a previous control.  In most cases this was a limitation of the system BIOS.  However, a way was found to improve this support across most devices.

NOTE:  Shift+Tab functionality is now supported to permit back-tabbing between controls, but may still be BIOS dependent.


SD-23287:  Smart Card Authentication has been substantially improved to no longer require that the Smart Card type be pre-configured in order to be understood by the device's Key File at Pre-Boot.

This improvement means that customers that change Smart Card type from one make/model to another will no longer encounter the complex process needed in previous SES versions, in which Boot Logon needed to know the token-type.

Benefit: This improvement means that even if users change to different smart cards, the existing key file will still work at Boot Logon as long as the new smart card has the same private key.


Resolved Issues

SD-32162:  macOS users using the Installme script in the Mac package to install SecureDoc were encountering issues where the script would kill all terminal windows, not just the terminal window under which the installer was running
Solution:  The scripted closure of the terminal windows has been removed from this script. 

Customers should now close the terminal manually after the installation has completed.

Alternatively, customers can change the terminal Profile Shell preferences settings panel, the option entitled “When the shell exists:” can be set to “Close if the shell exited cleanly”, which will cause the shell window to be closed automatically once the script has completed, as per the attached image.  

 SD 32162 Resolving Issues


SD-30822:  When using SecureDoc's Pre-Boot for native UEFI, after three failed logon attempts the system prompts the user to re-boot the device (to retry authentication), but the Reboot button does not have focus, and can only be accessed by using the mouse.

Issue: Following three failed login attempts, the Reboot button on the Native UEFI Pre-Boot Logon screen (PBU) did not receive focus, and could not be tabbed-to using the Tab/Back-Tab keys.  Without a mouse it would not be possible to reboot the device without a forced reboot or by powering off/on.

Solution: Focus is now on the Reboot button, so the user can press Enter or Spacebar to reboot the device.


SD-31928:  Devices unable to communicate to SES and which were installed using Offline installation would occasionally result in duplicated device and key records in SES database or in a failure to communicate

Issue: Under specific conditions, devices that encounter interrupted or incomplete communication with the SES server during SecureDoc installation could incorrectly assume the communication had failed completely. However, based on what was communicated, SES created an incomplete device record and key record.  The Device, assuming that communication had failed completely, would continue installing SecureDoc using the offline installation mode specified in the Device profile.  Upon its first successful post-installation communication with SES, a new device record may be created, or communication may no longer be possible without uninstalling and reinstalling SecureDoc.

Solution: This has been corrected in this version. Any incomplete device and key records for a given device are now deleted on first successful post-installation communication by the same device, and SES finds the previous record incomplete.  This enables registration to be re-processed successfully.


SD-30842:  SecureDoc's Pre-Boot Linux for UEFI (PBLU) 64-bit environment would crash whenever the Pre-Boot Browser would be invoked, for devices installed on VMWare.

Issue: Some customers rely on virtual environments to test Client functionality. This issue was detected only where the Pre-boot web browser is enabled in the profile, devices whose profile specifies PBLU would freeze/crash when trying to load using VMWare Workstation 15. This issue is specific only to PBLU 64-bit in combination with the Pre-Boot Browser being enabled. When the VM crashes, it produces an error message: "the CPU has been disabled..."

Solution: This issue has been corrected in SES V8.5.


SD-30819:  Use of non-zero values in the setting for Boot Idle Power off time, coupled with use of SecureDoc's Native Pre-Boot for UEFI devices (PBU), will cause devices so configured to not display messages indicating a failed login attempt and may similarly not display network connection messages.

Issue: When the system is configured for PBU AND if the Pre-boot idle timer value is set to anything other than 0, then PBU will not show the messages about invalid credentials or other errors encountered.

Solution: This issue has been corrected in this version (and a previous limited-release Hotfix), and now when the pre-boot idle timer is enabled, messages will be shown as expected at PBU.


SD-29710:  SecureDoc's Pre-Boot now supports Fixed IP addresses under Wi-Fi/Wireless Connection to the SDConnex Server.
Similar to the option to use Static IP addresses available in SecureDoc for Wired networks, SecureDoc's Pre-Boot now adds support for Wi-Fi/Wireless connectivity using a static IP address, which will be stored/re-used when connecting to SDConnex over a Wi-Fi network.

NOTE: To enable this, the SES Administrator must enable "Use Static IP Configuration from client at pre-boot." in the Device Profile to be used on the device (exactly as is used for fixed wired IP address use).


SD-29734:  Global options relating to Password settings now apply those settings across all existing Device Profiles

Issue: Customers expect that Global Options are applied globally, and the Password rules (defined globally) are actually deployed to endpoints and encapsulated in the Profile/Package files applied to those devices.  In previous versions, when the Global password rules were changed it was found that the installation packages previously created did not properly update those rules for application on future installations.

Solution: In SES 8.5, changing Password settings at the Global level will update all relevant aspects of all package settings.

NOTE:  Changes to the global password rules do not apply to existing deployed SecureDoc Clients.  This may be improved in a future version of SecureDoc.

SD-29732:  An issue has been found where some devices utilizing Opal self-encrypting drives would work for a period of time, but then would show error 0x8011 and/or 0x78011 at SecureDoc's Pre-Boot.

An issue has been found where devices utilizing Opal self-encrypting drives would work for a period of time, but then at some point after being rebooted would show error 0x8011 and/or 0x78011 at SecureDoc's Pre-Boot, blocking further access. If the user attempted to tap 'a' during start-up to access the Version 4 Pre-Boot, the device would show a 0x4480 error, and again access would be blocked.
 
It was determined that through use of WinPE the drive can be unlocked, after which it would be possible to access the SecureDoc Control Center application in Windows (after doing a warm-reboot).

Solution: This issue has been resolved.


Limitations

NOTICE: For Customers installing on Microsoft Surface Devices:

To install the SecureDoc Client software on Microsoft Surface Pro 1, 2 or Surface Book device types, use the standard SES Installer, with support for on-screen keyboard and external devices at pre-boot.

For installation on Microsoft Surface Pro 3, 4, Surface Pro 2017 or Surface Book 2, you must use the new Surface Installer (64- bit). This new installer supports on-screen keyboards and external devices at pre-boot.

Customers that utilize the Surface installer .EXE file (64-bit) must download this .EXE file from the links provided in Knowledge Base Article 1743, and then insert them into the SES Installer folder after installation or upgrade of SecureDoc Enterprise Server.

Please refer to Knowledge Base Article 1743 for instructions and further information.


SD-32232:  Upgrading ODBC from 17.1 to 17.4.1 will cause problems in accessing the SecureDoc Database.

This issue applies only to upgraded ODBC drivers.

Solution: Manually uninstall ODBC 17.1, and then manually install ODBC 17.4.1 directly. This problem does not occur following a full uninstall/reinstall, only where the ODBC drivers are upgraded in-place. This problem appears to be caused by issues in Microsoft's driver code.


SD-32052 - SecureDoc's BitLocker installation cannot perform initial Full Disk Encryption when the Pre-Boot and Windows System Partitions reside on different physical disks.


SD-29446 SecureDoc for Linux cannot be installed on a physical endpoint device when SecureBoot is enabled in the device.

Work-Around:  Disable SecureBoot on in Client BIOS/UEFI, and re-try the installation


SD-32321:  USB is not detected in SecureDoc Control Center (SDCC) following upgrade from macOS 10.13.6 to Catalina.

Cause: MacOS retains the old SecureDoc driver in the /Stagedextensions/ folder and the upgrade installer has no rights to remove or unload it during the upgrading process. Since the old driver is still in place, it cannot be replaced correctly by the new driver, and this is why USB media cannot be detected by SDCC.

Reason: This is an Apple limitation of macOS Catalina.

Work-Around 1: An option that can be used to avoid this issue:

1 - Upgrade to macOS Mojave first, and then to macOS Catalina.

Work-around 2: Use if this issue has already occurred:

1 - Boot the macOS device into the Recovery partition by rebooting and holding down the Command+R keys during macOS start-up.

2 - Remove the old SecureDoc drivers from folder Library/StagedExtenstions/Library/Extenstions/

Here is how to remove drivers in details:
1) - Use command <diskutil list> to find out the correct Volume. (Usually it shows operation system partition name and disk size will be approx. 10~11 GB, such as Macintosh and disk1s5)

2) - Use command <diskutil apfs unlockVolume diskNumber>. After providing the correct password, the disk should be unlocked and mounted. e.g. <diskutil apfs unlockVolume disk1s5>

3) - Use command to remove the driver under /Volume/VolumeName/Library/StagedExtenstions/Library/Extenstions/ folder, and both WinMagicSDFVFamily.kext and WinMagicComUnit.kext. e.g. <rm -r /Volumes/Macintosh\ HD/Library/StageExtensions/Library/Extensions/WinMagicSDFVFamily.kext>

4) - Reboot the device, and then log into system. The old driver should now be successfully replaced and SDCC will be able to detect inserted USB media.


SD-32361:  Windows RMCE Viewer application will show "Not Responding" status when using Container-encrypted exFAT USB Media created on macOS Catalina 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 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 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-32777:  BootLogon is shown while system is in Temp Auto-boot mode, when using the option to "Protect Auto-boot with TPM" option on Dell 7280 or 7480 with Hardware Encryption

Issue:  In SecureDoc 8.5, a new feature was introduced to allow the protection of the auto-boot keyfile by the Trusted Platform Module (TPM).

There is a known limitation on Dell 7480 and 7280, where this option to protect the keyfile by TPM is enabled and Hardware Encryption is applied. With this combination of HWE+TPM+Dell 7280/7480, the auto-boot keyfile is unable to be protected by TPM and pre-boot authentication is shown.

Root cause is not yet determined and WinMagic is actively investigating this issue.
Workaround 1:  Disable the option to protect Auto-boot keyfile by TPM
Workaround 2:  Use Software encryption on these devices in conjunction with the option to protect auto-boot keyfile by TPM.


SD-32837: Where a user has no rights to change his/her Password, it has been found that in V8.5 the user may still answer his/her Self-Help Recovery Questions.

Issue: The ability to set Self-Help Recovery answers acts as a form of authentication that remains in the user's abilities to set, but the user has been denied the right to change his/her Password, so should not be able to set personal answers for Self-Help Questions.

While versions of SES prior to V8.5 barred users from setting Self-Help answers if they did not have the necessary rights to set or change a password, in V8.5 it has been found that they can set Self-Help answers.
Work-around: None  
Impact: Low; Relatively few customers limit users abilities to set/change their own passwords.

WinMagic will correct this in a future version or Service Release

How to Install/Upgrade

Customers with an active support plan should contact support@winmagic.com to receive the latest download link for their SecureDoc upgrade. 

Contacting WinMagic

WinMagic
5600A Cancross Court
Mississauga, Ontario, L5R 3E9
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

Acknowledgements

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 - 2019 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. © 2019 WinMagic Corp. All rights reserved.

© Copyright 2019 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.

 Alles anzeigen Release Notes