SecureDoc v7.5 Release Notes

Version 7.3 Features, Improvements included in this document

Version V7.3 contained a number of improvements and new features. 
However, V7.3 was released for a very limited customer audience while V7.5 continued to be developed. 

Rather than asking customers considering V7.5 to review the list of V7.3 improvements in a different source document, since these improvements are also included in V7.5 they are repeated here:

NEW FEATURES in 7.3/7.5:

• SecureDoc File Encryption (SFE) now supports latest version of DMK (FESF v1.1). This version addresses many incompatibilities the older SFE version had with application conflicts.

• Encrypted files now display a lock overlay icon directly on the file – for better user experience to know the state of the encryption: Green icon shows that the file is encrypted (and the user has the correct key) and the Red icon shows that the file is encrypted (but the user does NOT have the correct encryption key).

• Network folder encryption policies now support built-in monitoring from SFE agents – to make sure that all files copied into the SFE protected network folder are automatically encrypted

• Improved (local) logging is available for SFE that helps determine why files are not being encrypted, i.e. due to file permissions, etc.

• Users must have full local SecureDoc privileges on the device in order to remove SFE folder policies that were deployed by SES

• Password rules are now applied within the SFE Context Menu

IMPROVEMENTS AND FIXES in 7.3/7.5:
SD-4354 - Network folders that have more than 800 GB of data can be successfully encrypted

SD-18264 – Performance issues found when closing Excel files that are encrypted within a folder on a NAS

SD-13418 – Fixed a crash issue in Windows 10 when a PDF file was opened by a Metro Application

SD-14038 – Resolved an issue with File folder browsing being slow on Internet VPN connection when SFE is enabled on the client

SD-15747 – Improvement to the time it took to copy large files (Mail Data) to an encrypted folder – compared to a non-encrypted folder

SD-18345 – Resolved an issue with the environment variable for not working when the policy was deployed from SES

SD-19569 – A symbolic link issue with non-Windows operating systems was resolved

SD-20569 – SFE now supports encrypting folders on servers that names start with a number

SD-15628 – SFE now supports using IP addresses instead of the server name for network folder policies

V7.3 LIMITATIONS FOR SFE CARRIED FORWARD INTO V7.5: (See limitations section, later in this document).

SecureDoc File Encryption (SFE) was unable to file-encrypt the contents of the user’s temporary folder when the SFE policy used the <User temporary folder> environment variable

An issue had occurred on a previous version (that had worked correctly in V7.1) in which SFE policies did not correctly file-encrypt the user’s Temporary Folder (defined in the SFE policy using the Environment variable <User temporary folder>)

This corrects that issue that and reinstates the expected functionality, so that an SES SFE policy can once again be applied to encrypt the user’s Temporary Folder (defined using the Environment variable <User temporary folder>

SD-14882

To prevent against possible server component incompatibilities, SES now checks and prevents an older SES version from connecting to a new version of the SES database. 

From SES V7.5 onward, a message prompt will appear to the SES administrator advising the current SES version currently installed is older than the required version to connect to the database. 
This will be of particular value for SES environments where there may be multiple SDConnex servers, or where Administrators have the SES Console installed on their own desktops, helping to ensure that all elements will be upgraded to match the current Database version.

This improvement will prompt users to upgrade SecureDoc components to the required newer SES version, including SES console, SDConnex, and ADSync.

Under either SecureDoc for FileVault (SDFV2) or SecureDoc's new Pre-Boot for FileVault 2 (SDOTFV2), the SES console now allows administrators to send a remote command to Mac clients to update the FileVault 2 Recovery PIN (Personal Identification Number). 

After performing a password recovery, SES admins can now easily update the FileVault 2 recovery PIN on the device by right-clicking on the Mac device and selecting the “Change SDOT FV2 Recovery Password” option.

Overtake System Integrity Protection (SIP) function on Mac devices running macOS from version 10.11 onward

SIP System Integrity Protection is a security technology in OS X El Capitan (10.11.x) and later versions, designed to help prevent potentially malicious software from modifying protected files and folders on your Mac.

This fix ensures:
1. Fresh install of SDOTFV2 or upgrade from SDFV2 to SDOTFV2 on Mac having SIP enabled will work; also upgrade from older Mac OS to El Capitan (10.11.x) or Sierra (10.12.x) with SDOTFV2 installed will work.
2. Remove WinMagicBootSDotFV partition from internal list disk after removed SDOTFV2.

Permanent limitations:
After performing minor OSX Yosemite (10.10.5) upgrade, it reboots directly to WinMagicRecoveryAccount login page instead of SecureDoc pre-boot. This issue may also happen on El Capitan, Sierra especially from an earlier point upgrade such as 10.11.1 to 10.11.6 latest build etc.

Work-around: After completing the upgrade process for OSX, device may automatically boot to WinMagicRecoveryAccount login page instead of SecureDoc Preboot.  At this moment please apply the following steps:
1. Click Restart, then it will boot to SDOTFV2 Preboot.  After typing User ID and password, it will boot to system and work normally.
2. If the above reboot still boots to the WinMagicRecoveryAccount login page, please enter password and login. After login, it will automatically prompt countdown dialog.
3. After rebooting, you’ll be able to see SDOTFV2 Preboot.

Support has been added for the Crescendo C1300 smart cards from HID

SecureDoc now supports the HID Crescendo C1300 smart Card

Note: SecureDoc only supports HID Crescendo C11xx smart cards that have PIV profiles. Customers will have to use the advanced diagnostic features of ActivClient middleware to add the PIV profile to their smart cards.

SES Administrators can now centrally manage profile updates for OSA clients

SES Administrators can now centrally manage and modify profile options for OSA clients.  Upon the OSA client restarting, or while the OSA client is at pre-boot, the client will check back with the server to detect updates.  If new updates are available, the client will receive and enforce the new changes right at pre-boot.

Supported OSA profile functionality include:  PBConnex server address information, Boot Text and Color, WiFi settings, Keyboard Layout, General Boot Configuration, and several Boot Configuration settings.

Note:

• PBA background image changes are not supported through the update
• Profile update can be applied only after device restarts (device must be rebooted for new profile to take effect).
• Updating BOOT_PARAMETERS is not yet supported because the boot loader cannot read the SED Data store.
• Updating Preboot Web Browser URL is not supported because there is no trusted certificate sent down from SES currently.
• Updating Wireless Router configuration is not supported.

Under either SecureDoc for FileVault (SDFV2) or SecureDoc's new Pre-Boot for FileVault 2 (SDOTFV2), a new Mac profile option called “Allow SecureDoc uninstall by a SecureDoc user with admin rights or local administrator” is now available

This new option enforces whether or not a local Mac administrator account is authorized to uninstall SecureDoc FV2 protection from the Mac device.

NOTE: This enforcement control is not supported centrally supported through sending a Mac profile update from SES.  This control can only be updated through a new Mac client install or client upgrade.

New BitLocker Tamper Protection policies are now available within the SecureDoc client to enforce against unauthorized disabling of these security controls

There are 3 enforcement controls available:

•  Block access to Manage-bde.exe.  By preventing this application from running, most BitLocker controls won’t be accessible, i.e. Decrypt BitLocker, Suspend Mode, and others – even via power shell scripts.
• Enforce Suspend Mode from being enabled.  SecureDoc monitors BitLocker Suspend Mode – and if BL Suspend Mode is enabled - SecureDoc will alert the user of this unauthorized action, log this event locally and send back to SES.  SecureDoc will immediately DISABLE BitLocker Suspend Mode without requiring a reboot.
• Continuously managing and controlling BitLocker Drive Encryption Status.  The SecureDoc client will continuously monitor the BitLocker encrypted state.  If a user or process start the BitLocker decryption process, SecureDoc will automatically start the decryption and revert back and start encryption without requiring a reboot.

Memory leak corrected, detected on  devices that had upgraded from 6.5 SR1 to 7.1 SR6 HotFix 1

Customers had notified WinMagic that after having upgraded devices from SecureDoc v6.5.1.17 to v7.1.501.93, their users had reported significant performance issues.

This has been corrected in this version, and customers experiencing this issue are requested to upgrade to this version of the client software.

SES V7.5 introduces a new  ability to configure a specific SDConnex server to handle  scheduled tasks, rather than having all SDConnex servers effectively trying to handle scheduled tasks concurrently

Under this new feature, it permits a single SDConnex server to handle scheduled tasks, rather than having each of several SDConnex server’s attempting to handle that workload (and potentially colliding on their attempt to perform those).

This improvement will automatically enable each SDConnex server to handle scheduled tasks (since many smaller customers may have only a single SDConnex server, it will guarantee that these scheduled tasks will continue to be performed).  However, for customers having multiple SDConnex servers, WinMagic requests that they determine which of their SDConnex servers should handle scheduled tasks, and then should turn off that feature on all other SDConnex server.

The change to the SDConnex configuration User Interface is that there is a new option entitled: "Enable scheduled tasks".

NOTE:  At the time that the initially-shipped SES User Guide was completed, this feature was not included in that document, and early adopters of V7.5 will not have this feature covered in the documentation (this will be repeated in the Limitations section).

WinMagic recommends that V7.5 early-adopter customers should re-download the SES User Guide (from the same link as was originally used) within a few weeks of initially downloading it, in order to ensure they have the most up-to-date version of the SES User Guide (the Administrator’s primary manual).

SecureDoc’s Pre-Boot for FileVault 2 (SDOTFV2) will change Apple macOS sleep/hibernation mode from 25 to either 0 or 3

SecureDoc does not have support for macOS sleep/hibernation mode 25, so where devices are currently defined with hibernation mode 25, depending up on device model, installing SecureDoc’s Pre-Boot for FileVault 2 (SDOTFV2) will automatically change the device’s sleep mode from 25 to either 0 or 3.

SecureDoc now has support for macOS 10.12.5 and 10.12.6

[DAC] Improve SD to not prompt message to encrypt plaintext portion of SD RMCE USB drive

When the SecureDoc Disk Access Control policy is configured to "Read Only Unless Encrypted" for removable media, and a customer plugs in an unencrypted USB drive, he/she would expect to get a message stating that the drive cannot be written to unless encrypted. This is by design.

This improvement corrects an issue where:

• Having container-encrypted said USB drive using SecureDoc RMCE method and
• Having unplugged the drive, then
• Upon plugging the drive back into the computer (although the container mounts and all is accessible), then
• The user would still get a pop up message referencing the unencrypted portion of the drive (e.g.  D :) where the media viewer is located and has as little as 0 bytes free space.  

SecureDoc would incorrectly detect that this drive has some unencrypted space on it (which it would see as a risk), rather than recognizing that the drive had been correctly container-encrypted and is effectively fully protected.  

This improvement now will only display this message if the Container does not effectively use all the available space on the USB media (e.g. if the container occupies < 100% of free space, leaving a non-trivial amount of unprotected space, then the message will appear).

SD-23030

Windows client deployment issue:  If a non-AD user has a password stored in SES user record, but customer then deploys a device to a Domain user having the same User Name but a different password, the device does not transition to “Owned” state and remains in Provisioning state.

WinMagic has introduced a pre-boot install method which doesn't modify NVRAM UEFI Boot Order mechanism for devices equipped with Self-Encrypting drives (e.g. Opal SED)

WinMagic has introduced a general improvement to ensure that Self-Encrypting Drives boot stably in UEFI device environments where Boot Order can be altered. 

This reflects/mimics the Shadow MBR so it has the same layout as the Disk Layout.

SD-23374 and SD-23410

Migration for Profile updates – New Profile option permits Hiding or showing the Microsoft Bitlocker Preboot Logon screen

The SecureDoc Profile now will have a new Attribute – BitLockerHideLogonScreen

This option defines whether the native Microsoft BitLocker Pre-Boot MS Bitlocker Preboot is to be:
Hidden (if set to 1) or
Not hidden (if set to 0, which is the default).

Network folders that contain more than 800 GB of data can now be successfully encrypted  

A previous limitation has been eliminated, under which a Network folder that contained more than 800GB of data would fail to be successfully encrypted using SecureDoc File Encryption (SFE).

Note however that during the encryption phase, SFE will create a temporary version of each file that it encrypts, so it is necessary to have adequate free space available to temporarily contain a second copy of the largest file in the network folder.  For example, in a network share of only 1GB overall disk space and (say) it contains only a single file that is larger than 500GB, there would not be enough free space (by definition) to be able to encrypt that file.

Failed login attempts when using PBConnex network-brokered authentication are not being correctly logged on the client as failed login attempts, and such failed login attempts are not being counted against the maximum permitted failed attempts to protect the device against attack.

Issue:
Unlike failed login attempts against a local key file being tracked, logged and counted, requiring a reboot after every third failed attempt and ultimately locking the device once the maximum failed login attempt threshold had been breached, similar failed login attempts against a device on which users authenticate over the network using PBConnex were not being logged and counted.

Solution:
This has been corrected, and all failed login attempts via PBConnex will appear in the log entries for the device, and will be counted toward determining if the maximum failed login attempts has been reached..

SD-11688

Web Browser at Pre-Boot to allows users to perform Password Reset against their company's Identity Management (IDM) web application

This adds one additional means for users to reset their passwords (e.g. when they forget their password) aside from Self-Help questions and Challenge/Response.

A Web browser accessible from the Pre-Boot screen allows user to access their company's IDM (ID Management) for password reset. The web address can be defined inside the Profile, and only that website is allowed.

Note: Only HTTPS protocol allowed. Web Browser configurations and its Ports are only controlled in the profile under Boot Configuration and Advanced Options.
Only a single website can be set at a time.
The Administrator can change website settings by updating the profile and sending remote command to client from SES console.
Website information is protected by being encoded in "SDProfile.ini" file (to prevent tampering). On the deployed client, similarly the website defined in the "SecureDoc.ini" is protected so a user cannot change it to access other websites.

SD-13418

A crash issue in Windows 10 would occur when an encrypted PDF file was opened by a Windows Metro Application

An issue was encountered where, when a SFE-encrypted PDF file was opened using the Windows 10 PDF reader (a Windows Metro/Universal app), it would crash Windows 10. 
This has been resolved in this version.

Resolved an issue with File folder browsing being slow on Internet VPN connection when SFE is enabled on the client

Customers had indicated that on slow network connections, typically where the use of VPN was further slowing the connection, devices running SecureDoc's SFE (SecureDoc File Encryption) would encounter very long waits to display the contents of folders on a remote server. 

SD-15628

SFE now also supports using IP addresses to define Network Shares in SFE Server Policies.

A limitation has been eliminated which had previously required that any Network Server shares that were to be encrypted using SFE were required to use DNS Server names.

With this version, SFE Policies can also be configured to define Servers by IP addresses directly.  The use of Server DNS Names continues to be supported.

Version 7.5 provides an improvement to the time it takes to copy large files (Mail Data) to an encrypted folder – compared to a non-encrypted folder  

A previous version showed substantial degradation in copy speed when copying large files to an encrypted folder. 

In this version, this has been corrected, and copying large files to an encrypted folder is now significantly faster.

SD-16666,
SD-22346

Able to change SES master-admin value in SA field via sub-admin.

It had been possible for subordinate administrators to elevate their own rights through direct manipulation specific columns in the SES database. 
While this involved an unusual method that required substantial understanding of the internals of the SES database, WinMagic still recognized that this security weakness should be blocked.

This issue is fixed.

SD-17012

When a valid AD user is logging into a device, if the user’s current AD password differs from the password stored in SES, the device will be secured and provisioning mode will end, while concurrently the user’s Password stored in SES will be updated to match the user’s current AD password.

The Device Provisioning process, which when completed results in the full securitization of the device, has been improved.

Now, when a valid AD user is logging into the system, if the user’s current AD password is different from their password in SES, SecureDoc moves ahead to successfully complete the device securitization while also updating the SES user information with the user’s current AD password.

Improve "Decrypt All" to work under elevated rights in Control Center, and is now based on the rights in the users Windows Key File.  Users are no longer required to go through Pre-Boot to get key file rights for this functionality.

"Decrypt all" function needs Administrator rights keyfile.  When used, it will decrypt all full-disk-encrypted disks, but will not affect individually-encrypted partitions.

Note: This is NOT SUPPORTED for individually-encrypted partitions that were encrypted using "Encrypt partitions only" function. This means that its use will not result in the decryption of all individually-encrypted partitions, only full disks.

Note: After decrypting all disks, the Boot Logon functionality will still exist in the boot disk, so unless Boot Logon is removed before rebooting the device, the device’s disks will be automatically re-encrypted after restarting the machine.

Corrected performance issues relating to closing encrypted Excel files stored within a folder on a NAS unit (Network Attached Storage)

In a previous version, users had determined that where Excel files were stored in a folder located inside a Network Attached Storage (NAS) device, closing and storing those files would occur very slowly.  This issue did not seem to apply to other file types.

This has been corrected in this version.  

Key File Deployment and completion of Provisioning stage can be blocked by combination of Hardware Encryption and use of WiFi connection.   If device cannot get network address/access within a fixed time period it would not be able to complete the Provisioning stage.

Scenario:

1. A windows device profile was created, having the 'Disable reboot following boot logon installation' option UNCHECKED.   The option 'Use hardware encryption if available' was CHECKED, to ensure that hardware encryption would be used for Self-Encrypting Drives.
2. The Installation package was created with the 'Restart device when encryption is complete...' option was UNCHECKED.
   The installation package also had Device Provisioning enabled (in this case with Temporary Auto-boot, though it’s not material).
3. On the device (which contained a Self-Encrypting Drive (SED) and only a WiFi connection (in this case the Operating System was Windows 10, though the issue might not have been limited to Windows 10.  The Administrator created an ad-hoc (non-AD-imported) user with a name which does not exist within the SES Database
4. Login to the device as the created user account, and then deploy the created SecureDoc Client software installation package to the device

As a result of the above, the package was installed, SecureDoc’s Boot Logon/Pre-Boot was installed and encryption was completed.
At this time both the new device and the relationship to this new user were added, appearing in the SES Console.  The device showed a status of:  'Encrypted reboot required' and 'Temp Autoboot' user is created password not synchronized.

5. The user shut down the device and started it again (Note: Under Windows 10 the device’s WiFi is not automatically initiated on login screen)
6. Expected result: Login Windows with the same deploying user and see the device status changes in SES console (indicating that the user’s Key File had been sent to the device, the Auto-Boot account would then be removed since the device would have completed the Provisioning state, and the device would show in the SES console as ‘Deployed’.

Actual result: The device communicated the device’s IP address to the server, and the device status changed to 'Encrypted', however the device could not complete the provisioning stage, and remained in the 'Temp Autoboot' state, permitting the device to continue to bypass Pre-Boot Logon.  As a result Preboot is not displayed on the device
Note:  The same package installed on the device with Software encryption does not experience the same issue (device is successfully completed Provisioning stage, the user’s Key File was the only means of authenticating to the device, and Temporary Auto-boot was removed).
After some investigation it was found that it is related to the WiFi (on the device in question) being very slow at forming a network connection during Windows Login (a point in time during which SecureDoc attempts to complete the Provisioning stage); this network adapter in fact did not complete its connection to the network until after the Windows desktop had been displayed.

An issue - where SecureDoc File Encryption would not encrypt the user's temporary folder when an SFE policy was configured using the environment variable for <User Temporary Folder> - has been corrected.

SecureDoc's SFE policies can now correctly encrypt the user's temporary folder when this environment variable is used within the SFE policy definition.

SD-18398,

Improve FileVault2 Support where implementing the SecureDoc Pre-Boot Authentication (aka SecureDoc “on top” of FileVault or SDOT FV2) to include Profile configurations to support PBA Customization

Improvement:
SES’ FileVault 2 Profile settings will implement new controls to add background Image, and ability to change Header prompt, add a new SubHeader prompt, Key File, and Password prompts, as well as Font Color and ability to import a customized Background. 

This will make the Apple Mac user’s Pre-Boot experience on SecureDoc-managed FileVault2-encrypted devices to be very similar to what SecureDoc has supported for Windows users for many years.

This does not support the new Modern Pre-Boot environment that Windows supports.

Mac client change under SDFV2/SDOTFV2: Support and change WinMagicRecoveryAccount password length based on SES Profile configuration  

 SES V7.5 now makes it possible to edit the FileVault 2 Recovery Account password length from 24 characters up to 44 characters for SDFV2.  It remains non-configurable for SDOTFV2, which uses 44 characters by default.
Users can change WinMagic Recovery Account length in the profile setting and execute the Remote command entitled: "Assign device profile to devices" to clients to effect this change.
To use configured recovery password to login at FV2 pre-boot, if upgrading from SDFV2 to SDotFV2 and where the WM Recovery Account password length had been configured as anything less than 44 characters, it will be automatically set to 44 characters.

SecureDoc has switched to use the GUID Partition table (GPT) + EFI System Partition (ESP) on Shadow Master Boot Record (SMBR) of OPAL Self-Encrypting Drives for UEFI environments.

Using GPT + ESP on SMBR helps BIOS to boot correctly into the SecureDoc Pre-Boot path under UEFI with Hardware encryption.

This change also removes registering an absolute boot path on detection of “DELL” systems.

Internally, SecureDoc will switch to GPT partitioning automatically for UEFI devices.

SD-19451 and

Device Provisioning was unable to complete successfully when SDConnex is joined to a child domain (within a multi-domain environment) where that child domain has a bidirectional trust relationship with other child domains, from which users are synced through ADSync.
Issue Scenario:
1. A customer has a single forest and multi domain environment, with bidirectional trust in their existing setup.
2. An SES environment was installed, in which an SDConnex server was joined to one of the child domain, named e.g. service.abc.com, and ADSync was synchronizing users from another associated child domain named e.g. mind.abc.com
3. These domains have a bi-directional trust established between these (and other) child domains.
4. An SES client installation package setup with manual user identification, and the package was installed for one of the synced users from mind.abc.com domain, user named e.g. “johndoe”
5. SecureDoc attempts to define this user as the primary user of the device (in order to complete provisioning, making that user the “owner” of the device. In this case, the “johndoe” user exists in the child domain mind.abc.com.
6. As soon user “johndoe” enters his Windows credentials, the client device would throw an error message “Please contact technical support”.
7. DEBUG logs were collected from both SES and the Client for investigation and possible fix as a next step to move forward as per customer technical requirement.
The Primary issue was that: Provisioning would successfully complete for user “johndoe” on this device only when SDConnex communicated to the same domain mind.abc.com (the domain where the user exists). 

However, because of the bidirectional trust between domains, it should have worked regardless which of the child domains was directly communicated with by SDConnex.  This turned out to not be the case in this scenario, due to the existence of the issue above.

This issue has been resolved, and provisioning will complete successfully when SDConnex communicates with any of the Domain Servers within a single Forest, bidirectional

Resolved an issue relating to SFE on non-English operating systems renaming local-language folders to US English standard names

SecureDoc File Encryption under the new DMK library does not show this behavior, so this issue is considered closed and corrected.

Ability to add (AD) Groups to the Excluded Users List

The SES administrators can select automatic provisioning in the Provisioning Rules in the installation package settings, the first user account to login to the computer after the initial registration with SES will become the device primary owner.
This poses' problems when administrators need to log into the computer to perform other installations or checks - during the SecureDoc installation and encryption - and before the device can be given to the computer’s rightful owner.

Unlike the list of excluded users, the ability to add groups of Users to the excluded list is actually a new feature (or attribute) of the Group itself

This new option allows identifying groups of users created within SES or imported from Active Directory as not being considered for device ownership, effectively summing together the user-by-user list of excluded users and the user members of all groups for which this option has been set.

This ensures that none of these specifically-defined users nor those users who are members of the defined groups can get a Key File on the device if they happen to be logging in to the device to perform any further work prior to it being given to its ultimate owning user. In effect, they absolutely CANNOT be the users that effect final securitization of the device.  

Note: Located in the "General" tab of Group Properties, the extended option is entitled "Users from this group (and sub-groups) will not perform secure moment during provisioning".  If the group has a parent group with this setting already enabled, this check box will be disabled (grayed out).  

This option will be renamed to be more function-focused in a future version of SES.

Improve device Securitization.  "Device ID" (instead of a specific User ID) may be used to complete securitization and end Provisioning Mode.  This also fixes missing rules re: synchronization of passwords.
When a computer (e.g. with name "dev1") is registered, the deploying user will be created in SES as "dev1" with an empty password. A KeyFile will be generated for use by user "dev1", protected with a random password, and deployment will continue as before.
At the first Windows user login, at that moment the example device is still in Provisioning state and the SecureDoc Primary Account Setup form is displayed to prompt the user to enter a password.  In this case, the SecureDoc client software will send a request to SES to create an owning-user KeyFile for the user name "dev1", protected by the password the user has just entered <CustomPassword>. 
SES checks the password of user "dev1" in the SES database.

• If user "dev1" has never existed, or existed in SES but without a final password (so there will be no password for that user), SES will accept the entered password, update the user "dev1" in SES with the password the user just entered, and then generate and send down a new Key File to the client device.
• If user "dev1" has existed in SES and had a final password, in this case, SES will compare the client's entered password and the current one stored in SES. If there is a mismatch, the client must enter another password until SES determines it is the user’s correct with final password, per the SES database. After that SES generates and sends down a Key File to the client device, protected by the user’s final password.

Boot on Samsung 900X3G Boot takes an unacceptably long time where device has a Self-Encrypting Drive (SED) Solid State Drive (SSD) that has been encrypted using Software Encryption

In this (rather unusual) scenario, the device has an SED SSD drive installed, but which has been software-encrypted (rather than utilizing its built-in hardware encryption).  Once the SecureDoc Pre-Boot for Native UEFI (PBU) detects the drive is an SED it tries to determine its status, but due to broken read/write disk functionality in the BIOS of these computers, PBU is prevented from using the AHCI low-level interface when trying to access the drive as a Self-Encrypting Drive (SED).

Limitation:
Samsung BIOS firmware doesn't support the required protocols for SED (hardware encryption) support. Therefore SecureDoc pre-boot fails to unlock SED at pre-boot. The workaround is to force software encryption on SED.  

SFE now supports encrypting folders on servers whose server names start with a numeral (e.g. "1Server" )

Due to a previous limitation, SecureDoc File Encryption could not handle policies that applied to Server names that started with a numeral (0, 1, 2, ... 9). 

In this version, this issue has been resolved and SFE can encrypt folders stored on servers whose names start with numerals.

SES profile setting to enable client devices to cache PBConnex Auto-Boot Key Files for X days was not saving those changes to devices. 

Impact: Instead of having a cached Auto-Boot Key File resident on the endpoint device for the specified number of days specified in the SecureDoc Profile (reducing key-generation load on the SES server), the SES server was required to generate an Auto-Boot Key file on-demand ever time a device was supposed to auto-boot. 

Reason: This was caused by the Device Profile not instructing the client correctly to cache the key file for the required number of days.

This has been resolved in this version, and devices will now cached an auto-boot key file for the specified number of days before it is expired and a new key file must be generated by the server.

Corrected issue related to SdWpdFltr.sys (which is a filter driver), and support for user-mode feature Disk Access Control (DAC); These had prevented data access on WPD (Windows Portable Device) device types.

When Disk Access Control (DAC) is enabled, it filters interception of devices from USB class and WPD class. By its nature, it needs to filter all devices from WPD class, which had resulted in lost functionality of certain USB devices.

This issue is now resolved and these no longer not block access to USB devices.

Issue affecting SecureDoc Pre-Boot (PBL/PBU/PBLU environments): Activating Auto-boot through Remote Command would automatically log user into the Windows desktop.

After successfully sending the remote command "Activate Autoboot" to client successfully and restarting those devices, those devices would bypass Boot Logon and the SecureDoc Credential Provider (SDCP) screen, loading the Windows Desktop without prompting the user to enter his/her password.

This issue is now resolved. After bypassing Boot Logon the machine will boot to Window’s login, SDCP will load and stop, waiting for the user to enter his/her password.

Following deletion of a folder in the SES folder structure, main SES Admin user account encountered error message “Attempt to scroll past end or before beginning of data”.

Other Admin accounts would not encounter this error message.

This was determined to have been caused by an error in the Folder Rights calculation logic.

Implement the new remote commands on the SES side for Mac devices to "Uninstall SecureDoc". Mac device will be moved to Recycle bin once the remote command is sent to the device.

This new feature works both on SecureDoc for FileVault 2 (SDFV2) and SecureDoc with Pre-Boot For FileVault 2 (aka SecureDoc "On Top" of FileVault 2 or SDOTFV2).

When sending the remote command "Uninstall SecureDoc" SES console or SES web, regardless whether the user currently logged in to the device has Admin rights - or not - the command would be executed right away and SecureDoc will  be removed successfully and FileVault 2 will be disabled together.  Lastly, the device will be removed to the Recycle Bin in the SES Server Console.

Note: ONLY the SecureDoc ADMIN is allowed to perform this uninstall process.
Note also: the option "Allow SecureDoc uninstall by SecureDoc user with admin rights or local administrator" is DISABLED in profile of client.  

SDFV2/SDOTFV2: A new configuration element in the SES Console permits Administrators to define whether Local Administrators or SecureDoc Users with Admin rights are allowed to uninstall FileVault.

This new option is entitled:  "Allow Uninstall by local administrator or by SecureDoc user with admin rights".
Its use within the Device Profile determines whether (or not) the Uninstall application will exist on the Mac client device.

By default, this option is UNCHECKED:

1. If UNCHECKED, in the deployed default package for SDFV2/SDOTFV2, the SecDocFvUninstall application does not exists on the client.  In this scenario, it would only be possible to remove the SecureDoc application through the use of the new Uninstall SecureDoc remote command.

2. If CHECKED, the deployed package for SDFV2/SDOTFV2 will contain (and will install) the SecDocFvUninstall application (as was the default in previous versions).  With this application in place on the Mac endpoint device, Customers can use normal way to remove SecureDoc.  As well, the remote command "Uninstall SecureDoc" in SES is still available to the SES Administrator and works correctly to remove SecureDoc from the endpoint device.

A fix has been applied so that PBU German Keyboard with Caps Lock ON and pressing Alt Gr + q/e/m characters no longer displays incorrect characters

With German physical keyboards, some characters showed incorrectly in the Pre-Boot Environment for the Pre-Boot for Native UEFI (PBU) login screen when the Caps Lock was engaged/on and when users pressed the combination of the AltGr + q or e or m keys.

This issue is now resolved.  

Corrected issue in which excluded Windows Account users would still have Key Files created for them when logging into Windows

Issue: If Password Sync has been set, it will perform password synchronization.
When an excluded user would login to Windows, SES would still mistakenly create a user account key file and add it to the device's SDSpace as a boot key file.

It was mistakenly doing this without first checking whether the user in question was in the excluded accounts list.

An issue, wherein the USB port is disabled after deploying SecureDoc package to client device, has been corrected.

The issue was related to mistakenly registering a service key which in turn prevented windows from locating a required driver and loading it, causing a USB class malfunction.  

This issue is now resolved.

SES supports changing the Recovery account password for SD FV2 and SDOT FV2 users through a remote command.

Using SES console or SES Web, the Administrator can send a "Change recovery account password" remote command to a device running SecureDoc's client agent for FileVault 2 (both SDFV2 and SDOTFV2).

It will ensure that SES is updated with the newly generated password and that the client is using an updated password.  

Note: This feature now supports both SDFV2 and SDOTFV2.

Reduce number of steps required of SES Administrator when performing Bitlocker Recovery from the SESWeb browser-based console.

In previous versions, when a user needs to perform BitLocker Recovery, it required the Web Console administrator to click 7 times through 3 separate screens and then to confirm a warning message before getting the recovery key.

With this improvement, the steps required have been reduced by 50-60% to complete BitLocker Recovery. 

SDOT FV2 - SecureDoc now enforces and re-enables FV2 on the client if disabled by an end-user

When SDOTFV2 is installed successfully in client but FileVault 2 is disabled by an end-user, a message will appear to notify the user,  and it restarts the application after decryption. Then client is re-registered with SES, it re-generates the SD Account Password, upgrades SDSpace to contain the new Key File and enables FileVault 2 (FV2) again.  

SD-21171,

Black screen displayed after resuming certain SED-equipped devices from Hybrid Sleep mode.

This issue caused devices to fail to transition into loading Windows upon resumption from Hybrid Sleep, under the following circumstances:

SecureDoc client devices that

• had Self-Encrypting drives installed, and
• were running 7.1 sr5 build 62 or SES 7.1SR5 HF1
• were put into Hybrid Sleep
• Such devices would successfully pass through Pre-Boot Authentication but then fail to load Windows, and would remain at a black screen with a blinking cursor.

Note: Not all device types were affected, but WinMagic recognized that Lenovo device showed this issue.  Devices that were placed in Sleep mode or in Hibernate mode were unaffected.  This issue did not affect devices that were software-encrypted.

[SDFV2/SDOTFV2] - handle changing password length during SDFV2 ==> SDOTFV2 transition from 24 to 44 characters

SecureDoc for Mac FileVault2 has been improved to permit the transition from a 24-character password to up to a 44 character password if the device is transitioned from using SecureDoc for FileVault (SDFV2) to using the SecureDoc Pre-Boot Authentication for FileVault 2 (SDOTFV2).

SD-21276,

Issue corrected where Pre-Boot Logon could become "stuck" if user entered wrong UserID/Password and pressed <enter> twice before the network icon turned to green  

This issue could occur under the following specific circumstances:

Configuration:

• Device is encrypted using ‘Data Only’ and ‘Use hardware encryption if available’, under the PBLU (Linux-based Pre-Boot for UEFI devices)

Status:

• SecureDoc is installed on the device successfully, deploy state is deployed, encryption finished.
• The client is restarted and the pre-boot authentication screen appears.

Symptoms:

• If the user enters a wrong UserID/Password combination three times before the network icon turned to green, and
• Device is rebooted
• Device now shows Native Pre-Boot for UEFI Devices (PBU) instead of PBLU.
• Then if the user were to input a wrong UserID/Password two more times before the network icon turned to green…
• Pre-boot screen would be unresponsive, and the user cannot input anything.  The device would need to be rebooted before the user could access the Pre-Boot screen again.

SecureDoc’s pre-boot SDOT & Management of Multiple data volumes

In previous versions, where there were multiple partitions on a system that had already encrypted with BitLocker, i.e. C and D, when SecureDoc’s BitLocker Management (SecureDoc’s Pre-Boot for BitLocker were installed to "manage" the already encrypted BitLocker system, only the first drive partition C would be managed - and not any others.

In this version, SecureDoc now properly takes over management of all previously BitLocker-encrypted partitions.

SecureDoc blocks specific media despite DAC, and Port Control being disabled

Customer reports that when they attach a FlukeNet LinkRunner AT USB Device, the system reports "The SecureDoc policy on this computer does not allow access to the removable drive e:"

In this customer’s scenario, the profile of the device does not have Port Control or Disk Access Control configured.

Even after adding the device to the Trusted Device List, the issue continued.

The customer that originally experienced this issue had tried this after upgrading the Device from 6.4 SR1, to 6.5 SR3, to 7.1 SR4. They have also tried this with a fresh install of 7.1 SR4.

This issue has been resolved, and FlukeNet LinkRunner AT USB Devices can now be connected to SecureDoc V7.5-protected devices without triggering this problem.

Customers that had been experiencing this problem on earlier versions are requested to upgrade their Client devices’ SecureDoc version to V7.5

Improve SecureDoc messaging to guide user action re: BlockSID blocking successful SecureDoc Installation

Issue:
Previous versions of SecureDoc did not clearly indicate to a Windows User that the BlockSID feature of a Self Encrypting Drive (SED) has been enabled. As a result, customers were not provided adequate guidance regarding why SecureDoc was failing to install on their platform, even though the drive was not managed.
The message in place in previous versions was: "Failed to enable pre-boot authentication on specified self-encrypting drive. Error number 9a0001. Please contact Technical Support."
Solution: This version improves on this by providing a more reason-focused and articulate message, indicating that the BlockSID feature of the drive had been enabled by the BIOS and that the Windows User needs to disable this BIOS feature to solve the problem.
The new message will read:
"Failed to enable pre-boot authentication. Please ensure BlockSID is disabled in the BIOS and restart your system.

Periodically change the password of the FileVault Recovery Account

Through this improvement, SecureDoc Enterprise Server can now trigger the automatic update/setting of the FileVault Recovery Account password to a new random value every 30 days

SD-21642

Improve security – New feature can prevent Administrators from being able to view Self-Help Recovery answers of other Administrators

The first or primary administrator cannot lock him/herself out of being able to see the his own Self-Help Recovery answers , but has full rights of access to those of other Administrators.
The primary administrator can set what other administrators can see, and subordinate administrators cannot change this setting relating to themselves or other Administrators, only the primary administrator can do that.

Allow SES to generate replacement Token-protected Key Files even if the user’s imported Certificate has expired.

Normally, when a user certificate (that was imported by ADSync with the user record) expires, ADSync automatically removes the certificate from SES, detaching it from the user’s properties. 

However, this is considered to be a fundamental change to the user’s ability to authenticate, so it drives SES to generate a new Password-protected Key File to replace the original Token-protected Key File. 

Unfortunately, this runs counter to the database settings for the user on that/those device(s), which may be set to require the user to always have a Token-protected Key File.

Solution:
Rather than having SES create a Password-Protected Key file, SES will now continue to allow the Token-protected Key File to exist, even though the Certificate has expired.  Subsequent import of a new unexpired Certificate will auto-generate a new Key File based on that new certificate.

Where users are imported for the first time from AD but their Certificates had expired prior to initial import, those users can only have password-protected key files since their certificates were already invalid at the point the user was first imported from AD.

SecureDoc Self-Extractor command line now permits both Encryption and Decryption of encrypted archives

Solution:
The Self-Extractor executable SecureDocSFX.exe now has additional options that permit creation of new encrypted archives.
List of the command line parameters:
-e Extraction mode
-s Path of source file/folder (required)
-p Password (required)
-t Name of target (destination) file (.CAB or .EXE extension)
-o Folder for results output
-ng Silent mode (no UI)
Any other parameter will trigger help prompt display.
Usage examples:
Encrypt/Compress:
SecureDocSFX.exe -s C:\Folder\File.txt -t File.exe -p 12345
Extract:
SecureDocSFX.exe -e -s C:\Folder\File.txt -p 12345
Help prompt:
SecureDocSFX.exe –h

SD-21723

During password propagation - SecureDoc Enterprise Server will no longer update and send key files for individual users that exist on 100 or more computers  

Problem:
Where customers have the same user account (typically an IT desktop support pseudo-user account like “ITDeskSupport”) on many hundreds of machines, if that account’s password is changed, the SecureDoc Password Propagation option (if enabled) will automatically queue up one new Key File for that user account to be sent to every affected device.  For large customers, this can lead to a substantial loss of SES responsiveness while all these commands are queued up, and then a secondary impact as they are sent to affected devices.

Solution:
With this solution, SES will limit the password propagation feature so that it “maxes out” at 100 devices.  
This should have no impact on regular implementations (an ordinary computer user would be unlikely to have a key file on as many as 100 devices), but it will limit these mass common user id Key File updates to stop at 100 devices to limit SES processing time and network utilization.

Implement KF deployment into SecureDoc Pre-Boot for Mac FileVault 2 (SDOTFV2) that provides Provisioning stage (Temporary Auto-Boot mode only) with Prompted definition of device ownership.

When Provisioning Mode is ENABLED:
1. SDOT FV2 installs and registers as usual with SES - no user activity is required here. SecureDoc uses the current logged on Mac user (and device information) for the registration - as usual.
2. The system is automatically placed in Temp Auto Boot mode - which means provisioning functionality is available for the Apple Mac platform.
3. Similar to Windows - upon the next user logging into the system, i.e. restart, log off - the prompt will appear requesting the user to confirm whether he/she is the device owner. The user can:

• Log into the prompt - and confirm device ownership, completing the securitization of the device (i.e. that user’s key file with user's credentials are now set at Boot Logon as the “owner” and default user)
• Choose not to confirm device ownership at this point. The system remains in Provisioning Mode with continuation of Temporary Auto-Boot, and following subsequent reboots the user will be re-prompted to confirm ownership.

 
When Provisioning Mode is DISABLED:

• The user is required to complete the logon prompt to continue.

Improve capability to adapt to device hardware and technology.

SecureDoc’s “Installer will auto-adapt to device specifics/technology” option, if enabled, detects when a device did not smoothly transition from the Pre-Boot environment to the Windows loader, and will choose the next in a series of switch settings in anticipation that during a subsequent reboot those settings will be what are required for smooth transition.

This fix includes generalized improvements in this process, ensuring that the device will continue to try new switch setting, and it provides a visual notification to the user of its progress along this path.

[Hosting Solution issue: Folders displayed when Admin is selecting key or user do not display consistently – may include contents from folders that are not part of the current folder

When defining a hosted solution (where devices, users, keys are stored in a specific folder for hosted company or other structure), then when adding Users or Devices to a defined group, SES permits user and device selection from within Folders that are not part of the current folder. 

Issue had been that ability to select Users or Devices to add to a group should remain limited to the current folder but is currently not limited in this way.

Issues with 802.1x and when there are 2 certificates in CS (SHA-1 and SHA-2)

There was an issue with processing multiple device certificates in Windows store.

This has been corrected and SecureDoc will utilize the correct certificate where there is a choice to be made between multiple certificates.

Provide support for UEFI-level Device Guard  via dual-signing

With this version, SecureDoc provides support for UEFI-level Device Guard through a process of dual-signing the SecureDoc executables.

WinMagic has chosen to use WinMagic’s own SHA 256 certificate and another signing certificate from Microsoft.

The reason for this approach is because BIOS-level implementation of Device Guard no longer considers the Microsoft 3rd party EFI certificate to be proof enough, though it was previously considered good enough to have Secure Boot Enabled.

Using the WinMagic public certificate allows our certificate to be included by OEMs into the BIOS' list of valid signatures.

lsass.exe error causes devices to reboot after windows authentication

When an end user signs in and desktop is loaded, after 5 minutes the system would crash:

1. A Window file, lsass.exe. causes system to reboot.  Every time the end user logs back into the OS he/she will see an error message
2. If user right clicks on the SD icon and requests the device to communicate with the server, the system will crash.
3. If user ends the lsass.exe task in task manager, the system will also crash or reboot.

Based on Microsoft’s recommendation the customer experiencing this issue shut down the SecureDoc Server and SDConnex. After shutting down the server, the client devices would no longer crash or reboot. 

From further troubleshooting WinMagic have found that when Password Synchronization is enabled, and the client is allowed to communicate with the SDConnex server, the client will crash shortly after logging into windows.

Further testing showed that disabling password synchronization and then allowing the device to communicate, the system dud not crash.

Also, stopping SDConnex but keeping Password sync enabled, the system does not crash.

Lastly, if a refreshed/updated device profile is sent to the device, the device stops crashing.  

Correctly limit number of Self-Help Recovery questions in SecureDoc Key File, avoiding possibility of error:  PBA return 139, followed by a device crash.

In earlier versions of SecureDoc, while there was a limit of 7 questions that could be posed to any user, SecureDoc did not have a limiter defined for the number of questions that could be added to a Key File, with the result that adding an excessive number of questions could cause the device to error out with error message:  PBA return 139.

This improvement sets 7 as the maximum of questions that can be added to a Key File, which conforms to the maximum number of questions that can be displayed on the Self-Help Recovery screen at Pre-Boot.

NOTE: Existing customers that have more than 7 questions in any existing Installation Packages will need to reduce the number of questions in those packages to 7 or fewer.

Improvement:  Ensure that SecureDoc works with Microsoft Device Guard (OS-level)

SecureDoc supports MS Device Guard (OS), but with the following limitation:

• Windows crash dump will not function.  The Windows System Event Log will show the following error:   Error (161) volmgr: "Dump file creation failed due to error during dump creation". 

Add configuration that can hide the "Forgot Password" link in the SecureDoc Pre-Boot screen

This new feature permits manually adding a new setting in the Device Profile to suppress the display of the “Forgot Password” prompt in the SES Client Pre-Boot logon screen:  To implement this:

In the section headed: "SDSpace", insert BootHideForgotPasswordLink=1

When used, this option will suppress the display of the “Forgot Password?”  prompt at SecureDoc’s Pre-Boot Logon.

Note: There is no user interface in the SES console through which this can be added, it must be done manually at present.

Add configuration that disables (hides) the user name field in the SecureDoc Pre-Boot screen

This new feature permits manually adding a new setting in the Device Profile to suppress the display of the User ID/KeyFile prompt in  the SES Client Pre-Boot logon screen:   To implement this:

In the section headed: "SDSpace", insert BootHideUserIdPrompt=1

When used, this option will suppress the display of the User ID (key file) prompt at SecureDoc’s Pre-Boot Logon.  If the user wishes to display the User ID prompt, pressing F10 will cause it to be displayed again.

Note: There is no user interface in the SES console through which this can be added, it must be done manually at present.

Increase the text area in PBU to properly show all information (and not require scroll bars).

The SecureDoc Linux-based (V5) Pre-boot has been improved to permit the use of a notification text string of a more substantial length, without the need to resort to the use of a scrollable area.

Improvements were made to the Header area to auto-scale the font size, so that long strings can still be used; Long strings will drive use of small font sizes.
Such text strings are commonly used for corporate device “terms of use” advisories.

SES - Implementing the Emergency Disk information to support SDOT for BitLocker clients

SecureDoc now has support for creating Emergency Disks/Recovery Media for Bitlocker-protected devices which run under the SecureDoc Boot Logon for Bitlocker devices.

Improve the “Wait for File Distribution Software to Reboot the System” functionality to include additional boot scenarios.

The installation package setting has been improved to include additional reboot settings to accommodate additional use case scenarios.  Previously this setting only allowed for pausing the reboot after installation of the Pre-Boot environment.  This improvement has added the capability to pause the installation at 3 different points, as well as the ability to have a combination of any or all points.  The new behavior is governed by manually adjusting the “WaitReboot” parameter in the Installation Package Settings.  The new options are as follows:

• WaitReboot = 1 – Pause the installation and wait for a reboot after the Windows Client is installed but before device registration – SDWaitRebootI.txt is created
• WaitReboot = 2 – Pause the installation and wait for a reboot after the Pre Boot Environment has been installed but before encryption starts – SDWaitRebootB.txt is created
• WaitReboot = 4 – Pause the installation and wait for a reboot after encryption has completed and the system is fully protected – SDWaitRebootE.txt is created

These values can be combined for multiple reboot pauses.  For example, WaitReboot = 3 is the equivalent of (1 + 2). 

Role-Based Access Control for Groups under SES Web authorization was yielding more rights than group member should have had

In earlier versions, group members could have rights of access within SESWeb that exceeded those defined for the users.

This has been corrected.  Users who are group members will only have the rights specified for their group.

PBU and Token Authentication - Delay in successful authentication / PBA Notification during first use of new Smart Card

If a customer has a smart card that has numerous certificates on it, one of which is the one required for authentication,   SecureDoc must probe each of the certificate slots until it finds the correct certificate.
Thereafter it indexes that certificate slot so that it will more rapidly access that certificate (without having to search all over again).

 In this way, customers should experience the slow initial search only once, on first use of that card.

SD-22099, and

PBU - Have an alert/message at Boot Logon prompt when the CAPS LOCK button is engaged.

SecureDoc Pre-Boot environments (Windows, Mac, Linux) now provide an indication if the Caps Lock key is in effect.

This is intended to overcome a lack of clarity that could affect users in the past, particularly where using on-screen keyboards or physical keyboards that lack a prominent indicator of the Caps Lock key status.

In this version, the words “Caps Lock” will appear in a separate area at the bottom of the Boot Logon screen, near the right.

Creating key Files in the SES Console using V7.x takes significantly longer than creating a key file using v6.5 and earlier versions

This issue has been corrected in V7.5, and key files are being created in an acceptably rapid fashion.

In previous version(s) it was possible for an Administrator with no “Manage Administrators” role rights to be able to add a new Administrators group.

This issue has been corrected.

Improvement: Hide the  “<F10> abort auto-boot message” so that it only appears during the last 10 seconds of the countdown

SD-22969, and

Improvement: Add capability to define AD Groups in the Excluded Users list so those group members cannot become device owners

With this improvement, not only can the SES administrator define individual users who should not become device “owners” when Provisioning stage completes, but now can define Groups of users who cannot become device owners.  Any user who is a member of the group cannot become a device owner (in the same way as if that individual owner had been added to the Excluded Users list directly).

SD-22100, and

User key files were still being created when users logged in at Windows, despite the users being in the SecureDoc Excluded Users list

Issue:
Where Password sync has been set, it would perform password sync when the excluded domain user would logon to Windows, creating a domain user account key file and adding it to the device’s Key File space (SDSpace) as a boot key file without first checking whether the user’s account was in the excluded account list.

This has been fixed. SecureDoc will now first check if the user is in the Excluded Account list, and if it is, will not perform Password Sync and will not create any kind of key file for the excluded user(s).

SecureDoc’s Pre-Boot “On top” of FileVault 2 (SDOTFV2) permits creation of users on the local device, and then automatically associates the user to the device in SES, which sends a Key File for that user to the Device in question.

Now Under SDOTFV2, we support creating users on the local device and automatically provisioning a key file for that user to the device. 

This can be done by logging out of the current user account, then logging in with the new account.  SES / SDConnex will queue up and send a key file successfully.

Allow devices to  dynamically switch from SecureDoc Credential Provider to Windows Credential Provider when devices are able to connect to SES (indicating they are in their corporate LAN/secure network)

A new option entitled: "Switch to native Windows logon in home network (SES server is reachable)" has been added to the Device Profile.

This option is a dependent sub-option of the option entitled: "Only users having SD Credentials may login at Windows logon".

If enabled, this option will condition the automatic switch at the device level between the SecureDoc Credential Provider to the Windows Credential Provider (CP) when the device is in the corporate LAN (provable because the SecureDoc device has been able to successfully reach the SDConnex server)

Incorrect message is displayed when deploying installation package with 2 options "Wait for the file distribution software..." and "Restart device when encryption is completed" enabled

Issue:
Device should show a message:

• "Computer MUST be shut down to complete the process" is displayed following the V7.1 design.
  or
• Message "SecureDoc Remote Installation has completed" should be displayed, the same as when deploy package with option "Wait for the file distribution software..." enabled and "Restart device when encryption is completed" disabled.

Actual (incorrect) result:

• Dialog "Computer will shut down in ... seconds ..." is displayed with "Shut Down" and "Cancel" button.

The "Wait for software distribution software to restart" feature should behave as follows, based on the following Profile and Package configurations:
Profile:

• Disable reboot following Boot Logon installation

Package Settings:

• Enable option: Wait for file distribution software to reboot the system
• Enable option: Restart device when encryption is completed (for hardware encryption will power off)

Solution:
The option "Wait for file distribution software to reboot the system" should have HIGHEST priority.  This means that even if the options "Disable reboot following Boot Logon installation" and "Restart device when encryption is completed (for hardware encryption will power off)" are enabled, these options don't take affect and the system does NOT reboot. It also means SecureDoc should not display a message indicating the system will restart after X seconds, nor that a user is required to restart...
This has been corrected, in accordance with the logic above

SecureDoc V7.5 Windows clients now support a newer modern pre-boot background image for Boot Logon

A new option (dropdown list) has been added to the Boot Text and Color section of the Windows Profile.
The dropdown list provides the following options:
Modern - Windows background image
Classic - Original SecureDoc background image

NOTE: (Modern will be the default setting for the background image for new Profiles, but Classic will be the default for any pre-V7.5 profiles that are being upgraded, since their backgrounds would have been designed to work with what has now become the Classic pre-boot formatting).

• If Modern is selected, SecureDoc’s Pre-Boot Authentication (PBA) will use a new higher resolution image, with larger type-face. 
• Also, where customers enter a lot of text (e.g. at Terms of User advisory) into the Heading field, SecureDoc will auto-scale the typeface used so that this verbiage will look good on the screen and not overwrite anything else.

SecureDoc now supports v5 and v7 Cosmo smart cards for use in multi-factor Pre-Boot Authentication

Re-branding: Update various WinMagic and SecureDoc logos throughout the consoles

WinMagic has introduced modern graphics into the user interface within: console screens in Installation, splash screens, SES Console, SESWeb, SecureDoc (client) Control Center, and Boot Logon.

Introduce well-known device configurations for smoother installation of SecureDoc boot logon

In order to simplify the installation process which may be complicated by variability in device makes and models, WinMagic will collect and update a list of well-known configurations in a form of XML file

A set of criteria will be used to detect the current device model during installation and check it against certain the file, which will yield “override” configuration settings (changes to profile or installation package)
OR
A STOP flag if it is known that this model is not supported.

Using this, Customers should experience:
a) dramatic improvement in the success of SecureDoc installations across a broad range of equipment makes and models, since the overrides will have been created based on WinMagic testing of the same or like models, or
b) an early and smooth exit from the installation process for device makes/models that are known to be incompatible with SecureDoc.

NOTE: For a complete device compatibility/support list, please refer to this WinMagic SecureDoc Website link:  https://www.winmagic.com/device-compatibility

There may be details, tips and work-around recommendations relating to your specific hardware that list that refer to this version.

SecureDoc CloudSync for Apple macOS only works on macOS devices running macOS Yosemite version.

NOTE: Customers that require SecureDoc CloudSync should not upgrade their device operating system beyond macOS Yosemite until WinMagic has determined how to support CloudSync for later macOS versions.

Version V7.3 contained a number of improvements and new features, as well as limitations that carry into V7.5.  V7.3 was released for a very limited customer audience while V7.5 continued to be developed. 

Rather than asking customers to review the list of V7.3 limitations by turning  to a different source document, since these limitations are also included in V7.5 they are repeated here:

LIMITATIONS FOR SFE from V7.3 still present V7.5:

IMPORTANT: There is no backwards compatible support with earlier SFE versions. All existing folders that have been encrypted with SFE using earlier versions MUST be decrypted – folders removed from policy.

IMPORTANT: There is no upgrade support for existing SFE clients. SFE on existing devices MUST be fully removed before upgrading the clients to 7.3 – that contains the new SFE agent.

• SFE in 7.3 only supports key-based policies – password support is not available

• No persistent encryption support in SFE v7.3. All existing persistent encryption GUI elements will be disabled in 7.3 and 7.5

• No control for double-encryption of files – Meaning, if an encrypted file is copied into a different SFE folder (that has a different key) – it will be re-encrypted with the new key

• Encrypted SFE files are not compatible with SD CloudSync or the File Viewers

• SFE cannot encrypt files in folders that are read-only. The user must have proper access, i.e. read/write to the file in order for the SFE agent to be able to encrypt the contents

• SFE - Files do not decrypt after the process of “drag/drop” and/or “cut/paste” from SecureDoc File Encryption (SFE) folder Limitation: The files are still encrypted.

• Microsoft Office (MS) installation fails when SecureDoc File Encryption is enabled

NOTE:  At the time that the initially-shipped SES User Guide was completed, a New Feature (See SD-22330 earlier) referenced in the New Features section was not included in the SES User’s Guide (which is the SES Administrator’s primary reference document).

Early adopters of V7.5 will not have this feature covered in the documentation, but it will be added as soon as possible and the download link will provide the customer with the most-current version.

WinMagic recommends that V7.5 early-adopter customers should re-download the SES User Guide (from the same link as was originally used) within a few weeks of initially downloading it, in order to ensure they have the most up-to-date version of the SES User Guide.

[OSA Windows installer + OSA USB] Does not boot when SecureBoot is enabled

Issue: After installing SecureDoc’s OS-Agnostic version (OSA) from either the Windows Installer, or from a bootable USB Device on a UEFI System, after installation completes the system cannot load Boot Logon

Work-around:  Disable SecureBoot, install OSA, and re-configure SecureBoot.

WinMagic will address the Linux installer signing issues after 7.5 has been released - in a HotFix or Service Release.

SecureDoc’s Pre-Boot Networking support (PBConnex-Brokered authentication) does not function when the Mac Profile contains Server names for the SDConnex servers in the SES Infrastructure.  Where SDConnex servers are identified by their IP addresses, this works fine.

Issue: In SecureDoc’s Pre-Boot Network-brokered authentication for FileVault 2 devices, such devices currently are unable to resolve a server by Server Name (e.g. DNS name).

Work-around:  Until WinMagic has found and corrected this issue, please ensure that the SDConnex Server list is populated only with the IP addresses of the SDConnex server(s) in your SES implementation.

Solarflare Ethernet cards SFN8522-Plus |SFN6122F (although supported in 7.1SR6 HotFix 3) will not be supported (initially) in v7.5

WinMagic intends to have a resolution to this problem in v7.6
Reason: The base Linux kernel version in the SecureDoc Pre-Boot was changed/upgraded, and this new kernel does not yet have support for these Ethernet cards.

Work-around: Customers may wish to consider staying on v7.1SR6 HotFix 3 until v7.6 is available.

PBL/PBLU. Wireless network does not work in 64bit pre-boot
Wireless network is not supported in 64-bit pre-boot using the Linux-based Pre-Boot for legacy devices (PBL) or the Linux-based Pre-Boot for UEFI devices (PBLU).
WinMagic will be looking to add this support for 64-bit in future versions.
Work-around:  Where devices MUST use the 64-bit Pre-Boot environment due to their hardware requirements (less common), then users are recommended to connect to a wired network connection at Pre-Boot.

New BitLocker Tamper Protection policies are now available within the SecureDoc client to enforce compliance by blocking unauthorized disabling of these security controls

There are 3 enforcement controls available:

1. Block access to Manage-bde.exe.  By preventing this application from running, most BitLocker controls won’t be accessible, i.e. Decrypt BitLocker, Suspend Mode, and others – even via power shell scripts.

2. Enforce Suspend Mode from being enabled.  SecureDoc monitors BitLocker Suspend Mode – and if BL Suspend Mode is enabled - SecureDoc will alert the user of this unauthorized action, log this event locally and send back to SES.  SecureDoc will immediately DISABLE BitLocker Suspend Mode without requiring a reboot.

PBLU - Does not work with Lenovo X1 Tablet (KabyLake) and Win 10 RS1 using Hardware-Encryption (HWE)

Issue:
Using the Lenovo X1 Tablet with Windows 10 RS1, SecureDoc’s Linux-based Pre-Boot for UEFI devices (PBLU) will not load up.  Customers were forced to bypass the issue by clicking the "a" key at the BIOS screen to use SecureDoc’s PBU (Native Pre-boot for UEFI devices) to bypass the issue.

Use of the following boot settings will correct the issue
"acpi=off reboot=pci"

These settings can be integrated into the Boot Parameters area of the Device Profile Advanced Options panel.

Waking from Hibernate on Panasonic CF-20 with SecureDoc Pre-Boot for Native UEFI (PBU) causes Blue Screen Error (BSOD) "0xc000000f"
This appears to be a Panasonic UEFI implementation issue. When waking up from hibernation the system doesn't follow the boot order but restores the OS using something else stored on hard drive. That's why customers encounter the Blue screen error – The hard drive is encrypted and data stored during hibernation cannot be used.

Samsung 900X3G Boot Takes unacceptable length to boot HWE - Boot Media Error
Issue: After Hardware Encryption, the Samsung 900X3G takes nearly 4 minutes to get past the Samsung splash screen.
Once the devices passes the Samsung Bios Screen, a boot error appears:
"Reboot and Select Proper Boot device or Insert Boot Media in selected Boot device and press a key"
Reason: The Samsung BIOS firmware doesn't support the required protocols for SED (hardware encryption) support. Therefore SecureDoc pre-boot fails to unlock the Self Encrypting Drive (SED) at pre-boot.

Under certain circumstances, files are not decrypted consistently  when Dragged/Dropped versus being Cut/pasted from SFE folders
Issue:
1. When a file is dragged and dropped, Windows is internally doing a cut/paste behind the scenes. 
=> Result: It remains encrypted
2. If right click and drag, then select copy from the context menu? Does that also
remain encrypted?
=> Result: It remains decrypted
When the file are copied by right click and drag, then select copy from the context menu or by press Ctrl+C and Ctrl+V.

[Dell 7450]: The black screen with "Please wait, this might take several seconds..."" is shown about 2 minutes before BL displays

SecureDoc client cannot access an Encrypted Folder (under SFE) where the folder path contains more than 123 characters in full path.

Dell Tablet 5179 PBLU32\PBL32: System is down after install BL

[SDFV2] Mac login password CANNOT sync with FileVault password after changing user password locally
Precondition:

• If there are two local accounts on a Mac device, such as user1 with password "1" and user 2 with password "2"
• Deploy SDFV2 package successfully and disk has been fully encrypted
• Two users exist now in the Unlock list

Steps:

• Login with user1 and change password for user2 to "22" through Setting -> User & Groups -> Reset Password
• Log out the current Mac user and log in with user2 and new password
• Mac will ask for update Keychain. Choose Create New Keychain
• Mac will ask for current account password in order to add this user Keyfile
• After type in the new password and click OK, Challenge Response window prompt out
• After typing in the correct Challenge Response and click OK

Expected result:

• User2 with new password "22" is added to key file list and able to login Mac Preboot with password "22"

Actual result:

• Now User2 need to login twice when rebooting the system. Once with the old password "2" to login at Pre-boot and again with the new password "22" to login to Mac OS X

Note:

• This is not SecureDoc issue. With only FileVault enabled, it has the same issue. Please see this link for details: http://apple.stackexchange.com/questions/159961/change-osx-encryption-filevault-password-to-match-login-pass

• Suggestions for customers who want to change password:
  • Modify password from within SES and send down the remote command
  • Use  WinmagicRecoveryaccount to login and then reset the password

SecureDoc does not have support for 802.1x authentication in multi-layer PKI environments
SecureDoc’s Pre-Boot environment does not support 802.1x if PKI environment includes intermediate Certificate Authorities for the issuance of the RADIUS (authentication server) certificate(s).

The reason is that WPA supplicant used by PBL requires not only Trusted Root CA but that all intermediate CA certificates have been provided locally.

[Dell E7450] PBU - "Start PXE on IPV4" screen displayed too long before loading to windows.
Issue: The "Start PXE on IPv4/IPv6" screen displayed over 2 minutes before the device can proceed to load Windows.

This is a Dell BIOS issue. WinMagic is working with Dell to determine how this can be resolved.

Lenovo X1 Tablet (KabyLake) - Mousepad/Trackpoint and Touchscreen not Functional in SecureDoc’s Linux-based Pre-boot for UEFI devices
Work-around:  Please attach an external mouse to these devices if mouse support is required, or change to SecureDoc’s Pre-boot for Native UEFI devices on this device type.

SecureDoc for Mac does not support the Touch Bar hardware. When SecureDoc is installed on Touch Bar-equipped devices it requires the use of alternate key strokes to emulate Touch-Bar function keys.

Microsoft Surface 4 devices require the use of the Driver Hook setting for Win10RS2 Upgrade/Clean Install
After SecureDoc PBA the platform is stuck with the "BlInitializeLibrary failed 0xc00000bb error" message.
This is caused by a problem in Windows RS2, which is anticipated to be corrected in RS3.

Workaround: Warm re-boot the platform with Ctrl+Alt+Del and at SecureDoc PBA, after inputting your password press the F3 key.
A new button will appear ("Configuration") that you can click on to change the boot parameters for PBU.
In this new configuration list, change the "Use Driver Binding" Feature to "No", and save the changes, and then click the Enter button to continue.

Failed to scan WiFi at Boot Logon with Broadcom BCM943228HMB 802.11abgn 2x2 WiFi Adapter
This WiFi adapter type is not supported yet.

Currently no support in SecureDoc for Fusion Drive devices
SecureDoc currently has no support for Fusion Drives

"Selected boot device failed" error when user manually selects to boot from WinMagic SecureDoc Logon using the Boot Device List in the BIOS.  This applies to Dell E6530 UEFI devices under Windows 10.
After deploying the package, boot the device and press F12 to access the device’s boot menu.
From the boot menu, select WinMagic SecureDoc Logon.
The user can attempt authenticate at SecureDoc’s Pre-Boot for Native UEFI, but this fails and the user is returned to the Boot menu.
The BIOS on this device type changes the Boot order, and removes or tampers with the SecureDoc boot element.

[SATA Driver] HP ProBook 645 G3 cannot wake from S3 Sleep with SecureDoc 7.5/Win10 RS1
The root cause is the AMD SATA driver - ver. 1.1.3.277 AMD SATA driver internally issues hardware reset to SED disk, which is the root cause (It seems the recovery behavior from SATA driver, upon failing to complete a 'write" cmd ...)

Work-around:  Switch the SATA driver back to Microsoft native driver for affected devices.

Error Loading Operating System on Lenovo M910q models

Dell 7480 devices configured in Win10 in BIOS/Legacy mode may receive error message "An error occurred while initializing pre-boot authentication (0x1)" after installing SecureDoc’s Boot Logon

[Dell XPS 13 9350] Error '0x9911" with unrelated  message will be shown when user’s submit SDForm containing a User name that contains an emotion icon
SecureDoc does not support Unicode (e.g. Chinese and certain special) characters at this time, and so emotion icons (emoticons or emojis) are not supported.

Work-around:  Limit the use of unusual characters.

Windows 7 devices having the Dell Wireless 1820 WiFi adapter will not be able to authenticate wirelessly under the SecureDoc Linux-based Pre-Boot (PBLU)
Work-around:  Customers whose devices contain the Dell Wireless 1820 WiFi adapter are recommended to connect to a wired network if requiring Pre-Boot Authentication over the network.

An error message can be displayed if a user is completing the Provisioning prompt to take ownership of a device while that device is unable to connect to a trusted Domain

During the process of accepting the user’s approval to take ownership of the device, SecureDoc requires the confirmation of the Domain that this is a legitimate Domain User ID. 
Without that formal confirmation from the domain, the device will remain in provisioning mode.

Work-around: SDConnex must be able to connect to a Trusted Domain.  The user’s next request for confirmation of ownership will then succeed.

Windows 7:  Failed to install Boot Logon using SecureDoc’s Pre-Boot for BitLocker  (SDOT) deployment where non-UEFI device already had 3 Primary Partitions
SecureDoc installer was unable to create its SDSpace partition since this device already was at the maximum number of primary partitions.

Work-Around: None:  Devices that already have 3 primary partitions are not able to install SecureDoc‘s management for Bitlocker.  This is an unusual scenario since Windows 7 devices normally run in BIOS/Legacy mode and not UEFI.

NOTE: While this was experienced under Windows 7, any device that already has the maximum possible primary partitions (3) under Legacy/BIOS mode might encounter this limitation.

[Yoga 910] Pre-Boot Network available icon incorrectly shows RED light when network connected by Ethernet adapter USB 3.0 (PN-RTL8153) when device is configured to utilize SecureDoc’s Pre-Boot for Native UEFI devices (PBU)
Issue: The USB 3.0 PN-RTL8153 doesn't work with Yoga 910 in SecureDoc’s Pre-Boot for Native UEFI (PBU).

Workaround: The Ethernet adapter works with the Yoga 910 using SecureDoc’s Linux-based Pre-Boot for UEFI devices (PBLU)

Failed to log into Boot Logon using PBConnex with an iKey 2032-protected key file (and when the option "Authenticate user against Active Directory") is enabled
When authenticating at PBConnex with a new user, and this user will be enforced to use token-protection from SES, if you have the Global PBN option "Authenticate user against Active Directory" enabled, AND the user does NOT exist in AD, the PBConnex login process will fail with Error 7033.
The reason: The credentials the user enters at PBConnex cannot be validated with AD, and the credentials also do not match the current user account in SES.

Dell Venue 11 Pro devices requires special handling to avoid Blue Screen halt
This is primarily required due to the internal behavior of Dell’s firmware for these devices. Dell Venue 11 Pro devices should be configured to be installed using a SecureDoc Device Profile that disables the “Use UEFI Boot Order” option in the Profile’s Boot configuration | Advanced Options panel. This issue was encountered on BIOS update A23, and may or may not apply to other BIOS versions.

SD-23227

SecureDoc’s Pre-Boot Networking does NOT work on Windows 7-UEFI with "Legacy Support Enable and Secure Boot Disable" enabled in BIOS settings
Network-based boot authentication cannot be used on UEFI devices where Legacy Support is enabled in the device's UEFI settings.  Devices on which this issue has been detected are: HP840 G3 and HP850 G3, though other devices may be affected.
This does not appear to occur on devices running WIn10x64 RS2 - UEFI.
WinMagic is working to resolve this as soon as possible in a forthcoming service release.

Loading issues with SecureDoc Linux-based Pre-Boot for UEFI devices (PBLU)
When Lenovo P51 devices are installed with the SecureDoc Client and configured to use the SecureDoc Linux-based Pre-Boot for UEFI devices (PBLU), upon power cycling these devices will successfully pass the Lenovo BIOS splash screen, but then will hang at a black screen. This issue occurs regardless whether Secure Boot is Enabled or it is Disabled.
This issue does not occur when the SecureDoc Native pre-Boot for UEFI devices (PBU) is used.

SecureDoc’s Linux-based Pre-Boot for UEFI devices (PBLU)
Does not successfully unlock Self-Encrypting Drives on HP ProBook 645 G3 devices. WinMagic is working to resolve this in a future version.

Windows 7: Unable to boot into Windows after upgrading SDBM client from 7.1SR2A to 7.5
Scenario: SD Bitlocker-Management client already installed on Lenovo model T550 and BIOS version is 1.17. If the customer should then upgrade the SES Client to version 7.5, Pre-Boot Authentication fails because of BIOS limitations relating to the upgrade.
A new installation will work fine, so the workaround is to uninstall the old version and then reinstall the newer version.  Earlier versions of the BIOS did not have this negative effect.
Work-around:  1 – Decrypt and uninstall SecureDoc under its old version, then install V7.5. 

BitLocker Devices running Windows 7 on UEFI platform may encounter the BitLocker Recovery screen after successfully logging into SecureDoc’s Pre-Boot Logon environment for BitLocker (SecureDoc “on top” of Bitlocker, or SDOT)
This limitation appears under a combination of very specific settings:

Conditions:

• SD Client is installed, and its Installation Package is set to NO provisioning, and the SecureDoc Pre-Boot for Bitlocker is enabled, and
• BitLocker is encrypting ONLY the OS Drive and
• BitLocker is Encrypting Used Space Only

THEN:

• The SecureDoc Pre-Boot Logon Screen is shown, the user logs in successfully
• The device does not smoothly transition to the Windows login.
• Instead, it shows the Bitlocker Unlock prompt, and
• The user has to unlock the device using that process

Attempts to log into SecureDoc Client Control Center (SDCC) while creating an encrypted Container using Removable Media Container Encryption will result in error "The Master Boot Record (MBR) is not correct...."
The elements that create containers also are utilized in SecureDoc Control Center.  These are single-threaded application, and cannot handle two concurrent requestors (RMCE creating the encrypted container, and SecureDoc Control Center).
Work-Around:

Intel PleasantStar 121P NVME Self-Encrypting Solid-State Drive-equipped devices will experience BSOD system crash with SecureDoc 7.5

Failed to login BL by PBN user when PBN setting All user group is a member of All device group
Issue: In SES V7.1 the functionality was inconsistent. If the All User group is a child of the All Device group and the All Device group was not configured to allow Pre-Boot Network-brokered Authentication, but the All User group (which was in a sub-group relationship to the All Device group) does have Allow Pre-Boot Network-brokered Authentication, then such network-brokered authentication was allowed. However if customers used explicitly-created groups instead with the same parent to child group structure, network-brokered authentication was denied since the setting was being inherited from the Device group.
Solution:
SecureDoc’s use of Group to Group relationships had been inconsistent in the past, leading to customer confusion.
In this version, WinMagic makes it clear that PBConnex settings of the Group that contains Devices will be primary (e.g. the device-containing group must contain the settings that define PBConnex Auto-Boot or PBConnex network-brokered authentication).  
Where User Groups are used to define who can authenticate across the network, those User Groups must be subordinate to the device group.