SecureDoc v7.5 SR1 Release Notes

In this improvement, WinMagic has responded to a customer requirement that will ensure that no key files are available locally after the installation of SecureDoc 

This addresses a number of use cases i.e. servers, workstations, where administrators do not want there to exist ANY key files locally on the device, such that those devices will only be able to boot if connected to their secure network, for example by using SecureDoc's unique PBConnex AutoBoot. 

The security benefit of this improvement to customers is that it means if a computer (or drive) is ever stolen, there are no credentials on the computer that can be attacked, and it is completely impervious to any form of access without network access to its SDConnex server(s). 

This functionality already exists in SecureDoc's implementation policy settings available in V7.2 CloudVM, 

Note:  This feature ONLY affects the deploying user's key files during SecureDoc installation, thus if Windows Credential is turned on, key files can STILL be sent to the system. As well, key files can manually be added to the system from SES after the deployment process, so it does not block in any way the intentional or configured addition of User Key Files at a later point.

Change Key File deployment to support distinct use-cases including NO Key File, even in non-provisioning mode

Enables the use of the "Do not create and send down deploying user keyfile" option for installations that do not use provisioning mode, and further suppresses owner password dialog if installation has been performed without use of provisioning mode. 

This addresses the requirements of certain categories of customers whose main objective is that they do not want end-users to have key files on their workstations or servers – these systems will simply use PBN Auto-Boot to authenticate (much in the same way that SecureDoc’s CloudVM does not store local key files on the device).

The solution does not stage key files locally - but will continue with the product installation and initial encryption. 

Since the initial customer whose request triggered this change does not use password synchronization, they cannot use SecureDoc’s existing “automatic provisioning" feature, and this solution provides a smooth installation path even for such customers.

SD-23267
SD-24226

Integrate the new FESF library Version v1.2.3 into SecureDoc File Encryption (SFE) 

Issue: The underpinning development tool used in SecureDoc File Encryption has been upgraded to version 1.2.3 in this version of SecureDoc. 

Version 7.5SR1 incorporates an updated version of the third-party library that underpins the SecureDoc File Encryption (SFE) functionality, which has eliminated a number of issues and limitations that applied to earlier versions of SecureDoc SFE.

Limitation:  SFE also does not support encrypting SharePoint folders (SD-23982).

SD CloudSync now supports running on top of SecureDoc v7.5 and later versions

Automatically convert Key Files to TPM protection (if so configured) without requiring the user to log into SecureDoc Control Center (SDCC) first. 

In earlier versions of SecureDoc, where TPM Protection is configured the user was required to log into SDCC in order to have their key file converted to be TPM-protected. 

This has been improved in 7.5 SR1, and the user's key file is now automatically converted to TPM protection upon logging into Windows.

SD-23614
SD-23653

Issue corrected: Error type 0x7885 logged during SecureDoc client software installation. 

Larger customers having a high degree of device sharing or large numbers of users per device have encountered issues during installation of SecureDoc.  This was due to the large number of Key Files being sent to these devices during installation, which would cause an overrun issue, and result in the installation failing with error message 0x7885. 

WinMagic has corrected this issue by sending a limited number of Key Files during initial installation, then "catching up" on the remaining Key Files subsequently (post-installation), eliminating the overrun condition that caused error 0x7885.

USB Media:  Removable Media Container Encryption media size warning message improved. 

Under the FAT32 File System, USB sticks can support files that are a maximum size of 4GB. Since the SecureDoc RMCE Container is actually a file, any USB media that exceeds 4GB in total size will not be able to have an RMCE container created on it that will use 100% of the available space. This 4GB file size limitation does not apply to exFAT or NTFS-formatted USB sticks. 

The warning message regarding this has been improved and made clearer; it guides users to:

a) Cancel the Container creation and b) reformat the media as exFAT. 

This warning is intended to protect the user, avoiding the risk that continuing to use the existing FAT32 format would yield a 4GB container within an 8GB, 16GB or larger FAT32-formatted USB stick, leaving much of the stick's capacity unprotected, and helps customers avoid the risk of users inadvertently storing at-risk documents in unprotected space within the media (e.g. outside the encrypted Container).

New ability to suppress incremental (aka Delta) ADSync

Issue: One customer had encountered a problem when performing partial (delta) ADSync updates when their AD was working as a proxy to an LDAP source located elsewhere. 

A previous work-around for this issue had been to avoid the use of partial ADSync, and to perform only Full ADSync. Unfortunately such a work-around did not work well in larger Active Directory environment (above 50,000 Users, 20,000 Security Groups), so a more robust solution was sought. 

Solution: Through a change to the ADSync settings, the nominally hourly-based partial ADSync behavior can be suppressed completely if desired, leaving customers that require this to run only a Full ADSync on a daily basis. 

Note:  This option may not be of interest to the majority of customers since most customers will not have the unusual AD/LDAP configuration that precipitated the need for this new option.

Touch controls at pre-boot (PBLU) have limitations on MS Surface Pro 4 and 2017

The touch controls do not work on MS Surface Pro 4 and 2017 when pre-boot is configured to use PBLU 64-bit. As a workaround, it is recommended to use pre-boot (PBU) for these devices until a solution is available.

PreBoot Logon GUI supports any screen resolution 

SecureDoc’s Pre-Boot logon screen now self-adjusts to any screen resolution.

SDFileDecryptor - Improvements to the decryption workflow for better User usability 

Issue: Context menus for the SDFileDecryptor application have now been enhanced to include new options:

- Decrypt with SDFileDecryptor Here – This option decrypts the specified file and into the same folder. 

- Decrypt with SDFileDecryptor To – This option offers the user an option to choose a destination folder location and decrypts the file into the chosen location. 

- The application’s Context menu registration will be executed on every application start up (permitting the application executable to be moved by the user). 

Password prompt window: 
- If files to be decrypted are specified through the use of a command line (e.g. Context menu call) and a password was not specified, a password request prompt window will be displayed, requiring the user to enter the password. 

Package: 
- SDFileDecryptor.exe is a self-contained file for easy transfer. 

Note: SDFileDecryptor.exe was improved to support a context menu on Windows Server 2012. To enable the menu on Server 2012 OS (and possibly others), this application should be started by an admin user at least once. 

SD-23909
SD-23980

SecureDoc File Encryption (SFE) now supports Windows 10 RS3 

For customers deploying SFE to Windows 10 RS3 devices, SFE v7.5 SR1 and above must be used. 

Note: If using an earlier version of SecureDoc with SFE enabled on Windows 10 RS3 device, a possible Halt Error (BSOD) can appear when logging into Windows.

SecureDoc compatibility with Windows 10 RS3 added

SecureDoc V7.5SR1 is compatible with both Windows 10 RS3, as well as when upgrading Windows 10 RS2 to RS3.

SD-24506
SD-23446

Visual Improvements for masked password fields for SES Web  and SES Consoles

Issue: There has been an inconsistency in previous versions of SES and SESWeb between the way the SES Console and the SESWeb console represent the non-existence of a user's password. 
In the SES console, when a user does not have a password, the password field is shown as empty, whereas the SESWeb console would show a series of masking dots which would provide the viewer with the mistaken impression that SES has stored a password for that user. 

This has been corrected in V7.SR1, and where users do not have a stored password, both consoles will display this congruently by showing an empty password field. Where a user does have a stored password, both will congruently reflect this by displaying a set of masking "dots".

SecureDoc OS-Agnostic (OSA) Windows installer and OSA USB do not boot when Secure Boot is enabled

Issue:  On a UEFI System, the system cannot load Boot Logon after installing the OSA installation package from the Windows Installer or a USB Boot device. In a previous version, SecureDoc was using a non-signed EFI application (GRUB-based) to run the OSA Installation. As a result, since non-signed, it could not run if Secure Boot is enabled.
 
Note: The system and BootLogon works properly when disabling Secure Boot.

SecureDoc Utility (SDUTIL) did not correctly support the RemoveBL option under PreBoot Logon/V5 profile settings

Issue: Customers running V6.5 were unable to successfully remove Boot Logon when executing the command to remove SecureDoc’s Boot Logon from a V5 boot logon device.  Under this issue, once the command was executed, the device rebooted but the V5 Boot Logon had not been removed.

This issues is now resolved.

Note:  The feature only works on already-decrypted Software Encryption (all disks have previously been decrypted but BootLogon still remained in effect). Preboot will check if the disk is a plain text regular drive. If not, it will just return without removing boot logon.

Errors occurred when client devices having a large number of local Windows user accounts would register with SecureDoc Enterprise Server, causing a high volume of key files to be transmitted from SDConnex for the Local Windows Accounts

Issue: This occurs when the Profile option "Windows Account Feature - Create Boot Users + Personal keys" is enabled. This option allows SES to create NEW key files for all Windows users that have logged onto the computer. However, if there are a lot of users that have logged into the computer then the key file requested from SES can generate an unusually high volume of key file requests.  SDConnex may not be able to handle this large request set, i.e. 40 users or more. In this scenario, the installation fails during device registration and error 0x7885 is generated.

This issue has now been resolved.

Note:  Total AdminUser + WinUser amount should not exceed 32.

Microsoft Office Installation failed when SecureDoc File Encryption (SFE) is enabled

In a previous version, WinMagic had included a Limitation that required customers to install Microsoft Office before installing SecureDoc (or disable SFE temporarily in order to install Microsoft Office) if the SecureDoc File Encryption feature was to be enabled on the devices, since in that version the version of the third-party encryption library on which SFE depends conflicted with the Microsoft Office Installer. 

This limitation has been eliminated, as SES Version 7.5SR1 now utilizes an updated version of this third-party encryption library that does not cause this compatibility issue.

Under certain circumstances relating to high numbers of local User accounts on devices, those devices were being duplicated in the SES database upon Installation, with a failure to submit the SDForm prompt panel

This issue is associated with SD-20687, since its effects are derived from SecureDoc’s handling of generating multiple key files. 

Issue: On the client side device registration does not complete because SecureDoc has a built-in MAX_ADMINS_IN_PCKG=32 setting, which would cause issues in case there are more than 32 in the client device.  The registration process re-generates a unique ID in case a computer is already registered on SES. This results in duplicated devices and endless loops that lead to registration failure. 

This issue is now resolved.

In KeyFile Deployment, Excluded user key files were still being created even though the rules defined they should not be

Issue: User Key Files were being created for users defined in the Exclude List feature. 

This has been corrected. Users in the Exclude List will no longer have Key Files created for them.

Timing improvements made to permit SecureDoc Client to update information in SED Shadow MBR more dependably.

Improvements were made to the Shadow MBR synchronization sequence on SED’s during the User’s initial login process to the operating system, ensuring that SecureDoc can update information in the Shadow MBR during boot-up. These improvements resolve several rare cases seen during the Secure Moment process of the deployment where the temp user account was not being removed from the system – and the device would remain in provisioning mode.

Profile status column displays incorrect information

Issue: In an earlier version, SES would take the “optimistic” path, and would prematurely mark Profile changes as having been successfully applied to devices based only on having transmitted the new profile to the device, and would show the Profile on the device as Up-to-Date. While reasonable, under this older method the status column setting could in rare circumstances be out inaccurate since it did not positively know the status of the profile change at the device.  The device had not had a chance to confirm that it had successfully processed that profile change, leading to the rare possibility that any issue on the device itself in applying the new profile would not be visible at the server.

This has been corrected. As usual, the Profile's Out-of-Date flag is set by changing the Profile, so the existence of a more up-to-date profile on the Server will mean that all clients having that profile are out of date.

Under this improvement, Client devices will now positively confirm back to the server that they have successfully applied the changed profile, which will then actively update their Profile setting to "up-to-date" upon next communication with the server.

Microsoft Surface Pro 3 and 4 devices were unable to access dongle-connected or dock-connected Network Interface devices at SecureDoc's Pre-Boot for UEFI devices

Issue: By default the UEFI network stack is disabled on MS Surface Pro, Book and later devices to improve boot performance. For such systems deployed with SEMM (System Enterprise Management Mode) there is a hidden setting to enable the network. 

This issue has now been resolved: SecureDoc will enable the UEFI network stack programmatically so that PBConnex-brokered authentication can be used at Pre-Boot on these devices.

SDPin crashing on resume from sleep mode

Issue:  In version 7.1SR6 HF1, SecureDoc’s WinPin (SDPin) service crashed on SecureDoc’s Bitlocker Management (SDBM) after resuming from Sleep mode.

This issue is now resolved.

Note: The Issue was caused by Security Software that managed Windows rights which has now been removed. Changing the security settings from High to Medium when monitoring the SecureDoc application resolved the crash.

Error recognizing smart card with an internal reader

Issue: When logging in with the incorrect key file using an internal smart card reader it doesn’t work correctly. The issue doesn’t occur with an external smart card reader along with the existing smart card. The end user can successfully log into the system.

This issue is now resolved.

Microsoft Surface Pro 3 and 4 devices were unable to access dongle-connected or dock-connected Network Interface devices at SecureDoc's Pre-Boot for UEFI devices

Issue: By default the UEFI network stack is disabled on MS Surface Pro, Book and later devices to improve boot performance. For such systems deployed with SEMM (System Enterprise Management Mode) there is a hidden setting to enable the network. 

This issue is now resolved.

SecureDoc will enable the UEFI network stack programmatically so that PBConnex-brokered authentication can be used at Pre-Boot on these devices.

Added Support for Solarflare SFC9240 Network Interface Card (NIC) at preboot 

Issue: Native Linux driver doesn't support a new network interface card (Solarflare SFC9240. Vendor ID: 1924, Device: 0A03). 

This issue is now resolved.

Customers must replace the native Linux driver with the one downloaded from the manufacturer's download page. 

Note: SecureDoc’s Pre-Boot for native UEFI (PBU) is still incompatible with the Solarflare SFC9240 Network Interface Card.

User accounts listed in the Installation Package settings in SES were being removed when saving the Installation Package after a 7.5 upgrade 

Issue: Once the installation package has been created with added user accounts, those user accounts were being deleted when recreating the installation package under V7.5. The profile package synchronization was not functioning correctly in cases when the User does not edit the package explicitly (e.g. the installation package was not re-opened for editing, and then saved) 

This issue is now resolved. 

Note: The issue only occurs when the SQL database has been updated from previous versions. If the database was created fresh with the same build, this issue will not occur.

Surface 2017 issue: Uninstalling through Control Panel does not work

Issue: When testing the un-installation of the SecureDoc Client software on Microsoft Surface Pro 2017 devices having the latest firmware, it was found that by un-installing SecureDoc through the Windows Control Panel, the process would fail to complete successfully, and thereafter the SecureDoc software could not be uninstalled. 

This has been corrected, and SecureDoc can now be successfully uninstalled from these device types.

User permissions on devices are inconsistent with server settings and are overwritten incorrectly

Issue: User permissions on devices are inconsistent with server settings and are being overwritten at various times, and permissions inherited from groups are not always applied.  Admin permissions are not added if user's keyfile already exists on a device and admin permissions are removed when the KeyFile is updated. 

This issue is now resolved.

The SES Console displays calculated effective permissions alongside with permissions directly assigned to a user or a user-device. This way administrator can see in real time what effective permissions the user will get on the device any time a keyfile is updated.

Permissions directly assigned to user-device combination will no longer override everything else as it is in current non-PBN scenario. As a result, Users will automatically get permissions from their groups and it will not be possible to selectively deny inherited permissions on User devices.

Unable to set TPM2.0 protection on Panasonic device (CF-SZ6)

Issue: On the Panasonic CF-SZ6 type devices, when the TPM option profile is enabled, the PC user account (keyfile) doesn’t change to TPM protection after login to SecureDoc's Control Center (SDCC), and also the SES console ‘Keyfile Protection Type’ for the Device does not change the user's authentication type shown in the Console to “Password + TPM”. 

This issue has been corrected, and user key files will now be set to use (and display) "Password + TPM" for Panasonic CF-SZ6 type devices.

SecureDoc's Pre-Boot management for BitLocker  (SDOT) Boot Logon does not override users from running BitLocker

An issue was detected in SecureDoc Version 7.5 where installation of SecureDoc's Pre-Boot management for BitLocker (SDOT) no longer blocks user access to the Bitlocker Management user interface. This access had been blocked in the earlier 7.1 SR5 and SR6 versions. 

This issue impacted Windows 7, but may impact other operating systems. 

Solution: The installation of SecureDoc to manage Bitlocker will disable access to Windows' own Bitlocker management tools through registry changes when SDService starts up, and access to these tools and registry settings will not be reinstated if Bitlocker is removed.

Unable to update user passwords from the SES Server where the same user existed on more than 100 devices

Issue: Limitation on updating Users that have more than 100 Users or more devices. Such as updating the password on the SES Server, the information was not updated accordingly and clients were not able to log on.

This issues is now resolved.

Tablet touch-screen  calibration during SecureDoc Installation causes issues

Issue: During installation touch screen function doesn’t detect at the Calibration process, which keeps the User from being able to complete the installation successfully.

This issue is now resolved. Eliminate double definition, users will now be able to successfully calibrate their fingertip use of the touch screen and then proceed to Boot Logon.

Unable to change User's password with SESCMD when the user has a '@' symbol in their username 

Issue: There's a built-in parsing function which separates user@domain into two parts, stripping the last @ symbol. 

Work-around: Try the non-parsed name first.  For Example, if there are Users "abc" and "abc@", and the parameter is "abc@", then abc@'s password will be changed. 

Removable Media Container Encryption (RMCE) and Disk Access Control (DAC) issues occur if an encrypted device is opened in Windows Safe Mode

Issue: When customers boots a SecureDoc-protected device into Windows' Safe Mode, SecureDoc’s SDPin agent is not operational anymore and due to this, the auto-encryption RMCE policy is not working properly. 

Work-around: Join PinFile to the Safe Mode driver pool. SdPin.exe does not run automatically in SafeMode but Disk Access Control (DAC) should be enforced. 

Sharepoint’s “View in File Explorer” option does not work with SecureDoc File Encryption (SFE) enabled 

Issue: When Users attempt to view Sharepoint site documents using Internet Explorer with the "View in File Explorer" option enabled, an error message would appear indicating “Your client does not support opening this list with Windows Explorer” when SecureDoc is installed. 

Work-around: Use a newer version of FESF driver’s v1.2.3 and higher from OSR 

Note: Turning off SFE in the policies resolves the issue with the “view files in Explorer” option in SharePoint. 

WinPin (SDPin) crashes after resuming from Sleep mode

Issue: This was caused by Security Software that managed Windows rights and removed them. 

Work-around:  WinMagic lowered the security setting from High to Medium when monitoring the SecureDoc application and that resolved the crash

SD-23702

Atos CardOS DI 5.3 - No private key in token 0x7730 with certificate length 2048

Issue: Customers testing use of the Atos CardOS DI 5.3 card found that it doesn’t work with 2048 bit certificates, but does work with 1024-bit certificates (which are no longer used). With 2048 bit certificate length, an error (0x7730, No private key in token) occurs at pre-boot Atos CardOS DI 5.3 card provided doesn’t work with 2048-bit certificate. The security standard now is 2048 or 4096-bit.

Work-around: The smart card requires longer APDU. When APDU is longer than 255 bytes the smart card requires APDU length one byte longer. Limitation: 4096-bit certificate length (4k) is not supported at the moment.

SecureDoc File Encryption feature (SFE) will NOT encrypt files located on a SharePoint folder when the SFE policy was created on the Client device.

Limitation: SecureDoc File Encryption does not currently support the encryption of WebDAV paths, which is what SharePoint shares are.

Under SecureDoc File Encryption (SFE), customers have encountered an issue where overlay icon would not appear when mapping a network connection to DFS (Windows Distributed File System) 

Note: If using a FQDN path, this problem does not occur and the green overlay icons appear as expected.

Black screen on SecureDoc Linux-based Boot Logon affects certain device types (see below)

Issue: After installing SecureDoc's Linux-based Boot Logon (PBLU) on an HP X2 210 G2, the system remains at a black screen 

Limitation: Until a solution can be found, this device type will require the use of a Device Profile that specifies SecureDoc's Native Pre-Boot for UEFI devices (PBU).

Hewlett Packager HP Pro x2 612: Touch screen does not work under SecureDoc's Linux-based Pre-Boot For UEFU devices (PBLU)  

Note: The Touch-screen does work under SecureDoc's "Native" Pre-Boot for UEFI devices (PBU) 

Pre-boot authentication screen delay on Dell E7250 system

Limitation: There have been cases reported in which the pre-boot authentication screen has taken 10-15 minutes to appear on the Dell E7250 system.

The external mouse does not work on Lenovo T570 with PBU 

Limitation: The external mouse does not work at pre-boot when using PBU on Lenovo T570 devices. The touch pad is required for mouse cursor functions.

Pointer functions at pre-boot (PBLU) do not work using the touch pad 

Limitation: The mouse controls do not work on the Dell E7450 using the built-in touch pad. It is recommended to either use PBU on these systems or use your external mouse device.

HP ProBook 645 G3 (HWE) - Windows error (0xC0000411) appears after returning from hibernation mode 

After performing a series of sleep, wake-up, hibernate, and warm restart operations on the encrypted platform, several times a Windows error (0xC0000411) was seen upon logging into Windows from hibernation. 

Work-around: Shut down the system and re-authenticate. 

Note: For systems using hardware encryption, it is recommended that users perform full power down, and not warm restarts. 

Additional implementation protection for WPA2 KRACK vulnerability in PB Linux

After undertaking an assessment of risk for our SecureDoc customers, WinMagic is advising that while KRACK does impact our pre-boot wireless support because SecureDoc uses standard Linux Wi-Fi drivers, the risk is mitigated by the fact that PBConnex runs an encrypted protocol on top. Nevertheless, WinMagic has provided additional protections in this SecureDoc 7.5 Service Release 1 (SR1).

SecureDoc customers using Pre-boot UEFI mode (PBU), or not using pre-boot WiFi networking, are not affected by this vulnerability. 

HP Folio 1040 G2 touch screen unavailable

Issue: The touch screen at pre-boot (PBU) does not work on this device.

Limitation: The on screen keyboard controls do not work on the HP Folio 1040 G2 using PBU. It is recommend either using PBLU on these systems or using your external mouse device.

Pointer functions at pre-boot (PBLU) do not work using the touch pad

Limitation: The mouse controls do not work on the X260 using the built-in touch pad.  It is recommended to either use PBU on these systems or use your external mouse device.

Atos CardOS DI 5.3 - No private key in token 0x7730 with certificate length 2048 

Issue: Customers testing use of the Atos CardOS DI 5.3 card found that it doesn’t work with 2048 bit certificates, but does work with 1024-bit certificates (which are no longer used). With 2048 bit certificate length, an error (0x7730, No private key in token) occurs at pre-boot 

Atos CardOS DI 5.3 card provided doesn’t work with 2048-bit certificate. The security standard now is 2048 or 4096-bit. 

Work-around: The smart card requires longer APDU. When APDU is longer than 255 bytes the smart card requires APDU length one byte longer. 

Limitation: 4096-bit certificate length (4k) is not supported at the moment. 

SD-24541

Features for tablet does not correctly work with SecureDoc’s Linux-based Pre-Boot for UEFI devices (PBLU)

Issue: The touch pad, mouse track, and on-screen keyboard do not work with PBLU for ThinkPad X1 Tablet 2 model.

Lenovo ThinkPad X1 Carbon 5 devices encounter a SecureDoc Linux-based Pre-Boot error, failing with a "Bad Address" error when using Windows 7 and Hardware Encryption (e.g. SED drives)

Lenovo ThinkPad X1 Tablet 2 issues:  Touchpad, mouse track, and external mouse do not work at SecureDoc’s native UEFI Pre-boot (PBU)

Issue: The touch pad, mouse track, and external mouse do not work on the ThinkPad X1 Tablet 2 in SecureDoc’s PBU (native Pre-Boot environment for UEFI devices) during pre-boot authentication

Workaround: For the ThinkPad X1 Tablet 2 device, please use the on-screen keyboard to login at pre-boot authentication.
Alternatively, the external keyboard can be used with configuring pre-boot using SecureDoc’s Linux-based Pre-Boot for UEFI Devices (PBLU).