Please note that WinMagic is deprecating SecureDoc V4 Pre-Boot Authentication (PBA) support for SEDs in favor of the fuller function, more capable, V5 Pre-Boot Linux (PBL). The existing V4 support for SEDs will remain in the product for the time being but will not be maintained or enhanced. We recommend that customers migrate to V5 PBL over the course of the next year.
WinMagic has done extensive work to improve, streamline and augment the security surrounding the initial deployment of Key Files during the process of installing the SecureDoc Client software, bearing in mind that many customers have widely divergent requirements relating to how devices are used during and after initial installation. Some customers install SecureDoc while the primary device user is on or will be on the machine, while others may need to protect new devices before the end-users of those devices have been defined, as well as other scenarios.
Please refer to the When SecureDoc server is upgraded to version 7.1SR5 HF4 from previous versions (6.5 or earlier) and the Device Provisioning Rules sections under the Creating Installation Packages for Windows chapter in the SES User Manual to understand how these new settings work, in order to inform your own use of these new features, particularly as they operate in a way that cannot be easily migrated from the previous methodology to the new methodology. Upon upgrading from an earlier version, you will need to adjust each of your existing Installation Packages to reflect the deployment methodology that will meet your security design.
System requirements and supported devices - including tokens and Smartcards - for SecureDoc v7.5 are listed here.
Note: It is strongly recommended to initially install Full-Text Indexing feature (Full-Text Search) into the Database Engine, before performing an SES installation. More information can be found here: http://msdn.microsoft.com/en-us/library/ms143786(v=sql.100).ASPX
During the installation of SES, if Full-Text Indexing has not been installed, a message will appear indicating the absence of the Full-Text Indexing. This message will not allow the user to stop the installation of SES which will require retrofitting Full-Text Indexing into an existing SQL Server.Note: Use of the SES Console will require the user to have at least local admin rights on the server or client device (e.g. Admin desktop) on which it runs, in order for the console to function properly.
Version 7.3 Features, Improvements included in this document
Version V7.3 contained a number of improvements and new features.
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-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>
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 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).
Overtake System Integrity Protection (SIP) function on Mac devices running macOS from version 10.11 onward
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:
Support has been added for the Crescendo C1300 smart cards from HID
SES Administrators can now centrally manage profile updates for OSA clients
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.
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
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 v184.108.40.206 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".
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:
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).
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.This issue has been corrected.
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:
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.
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.
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.
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.This has been corrected in this version.
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.
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.
This issue is fixed.
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: 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.
As a result of the above, the package was installed, SecureDoc’s Boot Logon/Pre-Boot was installed and encryption was completed.
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
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.
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
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.
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.
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.
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.
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.
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.
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).
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.
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.This issue has been corrected.
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.
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.
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.
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.
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.
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.
It was mistakenly doing this without first checking whether the user in question was in the excluded accounts list.This issue is resolved, and will now check if an excluded Windows user is logging in and if so, SecureDoc will no longer be able to create a key file for that excluded user.
An issue, wherein the USB port is disabled after deploying SecureDoc package to client device, has been corrected.
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.
Reduce number of steps required of SES Administrator when performing Bitlocker Recovery from the SESWeb browser-based console.
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
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
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).
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:
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
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
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.
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.
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
During password propagation - SecureDoc Enterprise Server will no longer update and send key files for individual users that exist on 100 or more computers
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.
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
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.This has been corrected in this version, and only the Users or Keys from the current folder structure will be displayed.
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:
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.
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:
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.
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:
These values can be combined for multiple reboot pauses. For example, WaitReboot = 3 is the equivalent of (1 + 2).Starting in 7.5, enabling this setting in the GUI will set a default value of “6”, which is a combination of 2 and 4 above. In addition, an empty text file is created to facilitate software that can monitor for this file and initiate the reboot via setting by the third party software. This capability provides for additional flexibility when creating captured images as well as simplifying the control of the reboots during the SecureDoc installation process.
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.
In this way, customers should experience the slow initial search only once, on first use of that card.
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
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).
User key files were still being created when users logged in at Windows, despite the users being in the SecureDoc Excluded Users 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
Actual (incorrect) result:
The "Wait for software distribution software to restart" feature should behave as follows, based on the following Profile and Package configurations:
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.
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).
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
Using this, Customers should experience:
|Device Support Reference Materials||
NOTE: For a complete device compatibility/support list, please refer to this WinMagic SecureDoc Website link: https://www.winmagic.com/device-compatibility
|CloudSync Support for Apple macOS||
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 7.3 LIMITATIONS||
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 enabledLimitation: It is required to have MS Office 2016 installed on systems prior to installing SFE. If SFE is installed on the system first, the MS Office 2016 installation process will report errors and fail.
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
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
New BitLocker Tamper Protection policies are now available within the SecureDoc client to enforce compliance by blocking unauthorized disabling of these security controls
PBLU - Does not work with Lenovo X1 Tablet (KabyLake) and Win 10 RS1 using Hardware-Encryption (HWE)
Use of the following boot settings will correct the issue
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"
Recommendation: Users should not use hibernation for these encrypted devices until a solution has been found in collaboration with Panasonic.
Samsung 900X3G Boot Takes unacceptable length to boot HWE - Boot Media Error
Under certain circumstances, files are not decrypted consistently when Dragged/Dropped versus being Cut/pasted from SFE folders
[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.SecureDoc File Encryption Folder Policies cannot reference a folder location whose full path contains more than 123 characters.
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
SecureDoc does not have support for 802.1x authentication in multi-layer PKI environments
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.Work-around: None
[Dell E7450] PBU - "Start PXE on IPV4" screen displayed too long before loading to windows.
This is a Dell BIOS issue. WinMagic is working with Dell to determine how this can be resolved.Work-around: None.
Lenovo X1 Tablet (KabyLake) - Mousepad/Trackpoint and Touchscreen not Functional in SecureDoc’s Linux-based Pre-boot for UEFI devices
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.Please refer to the SecureDoc install/user guide for Mac client devices – the list of Function Key equivalents available at the SecureDoc Pre-Boot for FileVault 2 is defined in an Appendix in that document.
Microsoft Surface 4 devices require the use of the Driver Hook setting for Win10RS2 Upgrade/Clean Install
Failed to scan WiFi at Boot Logon with Broadcom BCM943228HMB 802.11abgn 2x2 WiFi Adapter
Currently no support in SecureDoc for Fusion Drive devices
"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.
[SATA Driver] HP ProBook 645 G3 cannot wake from S3 Sleep with SecureDoc 7.5/Win10 RS1
Work-around: Switch the SATA driver back to Microsoft native driver for affected devices.
Error Loading Operating System on Lenovo M910q modelsWork-around for consideration: Use UEFI (Windows OS is natively UEFI under Windows 10) and create a package which has "Force direct boot into Windows" option enabled, this could help work around the need for double login. Note: this “Force direct boot…” option does not work under non-UEFI device environments.
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 LogonWork-around: Use one of the Pre-Boot environments for UEFI devices (e.g. PBU/PBLU) on this device configuration under SecureDoc V7.5
[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
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)
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.
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
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)
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
Dell Venue 11 Pro devices requires special handling to avoid Blue Screen halt
SecureDoc’s Pre-Boot Networking does NOT work on Windows 7-UEFI with "Legacy Support Enable and Secure Boot Disable" enabled in BIOS settings
Loading issues with SecureDoc Linux-based Pre-Boot for UEFI devices (PBLU)
SecureDoc’s Linux-based Pre-Boot for UEFI devices (PBLU)
Windows 7: Unable to boot into Windows after upgrading SDBM client from 7.1SR2A to 7.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)
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...."
Intel PleasantStar 121P NVME Self-Encrypting Solid-State Drive-equipped devices will experience BSOD system crash with SecureDoc 7.5There is currently no support for this disk drive. Equipment on which this issue has been encountered is primarily Lenovo X1 Yoga (Gen 1) devices having the Intel PleasantStar 121P drive installed.
Failed to login BL by PBN user when PBN setting All user group is a member of All device group