SecureDoc Enterprise Server Version 9.2 SR1

Administrator Manual

© Copyright 1997 - 2026 by WinMagic Corp. All rights reserved.

Printed in Canada

Many products, software and technologies are subject to export control for both Canada and the United States of America. WinMagic advises all customers that they are responsible for familiarizing themselves with these regulations. Exports and re-exports of WinMagic Inc. products are subject to Canadian and US export controls administered by the Canadian Border Services Agency (CBSA) and the Commerce Department’s Bureau of Industry and Security (BIS). For more information, visit WinMagic’s web site or the web site of the appropriate agency.

WinMagic, SecureDoc, SecureDoc Enterprise Server, Compartmental SecureDoc, SecureDoc PDA, SecureDoc Personal Edition, SecureDoc RME, SecureDoc Removable Media Encryption, SecureDoc Media Viewer, SecureDoc Express, SecureDoc for Mac, MySecureDoc, MySecureDoc Personal Edition Plus, MySe- cureDoc Media, PBConnex, SecureDoc Central Database and SecureDoc CloudSync are trademarks and registered trademarks of WinMagic Inc., registered in the US and other countries. All other registered and unregistered trademarks herein are the sole property of their respective owners. © 2026 WinMagic Corp. All rights reserved.

Acknowledgements

This product includes cryptographic software written by Antoon Bosselaers, Hans Dobbertin, Bart Pren- eel, Eric Young ([email protected]) and Joan Daemen and Vincent Rijmen, creators of the Rijndael AES algorithm.

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.OpenSSL.org/).

WinMagic would like to thank these developers for their software contributions.

Contacting WinMagic

WinMagic Corp.

11-80 Galaxy Blvd.

Toronto, ON | M9W 4Y8 | Canada

toll free: 1-888-879-5879

phone: (905) 502-7000

fax: (905) 502-7001

Sales: [email protected] Marketing: [email protected]

Technical Support: [email protected] For information: [email protected]

For billing inquiries: [email protected]

Who Should Read this Document

This document explains how to set up and use SES and is intended for an administrator audience. It assumes you have a working knowledge of your database and network infrastructure. This document explains only SES-specific procedures: you may also need to consult separate documentation, such as that provided by a token manufacturer.

Introduction to SecureDoc Enterprise Server (SES)

What SES Does

SecureDoc Enterprise Server is a robust encryption solution designed to protect company- wide devices with minimal administrative effort, enabling centralized security and protection for enterprise data. Using SES, you can automatically install WinMagic’s SecureDoc software on client devices in the enterprise, providing fixed disk and removable media encryption for all users while automatically creating the encryption keys and key files that protect those devices. All security-related information, such as keys, key files, user information and device information, is centrally stored and managed. SES also lets you remotely control client devices and helps you support users if they encounter encryption-related problems, such as a forgotten password.

With SES, SecureDoc can be deployed to all users, regardless of how or where they are connected to the company network, and whether they are using Windows, Mac, or Linux machines (desktop or laptop), including those with SEDs or Intel Anti-Theft protection. Users connected by LAN, WAN, VPN, dial-up or no connection at all can have SecureDoc disk encryption protecting their devices using the very strong AES encryption algorithm (256-bit). SecureDoc can even be used to protect the large drives and RAID controllers of servers.

Note: SES Console will require administration rights in order to function properly.

SES Components

Database (SQL Server) - Repository of all SES Data

The SES database is a SQL Server database that contains information about users, devices, and encryption keys as well as other SES-related information. Access to the database from SES is secured through an encryption key.

SES Server/SES Management Console - Browser-based management of SES

The SES Management Console provides a secure and powerful means to define how SecureDoc is to be deployed, to remotely control client devices, to help users recover lost passwords, to manage user and device information, and to perform all other SES functions.

SES for Web

SES for Web (SES Web) is a web-based console that provides easy access to common SES features, offer- ing the means for administrators and help-desk technicians to assist end users in recovering access to their devices if they forget their passwords. It is described in the online help available from the SES for Web console.

SDConnex - Secure communication between Devices and the SES Server

SDConnex is the communication engine for SES: it must be running in order for information to be sent to and received from connected client devices.

In SES Version 8.5, for customers whose communication needs include SES access for devices that are frequently outside the office LAN, WinMagic has introduced Gateway Servers into the client-to-server communication equation.

Use of a Gateway Server permits substituting the SDConnex Server(s) that might have resided inside a Network DMZ (De-militarized-Zone), then standing up a dedicated SDConnex server in the main network to serve off-LAN users/devices.

About Lenovo Support

The Gateway server will listen on the same Port as other SDConnex servers, but the SDConnex server dedicated to off-LAN devices should listen on a different port number, so that there can be no blending of Off-LAN and in-LAN device traffic.

SDConnex runs as a Windows service.

To allow load balancing, up to 16 SDConnex servers and Gateway servers can be associated with a single SES Device Profile.

Each profile (see “Profiles and Packages” on page 32), assigns a priority number to each SDCon- nex/Gateway server.

Servers with the same priority number are considered part of a group or "pool". Client devices will attempt to establish communication with SDConnex/Gateway servers in order of group priority, and then either randomly or in order of configuration within a group.

For example, consider an environment where there are six SDConnex/Gateway servers. One package might assign priorities as follows:

• priority 1 — servers A, B, and C

• priority 2 — servers D, E, and F

Devices receiving that package will use either A, B, or C server and only if all those servers are unavail- able will they use D, E, or F.

Another package might assign priorities differently:

• priority 1 — servers D and E

• priority 2 — servers F and C

• priority 3 — servers A and B

Devices receiving that package will use either D and E, then if necessary F or C, and finally, only if all other servers are not available, use A or B.

AD Sync - Synchronizing and leveraging your organization's AD or LDAP inform- ation

AD Sync, which runs as a service, is used to configure and monitor the synchronization of Active Directory information (users, folders, and groups) with the SES database.

About Lenovo Support

Rescue and Recovery

Lenovo’s Rescue and Recovery utility is supported: Lenovo devices with SecureDoc installed can use Rescue and Recovery to help recover from system crashes. However, Rescue and Recovery must be installed before installing SecureDoc.

Note that if this utility is used to create a custom disk image that includes a service partition, that service partition must be at least twice as large as the required contents to allow Rescue and Recovery to back up the partition. If there is not enough space available in the service partition, the Rescue and Recovery backup process will generate a user warning indicating the available disk space is insufficient for the backup. If this occurs, the user should accept the warning: all partitions will be successfully backed up except the service partition.

Deploying SecureDoc

Pre-Testing Candidate Devices for Compatibility with SecureDoc Pre-Boot

SecureDoc Enterprise Server (as of V8.3) offers a new "SecureDoc Pre-Boot Compatibility Test" tool, which will temporarily install SecureDoc's Pre-Boot, interrogate the details of the computer and determine whether the device should be compatible with SecureDoc's Pre-Boot Authentication, and will also produce - for each device type - guidelines that may indicate any needs for special handling.

All customers are strongly recommended to run this tool on an example of each make and model of device that will be installed with SecureDoc. This will provide customers insight into any device types that might require special handling.

More importantly, it permits customers to confidently move through the deployment of SecureDoc to the vast majority of device types that will install without any additional work.

Please see Appendix F for details on how to install and run the SecureDoc Pre-Boot Compatibility Test tool.

Profiles and Packages

SecureDoc is installed and initially configured on client devices using a set of files, known as an installation package, produced from SES. Those files reflect options set in several locations in SES that determine what SecureDoc features are available to users and how those features are configured:

• the global options, which act as default values for all installation packages and which apply to keys pushed to devices (for example, users added to devices through the console)

• the profile options, which are specific to a type of client device (Windows desktops/laptops/servers, Mac, etc.)

• the installation package options, which are specific to a type of client device.

Once SecureDoc has been installed, changes to its configuration can be made by simply changing the profile.

Distribution Options

You can choose which users/computers should receive the installation package via SMS. You can choose to:

• have all users of computers known to SMS receive the package and have their hard disks encrypted — this is the default behavior

• have only those users of computers known to SMS and in the SES database receive the package and have their hard disks encrypted — you will need to configure SDConnex to perform the necessary checking

• have machines encrypted without a known user

Installation packages can be configured so that the user is not notified that installation and encryption is in progress (“silent” install).

SES Certificates for Protected Communication

If you choose to limit encryption to those users in the SES database, you can populate that database from your Active Directory system. Follow the instructions in “Importing and Synchronizing User Records with Active Directory ” on page 61.

Note: Although SecureDoc can operate on dual-platform machines, deploying to such machines cannot be fully automated. In such circumstances, you should create an installation package configured to not run encryption automatically, then instruct the administrative user of that client device to follow the instructions in the SecureDoc documentation.

When to Use Remote Installation Packages

You should only consider using the alternative method, remote installation packages, if:

• you want to encrypt only some disks of the client device (installation packages encrypt all hard disks on the client device)

• you want to encrypt only some partitions of the client device (installation packages encrypt all partitions of the client device)

Computers set up using remote installation packages do not send information back to SES. As a result, they do not support the remote control or password recovery functions. Remote installation packages can be created only for users already in the SES database. For details, see “Appendix B: Creating Remote Installation Packages” on page 381.

SES Certificates for Protected Communication

An SES certificate is used to encrypt the initial communication between deployed installation packages and SDConnex, for ongoing communication with client devices, and to sign remote control commands so that the client can verify the command is legitimate. You can have as many certificates as you need, each stored in the SES database. Although one of the certificates will be considered the “active” one at any given time, other certificates can be used by SES.

For installation package communication, the initial communication is encrypted with the public key of the certificate that was active when the package was created. As long as that certificate is in the SES database at the time of installation on the client device, decryption is possible. The device’s record in the SES database will reflect the certificate used.

Any remote control command sent to the device will be signed with the certificate associated with that device in the database, even if that is not the active certificate.

In subsequent communications from a client device, SES attempts to send the currently active certificate to that device and, if successful, assigns the active certificate to that device’s record in place of the certificate used at installation. This occurs only when no remote control commands are queued up for that device.

You can import your own RSA keys as a PKCS#12 file from your certificate authority. The minimum key size must be 1024 bits. WinMagic recommends the use of 2048-bit keys to be compliant with NIST Spe- cial Publication 800-131A

The easiest way to obtain a PKCS #12 certificate is to install Windows Enterprise Certificate Authority service on your domain controller. Windows allows you to become your own Certificate Authority with the ability to manage certificates on your domain.

The other way of obtaining a PKCS #12 certificate is to purchase one from a public Certificate Authority like the following three public CAs.

• www.verisign.com

• www.thawte.com

• www.entrust.com

Device Authentication Certificates

In Version 8.3, WinMagic has added an option to permit advanced device authentication certificates for those customers that require certificate-based device authentication to their 802.1X wired networks. This is typically required in order for those devices to be able to continue with any other network communication.

The configuration of such certificates is covered the sub-section entitled "Device Authentication Certs" within chapter C4 (which is entitled "Setting SES Global Options").

Password (Device Access) Recovery

Password recovery allows users to gain access to their protected device, at which point they will be required to specify a new password.

Depending on how SecureDoc has been configured on the client device, password recovery can be performed in one or more of the following ways:

• users can perform their own self-help password recovery

• users can contact an administrator who uses SES to perform password recovery (challenge/response)

Password recovery requires that authentication questions and answers for individual users be recorded in SES (see "Authentication Questions Options" on page 49).

To avoid needing password recovery, users may be able to record a password hint they can use to remind themselves of their password.

Password recovery is available on Windows and Mac client devices only.

Options for Encrypting Removable Media

WinMagic offers two options for Removable Media Encryption: Full Media Encryption (Sector by Sector) and RMCE (Container Encryption).

For full media encryption, opening encrypted media on a third party device which does not have SecureDoc installed, requires a media viewer application (downloadable from WinMagic's website) to be installed.

Note: Not all third-party recipients of devices encrypted using SecureDoc will have the necessary local administrator rights to install applications. Determine whether this option is truly suitable, given the third parties with whom you will be sharing encrypted information.

For RMCE, the viewer is copied directly onto the USB and the encrypted media can be opened on a third party device without needing to install a viewer application (the viewer is included in a small un- encrypted portion of the USB device).

Using Folders to Organize User Information and Share Keys

Using Folders to Organize User Information and Share Keys

Folders in the SES database are used to organize user and device records and to allow the dissemination of shared keys to users and devices. Shared keys allow shared access to:

• department-specific partitions (performed on the client side)

• encrypted removable media (full or container encryption) (either by distributing multiple keys to users or using server-based access control, where keys are retrieved from the server when needed)

• network folders protected using SFE

• shared devices for PBConnex purposes (see “Using Pre-Boot Connex (PBConnex)” on page75).

Folders can be manually created or imported from Active Directory (see “Importing and Synchronizing User Records with Active Directory ” on page 101).

Folders can contain groups, used to associate users and devices for PBConnex purposes. By default, SES provides a single (root) folder, and an Administrators folder. Folders have a hierarchical relationship with each other. All users must belong to a folder (users cannot

belong to more than one folder).

Folder properties consist of:

• the keys assigned to them (these are inherited by users in any sub-folder or group in that folder)

• the users belonging to them (you determine whether users also belong to subfolders) Users become part of a folder in one of the following ways:

• membership is imported from Active Directory

• users are manually assigned to a folder

• users are automatically placed in the folder identified in the installation package used when SecureDoc is deployed to them (see “General Settings for Installation Packages” on page 144). Working with folders is explained in “Working with Folders ” on page 355.

SecureDoc File Encryption – Implementation Considerations

To implement SecureDoc File Encryption, there are several elements that contribute to deploying this functionality on an endpoint device such that it can be used by a user on that endpoint device.

SFE functionality (the ability to use SFE) is deployed to the Client Device through the Device Profile by enabling the SFE feature. Each device that has SFE enabled in its device profile will consume one SFE license, so enough licenses must be purchased to handle the number of devices that will permit their users to access SFE-protected files/folders.

In order for a SFE-capable device to actually encrypt/decrypt SFE-encrypted files or documents, it needs: A Policy, and a Key.

Each SFE Policy defines which FOLDER will be SFE-protected, and defines the KEY that will be used to protect the FOLDER contents.

The DEVICE holds the SFE policy information, and the DEVICE owns the SFE License-consuming SFE func- tionality through the Profile deployed to it.

SFE Policies can be either deployed:

• directly to the device through changing the device properties, adding the policy to the device,

• or the Policy can be applied to a Group, and the device added to the Group, through which the device will get the policy through attribution.

NOTE: Defining a Policy and applying it to a Client Device does NOT automatically send the required key to the users of the device. That step is still required.

The USER (of the device) must have, in his logged on Key File, the Key that will be used to read, update, write files into an in-policy FOLDER. Users can be provided the necessary Key in the usual ways

• directly to the user record, to the Folder the user resides in, to a Group that the user can be made a member of, directly to a device the user is known to use, etc, and each of these key distribution meth- ods requires an understanding of SES Key Distribution, covered elsewhere in this documentation.

Deployment Options:

SFE Policies can be flexibly deployed to DEVICES via adding those DEVICES into a Group – and then adding the Folder Encryption Policy (which can have been previously created, or can be created at the point of adding to the Group).

SFE Encryption Keys can be flexibly deployed to users via adding those users into a GROUP or moving them into a FOLDER to which the necessary KEY has been attached. By attribution, Folder or Group member users will receive the needed SFE Key.

WinMagic recommends the use of Groups rather than Folders for easy deployment and revocation of SFE Keys, as it is much more flexible to add/remove a user to/from a Group than it is to move the user to another Folder, and users can belong to multiple groups concurrently, whereas they can only belong to one Folder at a time.

If desired, one could have both users and devices in a single Group that deploys both the needed Key (to the users) and the SFE Policy (to the devices) in the Group.

SFE can be defined on the server side, the client side, or both.

On the server side, SFE can be implemented in one or both of the following ways:

• to apply SFE to shared network folders, create an SFE policy that points to those folders, choose the appropriate key, and send the policy to the appropriate devices (all users who should be able to view the shared network folder in decrypted form need the same key sent to them)

• to apply SFE to local paths on a device, create an SFE policy containing the environment variable (for example, "APPDATA" to protect the contents of the folder C:\Users\Admin\AppData\Roaming) and send this policy to the appropriate devices; the machine key on each device will be used to encrypt the local path

Setting up and Using SES: Overview of Steps

On the client side, if a client device (Windows only) received a profile that enables SFE, and the user has the appropriate privilege ("Config SFE"), the user can choose to apply SecureDoc File Encryption to any folder to which they have access, using any key they possess in their key file.

Once a folder is encrypted, only a user who logs in to a keyfile that contains the encryption key can view the decrypted contents of the folder.

Files moved out of the folder are automatically decrypted and files moved into the folder are automatically encrypted; encryption and decryption occur transparently. Bear in mind, as mentioned earlier, it is also possible to have "housekeeping" devices running SecureDoc automatically monitor SFE Policy-protected Folders for new files that are not encrypted. Upon detecting any new unprotected files, such "housekeeping" devices will automatically encrypt them with the key defined in the policy for that folder. This provides a truly innovative solution, allowing for the automatic encryption of files generated even by non-SecureDoc devices or processes (such as processes that generate reports, medical or other images, log files or any other documents into a shared folder).

Setting up and Using SES: Overview of Steps

1. Install SES. See “Installing SES” on page 47.

2. Review the available features and options to decide what combination of items meets your enterprise requirements. This might involve choosing your security policies, considering how many different profiles you will need, deciding uses of different types of encryption (including removable media), choosing your distribution method, etc.

3. Set up global options that will apply to all client devices to which you will deploy SecureDoc. See “Setting SES Global Options” on page 56

4. Set up import and synchronization of user records from Active Directory. See “Importing and Synchronizing User Records with Active Directory ” on page 101.

5. Optionally, configure PBConnex. See “Using Pre-Boot Connex (PBConnex)” on page 119.

6. Create the profiles and installation packages your enterprise needs.

7. Deploy SecureDoc to client devices. See “Deploying SecureDoc Using Installation Packages” on page 339.

8. Using the various SES tools and options, manage encrypted devices as needed.

C. 3

Installing SES

Choosing an Architecture

The components of SES (SES Management Console, SQL server database, and SDConnex) can all be installed on the same physical or virtual server, or on separate servers. All components need to be in the same LAN, which must also include client devices to be controlled via SES.

More than one SES Management Console may be installed on different machines within a single site, although each must point to the same database.

If desired, separate databases, each with their own SES Management Console, can be set up for dif- ferent sites. For example, you might have separate sites for different geographical areas. If you set up separate site-specific databases, each site distributes its own installation packages and encryption keys. This is useful if you want to keep the encryption methods of sites separate from each other.

The default communication time between client devices and the server is 60minutes (this is con- figurable for each profile). If you anticipate reducing this time, or if you expect to deploy SecureDoc to more than 10,000 clients, you should consider putting the SES Management Console and SDConnex on separate machines.

Step One: Installing the Software

System Requirements

Operating system, database, and hardware requirements for the SES Management Console are listed here (or at https://www.winmagic.com/support/technical-specifications if reviewing a printed version of this document).

Note: Please review these and ensure all server pre-requisites are satisfied before beginning to install SecureDoc Enterprise Server in your computer environment.

NOTE: For production implementations of SecureDoc Enterprise Server, WinMagic recommends that the Full Text Indexing feature be enabled in the database engine prior to the installation of SecureDoc Enterprise Server. Database Full Text Indexing is used to advantage in the SESWeb web-based console.

NOTE: IMPORTANT: In V9.0, SESWeb changes require that the URL Rewrite plug- in be installed into IIS before either installing or upgrading to V9.0.

This plug-in can be got at this web link: https://www.iis.net/downloads/microsoft/url-rewrite

1. – Please download this plug-in

2. – Execute the downloaded plug in executable and follow the steps indicated in the installer.

3. – Ensure the plug-in is enabled in IIS.

NOTE: For deployment and configuration of SESWeb, please utilize the Quick Deployment Guide; It provides a more easily-digested option for instruction on installing SES, generally, since it includes links to videos that cover most aspects of the SES Product initial installation.

SQL Security

SQL security is a major concern for the SES database, which will potentially contain all your encryption keys. It is natural for an administrator to worry about hackers and external attacks. Windows authentication is the recommended security mode, as it is more secure and you don’t have to send login names and passwords over the network.

Microsoft recommends that you implement common Best Practices to secure your SQL Server. Refer to

http://www.microsoft.com/downloads/details.aspx?familyid=da0531e4-e94c-4991-82fa- f0e3fbd05e63&displaylang=en

SQL Server Express Settings

Follow the SQL Server Express wizard, using the settings that conform to your corporate policies. In particular:

• install only the database services (selected by default)

• use of Windows Authentication Mode is recommended, but not required

• enable both Enable User Instances and Add user to the SQL Server Administrator role

Step One: Installing the Software

SES Features and SQL Server User Rights and Roles Requirements

SQL Roles Required for SES

WinMagic has determined that the following are the minimum roles that must be applied to the SQL account used when using SES:

db_datareader db_datawriter db_ddladmin public SD_admin SD_user

NOTE: When installing or upgrading SES, the SQL account being used must also be provided with the

DBCreator and public roles at the database engine level, in order to be able to create the SES

Database's

temp database during the upgrade, and to back up the database. Once the database has been cre- ated or

upgraded, the DBCreator role can be revoked for this account.

Please ensure that the above roles have been selected for the account you will use when logging into SQL when using SES.

Using SES with a Firewall

SES uses the following network ports, which need to be opened on your firewall if the SQL Server connection goes across a WAN connection that has a firewall. SES Management Console and SDConnex need to update SQL with any configuration changes.

Users must be able to share the \Microsoft SQL Server\MSSQL\Data folder.

When creating or upgrading the database, SES copies the database template files. In that case, the 139 and 1501 ports are used.

Note: For customers that have not installed SecureDoc before, please review Section 1 of the SES Quick Deployment Guide for a detailed understanding of the steps and user interface elements you will encounter during the installation of the SES software, or if desired, click on the following link to view a video that will guide you through the SES software installation steps: Video: https://youtu.be/T2J75QZTMQw Run-time: 2m24s

Installation Steps

Before you install SES, make sure no other programs are running.

1. Insert the CD, or download the installation file, and run Setup.exe.

2. Follow the instructions in the wizard.

3. The SES software is installed next. Follow the instructions in the wizard.

You can choose:

• Complete setup — installs SES and SDConnex on the same machine (for normal usage).

• Custom setup — allows you to choose whether to install SES or SDConnex, allowing you to install them on different machines, and/or to install multiple SDConnex connections (for large-scale implementations).

Step Two: Setting Up the SES Database and Key File

Introduction

SES information is stored in an encrypted database that is protected by a key file. The key file is protected using a strong password.

You can create both the database and key file at the same time (the system automatically creates the necessary encryption key) or, if a database or key file already exist, you can use them instead.

Note: Be sure to keep your key file for the SES database safe and secure, to protect the encryption keys it stores.

Setting Up a New SES Database

1. Run SES from the Start menu (Start >> SecureDoc Enterprise Server >> SecureDoc Enterprise Server). The Login to the database screen appears.

1. To use an existing key file, browse to its location, enter its password, and click Login Key File, then go to step 9.

To create a new key file, follow the steps below.

1. Click Create key file. The Create Key file screen appears.

1. Click Browse, navigate to the location where you want to store the key file, and type a name for the key file.

Note: If possible, create the key file in the folder where the database files are stored.

1. Click Save. The name appears in the Key File field of the Create key file screen.

2. In the Password field, enter a strong password for the key file. This password should be kept secret. You need it to log in to the key file and to gain access to the SES database, so must take care to remember it. Confirm the password by re-entering it in the Confirm Password field.

3. In the UserID field, enter a unique userID for the key file. This UserID will be used by the administrator who logs in to SES, and does not have to be a domain user ID. This also identifies, in the audit trail, which user made which changes to the database.

4. In the Key name field, enter the name you want assigned to the key used to encrypt the SES database. This key will be used to protect the sensitive data stored in the SES database and is required when logging into SES, but is not used for any other purpose.

5. Click OK. The Login to the database screen re-appears.

6. Enter the password you assigned in step 5, and click Login Key File.

7. Click Create new database. The Create new database screen appears.

1. From the Key List, which shows a list of available encryption keys in the key file you logged on with, choose the encryption key to be used to protect SES. Any user who wants to access SES needs this key added to their key file.

2. In the rare case that the database server is located in a different Domain than the SES Server, enter the name of your Windows domain otherwise leave this blank.

3. From the Server Name list, choose the MS SQL Server on which you want used to create the database files.

Note: If you are using SQL Server Express, enter the server name in the format server_name\SQLExpress.

1. In the Database Name field, enter the name for the SES database, following the naming conventions of your organization. A folder with this name is created, under the folder where you installed MS SQL Server.

2. Choose how you want to connect to the database files:

   • with a user account

   • with Windows authentication

   • with a system administrator’s account

Authenticate to Database using Windows Authentication

1. Check the Use Windows authentication radio button.

2. In the User name field, enter the user name and, optionally, domain of the user, who shouldbe given access to the SES database.

3. Click Finish. You are prompted to choose the default key for the user you created. See “Settingup Access Rights” on page 42.

Note: Windows authentication to the SQL database is considered more secure than SQL Account authen- tication because Windows Authentication details are sent across the network in encrypted form.

Authenticate to Database using SQL Server Authentication

1. Check the Use SQL Server authentication radio button. The prompts below will change to suituse of SQL Server authentication.

2. In the SQL Login ID field, enter the username of the SQL Account you havechosen to use. This could be the built in "sa" account or another. This account willneed SQL rights to create a database plus cer- tain other specific rights.

3. In the Password field, enter the password for the SQL Server account you hadchosen.

NOTE: SQL Account authentication is considered less secure than the use of Windows Authentication because SQL authentication details are sent across the network in clear-text.

Note: You must have a direct connection to the SQL Server to use this method.

1. Click Finish. You are prompted to choose the default key for the user you created. See “Setting up Access Rights” on page 42.

Setting up Access Rights

• 1. The access rights screen appears when you create a new database.

• 1. At this stage, you are configuring access rights for the main SES user. If you have more than one key available, choose the default key to be used to give this user access to the database.

  2. Choose the rights this user should have. Some of the access right options are not available, because this is the main administrative user for the database. To set up additional administrative users and access rights to the database, see “Adding Administrative Users” on page 460.

  3. Although you can choose which folders this administrator user has access to (by clicking Access To Folder), for an initial installation, which has only a single default folder, this is not

Backing up Your Key File

necessary. You can assign folder access later, when specific folders exist. For details, see

“Adding Administrative Users” on page 460.

• 1. Click Save. A message appears, indicating that server keys are being generated. When keys have been created, the SES Management Console opens (see “Understanding the SES Console” on page 96).

These server keys protect data being transferred between SES and the client devices. The server keys generated are shown in the RSA Server Keys screen (see "Server’s RSA Keys Options" on page 61) in the management console and can be changed to different keys if required.

Note: On installing, you have access to 10 SecureDoc licenses. To acquire more, follow the instructions in “Licensing Options” on page 86.

Backing up Your Key File

IMPORTANT: The DBK file and password should be backed up and stored for safekeeping (e.g. in a vault, safety deposit box, etc) since they provide the essential access to the encrypted database. If the key file should be destroyed or the password completely forgotten, then without these safely-stored backups it will no longer be possible to access the encrypted database and administer the SES environment.

Enhancing Mobile App for OTP and Number Matching on iOS/Android

Installing Mobile Application Setup

The mobile application on iOS and Android is being improved to support OTP (One-Time Password) and number matching. This upgrade aims to enhance security and provide a better user experience by allow- ing seamless OTP verification and numerical input verification for various purposes within the app.

To meet these requirements, we are implementing key enhancements to the iOS/Android mobile app. These improvements will elevate the app's functionality, ensuring a more secure and versatile user experience.

Steps to Enhance Mobile App for OTP and Number Matching:

1. Download and Install the App:

   • Go to the App Store (iOS) or Google Play Store (Android).

   • Search for the MagicEndpoint app.

   • Download and install the latest version of the app.

2. Enable OTP and Number Matching:

   • Open the MagicEndpoint app.

   • Navigate to the settings menu.

   • Enable the OTP (One-Time Password) feature.

   • Enable the number matching feature.

3. Set Up OTP Verification:

   • Follow the on-screen instructions to set up OTP verification.

Backing up Your Key File

• • Enter your phone number or email address to receive OTPs.

  • Verify the OTP received to complete the setup.

1. Configure Number Matching:

   • Follow the on-screen instructions to configure number matching.

   • This may involve setting up a numerical input verification process for added security.

2. Test the Features:

   • After setting up OTP and number matching, test both features to ensure they are working correctly.

   • Try logging in using OTP verification.

   • Use number matching for any applicable in-app verification processes.

3. Update User Credentials:

   • Ensure that your SCIM username and password are unique and saved in OKTA and the SCIM settings for basic access.

   • This ensures proper synchronization and access management. Additional Information:

   • Dynamic Lock Feature: This Windows feature uses Bluetooth to detect when your paired device (like a smartphone) is out of range and locks your PC for security.

   • MagicEndpoint App: This app facilitates secure authentication and access management, and it requires stable Bluetooth pairing to function correctly.

By following these steps, you can ensure that the MagicEndpoint app on iOS and Android is set up cor- rectly to use OTP and number matching, enhancing the security and functionality of the app.

C. 4

Setting SES Global Options

To set up these options, choose Tools >> Options and then choose which options you want to configure.

Since these options apply to all profiles and installation packages created, take the time to be sure they are set up correctly.

General Options

These options control the basic communication parameters for SES. In the Options screen, click General.

Server’s RSA Keys Options

The keys listed here are the ones that were created during SES database creation. At that time, a single certificate was created and set as the “active” one. For information on the use of the SES certificate (which contains an RSA pair), see “SES Certificates for Protected Communication” on page 42.

Changing the Server’s RSA Keys is optional. Under most circumstances, the keys created by the SES installation are sufficient. This needs to be modified only for strict security environments where you have to use certificates created from your own CA.

To work with SES certificates, in the Options screen, click Server’s RSA keys.

To add another certificate (it must contain, at minimum, a 512 bit RSA key), click Import and navigate to the PKCS#12 certificate’s location.

To generate another certificate, click Generate.

To make a certificate the active one, select it and click Set Active.

Note: The number of devices associated with the active certificate will gradually change as devices communicate with SDConnex. Once all devices have the active certificate assigned to them, the old certificate can be deleted.

To remove a certificate, select it and click Delete.

Note: You cannot delete a certificate that is associated with a client device.

Dynamic Update of Password Rules/Criteria Data from SES

Every time the admin makes changes to Password Rules (they will appear in Global setting only) the changes will be updated to ALL profiles (upon clicking OK on the UI).

There is a global option controlling the update of modified profiles to Clients in SES (Automatically update device's profile settings when profiles are modified). According to that option, the updated pro- file will be sent to the devices immediately or manually.

I. Keyfile Update (via SES Keyfile Push):

Previously, in older versions (< SES 9.1), after configuring "Password Rules" in the SES Console and deploying the package to the client, administrators could initially adjust the password rules in the "Global options" within the SES Server. Subsequently, they updated the key file using either the "Create key file" function or by modifying the user in the device tab.

However, with SES 9.1, administrators are only required to modify the "Password Rules" within Global Options. After modification, the administrator can apply the changes to all profiles by assigning them universally or selectively to specific endpoints upon profile update. (Refer to II. Profile for further details.)

Steps:

1. From SES Server, navigate to the main menu: “Tools/Options…/General/Password Rules”.

Option: “Automatically update device's profile settings when profiles are modified” is checked.

1. Modify any option in the “Password Rules” section. (Such as, changing the “Characters” = 3)

2. Click OK once to close the “Password Rules” dialog.

3. Click OK twice to close the “Global options” dialog.

4. In the SES console, “Device” tab, Method 1: Create key file:

   1. Right-click on the user and select “Create Key file” or press F3

   2.  A new “Create key file” dialog shows:

• 1. In “Create key file” dialog, try to modify these options:

• Apply user password from database:

+ Check: Re-use the old password from the database for the key file.

+ Uncheck: Input and confirm the new password for the new key file.

• Change initial password:

+ Check: The user must change the initial password after the first login.

+ Uncheck: Use the new password until the user would like to change it.

• 1. Click OK to create a new key file.

Method 2: Modify the user:

1. Right-click on the user and select “Modify User”.

2.  In the “Edit User Info” dialog, modify the password with the new password rules.

1. Click “Save”

2. On the SD client, communicate with server to receive the new key file.

3. Reboot and login BootLogon with the new password.

II. Profile (fully updatable with profile update)

From 9.1, the administrator can modify the “Password Rules” in Global options, these changes can apply to all profiles by assigning them to all profiles or just on the respective endpoints once updating the profile.

Steps:

1. From SES Server, navigate to the main menu: “Tools/Options…/General/Password Rules”.

.

1. Modify any option in the “Password Rules” section. (Such as: Characters, letter, Self-help questions)

2. Click OK once to close the “Password Rules” dialog.

3. Click OK twice.

4. SDDB dialog shows:

Modify any Authentication questions.

1. Administrator can choose 1 in 3 options:

   • Yes: Password Rules have been changed and it will send the modified profiles to all endpoints.

// Refer to the video clip: https://winmagicinc-my.sharepoint.com/:v:/g/personal/loc_nguyen_win- magic_com/ES-FKRXt1jFLsiAw3NdREPcBWpF1Gq7Fr2eDkoxeEtA7kA?e=GoVHE7

• • No: Password Rules have been changed but it will not send the modified profiles to all endpoints immediately. However, it will affect once the profiles are updated on respective endpoints.

Update for “Authentication Questions”

• • The administrator must define the “Authentication Questions” before adding them to “Password Rules”.

  • The number of “Authentication Questions” must be more than or equal to the ones in “Password Rules”.

III. Installation package (password rules set once during package creation and are not up-datable)

In all SES versions, we cannot modify or update the “Password Rules” in the package. All are disabled.

Authentication Questions Options

Authentication questions are used during challenge/response password recovery. Questions should be chosen so that the questions are meaningful to users (so they can recall the response) and that answers will uniquely identify the user (for example, “what was your mother’s maiden name?”, or “what month was your father born?”, or “what are the last five digits of your driver’s license?”). Questions should not be too easy to guess. For example, “what year were you born?” or “what is your employee ID#?” are not good questions, since someone who is not the valid user could easily know that information.

Use this function to create a library of questions from which you will choose when setting installation package options. How many questions will a be asked depends on the Password Rules set on the General tab (see “Appendix A: Password Rules” on page 474. Which of these questions is posed to a user is determined when the installation package is created. Since answers to questions are posed, and answers collected, as part of SecureDoc installation, be sure to build this library appropriately so that it is available when creating the installation package. It is not easy to ask users different questions after installation.

In the Options screen, click Authentication Questions

Enter the specified number of questions.

SES Administrator Manual

v9.2 SR1

NOTE: The required number of questions (or more) must exist in this list before the number of ques- tions can be defined in the Password Rule.

Key File Options

These options affect all key files created for all users whose installation of SecureDoc is based on this profile. Since key files are created automatically, and blindly, it is particularly important to ensure these settings are configured appropriately for your security needs.

In the Options screen, click Key file options.

Note: The actions (sending and updating key files) that may be performed as the result of these settings are automatic, so do not appear in the “waiting commands” display used for remote control commands. They do appear, however, in the audit log.

Other Options

In the Options screen, choose Other.

Licensing Options

In the Options screen, choose License.

Devices section:

The Device section of the Licensing screen displays the Total license counts you have purchased of each of the device types offered by SecureDoc Enterprise Server. These totals are shown in the Available column.

As you deploy SecureDoc to client devices, the Used column cells will be updated to reflect the current numbers of deployed devices of that type. Each additional device will consume a SecureDoc License for its device type).

Features section:

Note that some features are licensed separately (though not all device types support all features), and so consumption of these Feature license counts will depend upon the deployment of these features by enabling those features in the Device Profile settings you have defined. The Used column here will reflect the current number of devices that are configured to utilize each of the licensed features (e.g.

SecureDoc File Encryption) among the deployed devices (each, again, consuming its appropriate SecureDoc License type.

WinMagic provides customers with License Files that contain the number of licenses of each type that they have purchased, so customers will use this screen to load license files in order to alter their license count totals within the product.

See “Acquiring SecureDoc Licenses” on page 353 for information on how to load a license file following purchase of your initial or any additional licenses.

Note: Devices in the Purged Devices area and int the Recycle Bin are excluded from license calculations: see “Purging and Restoring Devices” on page 452.

SES License

Implementing SES-Controlled Management of BLE License Pool involves consolidating all client endpoint types, comprising Win/Mac/Linux, into a unified pool, while keeping Servers distinct. The introduction of Bluetooth Low Energy (BLE) licenses within SecureDoc (SD) functions on a per-device licensing basis. SDConnex actively prevents devices from falsely claiming BLE protection for keyfiles.

Several scenarios and operational processes arise in this setup. For instance, if a client erroneously switches locally to BLE and wrongly reports keyfile protection as BLE on an unlicensed device, SES should supply a password-protected keyfile. Additionally, a script is deployed to generate a warning notification upon surpassing BLE limits, prompting the keyfile to revert back to password protection.

In a different scenario, if a client requests a BLE-protected keyfile from SES, the response will contain a password-protected keyfile. SES might include specific data attributes to alert the client of dwindling licenses, allowing the client to notify the user about the depletion of licenses.

SES shows licenses that are available and used. SES Console:

After exceeding the loaded license count, there is a warning message showing on SES Console : "Num- ber of deployed installations exceeds the loaded license count. Contact WinMagic for additional licenses."

SES Administrator Manual

v9.2 SR1

.

SES Web:

Device Authentication Certs

As mentioned earlier, WinMagic has added an option panel that permits the definition and management of advanced device authentication certificates for those customers that require certificate-based device authentication to their 802.1X wired networks using a shared or global certificate that can be used by all devices and which may be required in order for those devices to gain certificate-authen- ticated access to a strongly secured network.

This new panel is entitled "Device Authentication Certs" and is located below the License Options panel in the SecureDoc Global Options section. Customers must have created or purchased Certificates which can be imported into the list shown in the panel below.

NOTE: ONLY customers that require shared/global Certificate-based Device Authentication to their net- work under 802.1X should import certificates using this panel, as the existence of imported certificates will mandate the use of those certificates in Device Profiles later in the implementation process.

If in doubt, please contact your Networking team to discuss whether your network requires Certificate- based 802.1X authentication.

To insert a new Certificate into this list:

1. Click on the Import button, and in the file picker panel that will appear, navigate to the disk loc- ation where the certificate PKCS#12 file exists.

1. Choose the file, and click OK to accept it.

The file should now appear in the list of available Certificates.

To Delete an existing Certificate:

First, determine whether the certificate to be deleted is not referenced by any Device Profiles. Any cer- tificate whose "Profiles" column contains a value of 1 or greater cannot be deleted - such certificates are currently associated with one or more Device Profiles. The association to - or dissociation of Cer- tificates from - Device Profiles is covered in the Boot Configuration settings covered later in the Device Profile segments of this manual.

C. 5

Understanding the SES Console

Running the SES Management Console Interface

1. Choose Start >> All Programs >> Secure Doc Enterprise Server >> SecureDoc Enterprise Server. The Login to the database screen appears.

Note: The SES Management Console launches automatically once you have set up a database and key file.

1. To log in using the existing key file and an established connection, enter the password and log on.

To log in using a different key file or when establishing a different connection, follow the steps below:

1. Clear the Automatically connect... option. Database Information area fields appear.

2. If the correct key file does not appear in the Key File Path field, click Browse and navigate to it.

3. In the Password field, enter the key file password, and click Login Key File. The Database Information area becomes enabled.

1. Specify the server and database you want to connect to, or click Create new connection to create a new connection.

1. Click Login.

SES Administrator Manual

v9.2 SR1

About the SES Management Console Interface

Console Components

The navigation pane (left side of the screen) is described below. The bottom of the information pane (right side of the screen) displays the total number of items of the selected type (for example, if the Groups tab is selected, the number of groups). If the alert option has been set (see “Other Options” on page 83), an alert appears in this area if a device has not communicated with the server for the specified number of days.

Adding, Modifying or Deleting Users, Devices, or Keys

This document explains how to add users, devices, and keys to the SES database. To modify any item, right-click on it and choose Modify from the pop-up menu. To delete any item, right-click on it and choose Delete from the pop-up menu, or press the Delet e key. Deleted users, client devices, and keys are moved to the Recycle Bin.

Navigation Pane Areas

SES Administrator Manual

v9.2 SR1

Interpreting Data

For information on the icons and symbols used in the console interface, choose Help >> Legend.

C. 6

Importing and Synchronizing User Records with Active Directory

Overview

SES’s integration with Active Directory imports AD information into the SES database and keeps it synchronized as AD is updated.

Note: Although it is possible to create or modify users, devices, and groups in the SES Console and SES for Web Console, such changes will not be synchronized back to AD. If an AD entity is manually adjusted in one of the consoles, those changes will be over-written at the next synchronization.

Synchronization takes two forms:

• partial, where only the changes to the synchronized items since the last synchronization of the domain are picked up

• full, where all specified objects are re-imported, capturing all changes including deletions.

Note: Password changes made in AD are not synchronized to SES.

The following SES components are involved:

• SES General Options, which set global settings for what is to be imported (although these are read each time full synchronization is done, it is recommended that you set them before using AD Configuration the first time): see “Setting up Active Directory-Related Global Options” on page 102

• the AD Configuration utility, used to select the objects to be imported from Active Directory, mapping them to specific tables and fields in the SES database: see “Setting up the AD Configuration Utility” on page 105.

• the AD Sync service, which keep data synchronized

• the AD Sync Configuration Console, where AD Sync is configured and monitored: see

“ADSync results in SES Console” on page 110

Setting up Active Directory-Related Global Options

1. In the SES Management Console, choose Tools >> Options.

Although the majority of customers find it valuable to import their Active Directory information in the form (Organization units full of users) to become Folders full of Users in SecureDoc, it is possible to not import such structures from AD, and instead only import Users. In such a case, the following options should be understood and utilized, if desired.

1. Click OK.

Note: When new AD Sections (e.g. OUs, other structures) are being added to the definition of what to import from active directory, it is important to restart the ADSync service after changes have been so that the ADSync service will read and utilize the altered definition list. Otherwise, ADSync will continue to synchronize only the objects in the definition list as it was when the service started. ADSync only reloads its configuration definition list when the service starts or is restarted.

AD Data Synchronization Default Behavior

Default Mapping

AD Configuration, by default, will map only the following objects:

• organizational unit (mapped to SES folders)

• group (mapped to SES groups)

• built-in domain (mapped to SES folders)

• user and certificate (mapped to SES users)

Default Configuration

By default, synchronization occurs as follows:

• partial synchronization every hour (if errors occur during this process, an attempt is made to repeat it every 20 minutes)

• full synchronization whenever the AD Sync service begins

By default, log files are rolled over at midnight or when they reach one million messages. Only the past 30 log files will be retained.

By default, four AD Sync service workers are configured, with only one scheduled to run and scheduled to sleep every 5 seconds.

To change any of these settings, modify the configuration file (see “Changing Default Configuration” on page 115).

Certificate Use

If users have more than one certificate, AD Configuration chooses the first certificate that meets the following criteria:

• has the most recent “issue date” (creation date)

• has not expired

• has appropriate key usage (if specified in SES options) — see “General Options” on page 56.

If such a certificate is found and can be used by SecureDoc, it is used. If not, the user is not assigned a certificate.

Note: The AD Sync service can import from Active Directory DER-encoded X.509 certificates.These are stored in an attribute as separate values, or in the content of a PKCS7 envelope.

Setting up the AD Configuration Utility

Getting Started

The AD Sync service is configured with the SecureDoc Service Configuration console.

1.  From the Start menu choose SecureDoc Enterprise Server >> SecureDoc Services Configuration.

2. Click AD Sync Service (in the left pane). The AD Sync Service Register View screen appears.

1. Choose whether you want the service started automatically (when the server starts) or manually. Automatic Startup is recommended.

2. Service Log on. This set of radio buttons determines how the SDConnex Service will run, and under which security account. Choose whether you want the service to log on to your network service or local system. Consult your Microsoft documentation for clarification of how these accounts work, and what settings might be required to use them, particularly where your Database engine is not running on the same server as ADSYnc, in order to determine the appropriate setting for your environment.

3. Alternatively, enter an account name and password that has access to the localservice or network service. This may be the preferred method in Domain implementations,, and is usually recommended by WinMagic since it allows for the setup of a Domain Service Account that can be provided the needed rights within SQLServer, and which can be set with a complex, never- expiring password so the service will always start when the server starts (if start up is automatic).

4. Click Register. The AD Sync Service screen changes to show two configuration tabs.

1. Complete the SecureDoc Services Configuration tab.

1. Click Login, then click the Sync Config tab. This tab shows, on the left, an expandable tree structure of the servers (domains) and objects in the AD structure to which you have connected. On the right it shows the attributes of the currently selected object. When first opened, it shows the contents of the current forest, that is, the forest to which the machine you are logged on belongs.

Note: Although all Active Directory objects are shown in the tree, the SES Console is only able to show Organization Units, Groups and Users; However, the SESWeb console shows imported devices within the Compliance Reporting Management tool section.

Choosing Items to Be Imported

1. To add a new domain to the tree, right-click on Root of Tree View and choose Add Domain. The Add Domain screen appears.

1. If AD Sync is running on the same MS network as AD, click Browse Forest and choose the target domain from the tree, then click OK.

The Server Name and Root Naming Context will be automatically populated.

1. Select whether the server is MS Active Directory or Generic LDAP server.

Note: Due to issues in this and some prior versions regarding support for LDAP, in V9.0SR1 the Generic LDAP Server option has been disabled and customers can only choose MS Active Directory. This has been done to prevent customers attempting to configure LDAP when such configuration would be problematic.

1. ​

1. Click OK. Once successfully registered, expand the tree to browse the domain. (To connect and expand a previously added domain, click on it and authenticate.)

2. Select the entries to be imported/synchronized. Click any object in the domain to see its properties on the right side of the screen. Checking the box adjacent to an object indicates that the object, and all relevant objects under it, should be imported and synchronized. To de-select an object, expand the tree and clear the box for that object.

3. Right-click on a domain and choose Parameter Settings.

A new screen appears, showing server parameters (which cannot be changed) in the top part of the screen. To change any of these parameters for a domain, copy and paste the parameter to the bottom part of the screen and change the value appropriately. These settings affect all imported objects in the domain. For details on parameters, see “Domain Parameter Settings” on page 111. If it is necessary to synchronize information from several Active Directories, define each of the additional Active Directories as follows:

1. Right-click on Root of Tree View.

2. From the pop-up menu that will appear, click on the option entitled "Add domain".

3. In the Add Domain panel that will appear, add the information about the domain.

NOTE: It is not possible to use the Browse Forest button for second or subsequent Domains - you will need to add the Server Name, User Name, Password and Root Naming Context information manually. Once you click OK, the additional domain will appear below the existing domain(s), and you can expand it to select the entries to be imported and synchronized as you had done in step 6, above.

Forcing Full Synchronization (Optional)

To force synchronization, do one of the following:

• to synchronize all domains, click the Full Synch button

• to synchronize the objects of a specific domain, right-click on the name of the domain and choose Full Domain Synchronization

Full synchronization will begin the next time the AD Sync service begins.

To force synchronization immediately, stop then restart the ADSync service.

Removing Items From Being Imported

Removing items from the tree does not affect AD: these are simply removed from the SES database at the next full synchronization.

To remove items:

• to remove all domains and objects, right-click on the Root of Tree View (top part of the tree) and choose Discard Forests

• to remove a domain and all its objects, right-click on the domain name and choose

Discard Domain

In all cases, you are prompted to confirm the removal.

Saving Your Changes

To save your configuration settings, click Save Sync.

ADSync results in SES Console

When AD information has been imported, the results appear in the SES Management Console.

Monitoring AD Configuration/AD Sync Service

Click the Monitor action to monitor the progress of the AD Sync service.

Note that “active” threads are the AD Sync Service Workers currently running (see “Service Worker Settings” on page 118).

Domain Parameter Settings

LDAP Attributes Parameters

This set of parameters defines various LDAP attribute names used by the service to import user and group information.

LDAP Search Parameters

This set of parameters defines various values used to perform LDAP searches.

Database Parameters

This set of parameters defines various values used to perform database queries.

Service Parameters

This set of parameters defines the behavior of the service when importing entries from directory.

Additional Service Parameters

For most customers, the NETBIOS name will typically be the same as the domain prefix (e.g. if Domain name=Domain1.name.local, then NetBIOS name=Domain1). However some customers may utilize a dif- ferent NETBIOS name (e.g. name=Domain1.name.local, but NetBIOS name=americas) which can cause difficulties in user import through ADSync if not handled through the addition of an ADSync setting defined here:

NOTE: During ADSync configuration, administrators may see a reminder phrased something like this:

REMINDER: Format is NetBIOSname\user. NetBIOS name is usually the same as the domain name prefix. (e.g. if Domain name=Domain1.name.local, then NetBIOS name=Domain1).

If NetBIOS name is different: Use ADSync Configuration tool. a) Right-click on domain; b) Open Para- meter Settings; c) Set the "adsync.service.domain.netbios.name" parameter to 1.

NOTE: This is covered in some additional detail in Knowledge Base Article number 1921.

Changing Default Configuration

To change default configuration values, edit the WinMagic.SecureDoc.ADSync.Service.exe.config file (located in the WinMagic installation folder).

Synchronization Settings

Change the values of one or all of the parameters in the <appSettings> section.

<appSettings>

<add key="settingsCache" value="5"/>

<add key="eventTrackingTime" value="20"/>

<add key="defaultADSyncSchedule" value="60"/>

<scheduleFullSyncPeriod="1"/> scheduleFullSyncHour="3"/>

<add key="defaultADSyncOnExceptionSchedule" value="20" /> recreateAdSyncPerfMon="false"/> MoveDeletedUsersToRecycleBin="true"/>

</appSettings>

Service Worker Settings

<rsSettings>

<workManager applicationName="WinMagic.SecureDoc.ADSync.Service" waitOnTerminateThread="10000" >

<worker mode="on" name="ADSync.Service.1" assembly="WinMagic.SecureDoc.ADSync.ServiceWorker" type="WinMagic.SecureDoc.ADSync.ServiceWorker.ADSyncWorker" workSleep="5000" /

<worker mode="off" name="ADSync.Service.2" assembly="WinMagic.SecureDoc.ADSync.ServiceWorker" type="WinMagic.SecureDoc.ADSync.ServiceWorker.ADSyncWorker" workSleep="5000" /

<worker mode="off" name="ADSync.Service.3" assembly="WinMagic.SecureDoc.ADSync.ServiceWorker" type="WinMagic.SecureDoc.ADSync.ServiceWorker.ADSyncWorker" workSleep="5000" /

<worker mode="off" name="ADSync.Service.4" assembly="WinMagic.SecureDoc.ADSync.ServiceWorker" type="WinMagic.SecureDoc.ADSync.ServiceWorker.ADSyncWorker" workSleep="5000" /

</workManager>

</rsSettings>

Use to determine how many AD Synchronization Service Workers are scheduled to run. Each worker is defined in its own node: in the example above, four workers have been configured.

The worker mode property indicates whether the worker is running (“on”) or not. As a best practice, you should have active no more than 2 service worker threads per processor.

The workSleep property denotes, in milliseconds, the sleep cycle before the WorkManager reinitiates the execution of the worker. Recommended to retain at the default value (5000 = 5 seconds).

C. 7

Using Pre-Boot Connex (PBConnex)

About PBConnex

PBConnex allows user credentials to be authenticated against SES and AD at SecureDoc's Pre- Boot, before the operating system loads, either from a connected device or through a wireless connection (using supported wireless cards). Multiple users can have access to multiple devices through their group and folder membership.

NOTE: Only devices that have a SecureDoc Pre-Boot stage can make use of PBConnex. Please bear in mind that since SecureDoc's Pre-Boot for Apple macOS devices (aka SDOTFV2) was removed from the product in SES V8.2SR1, there is no further PBConnex functionality for FileVault 2-protected devices installed with SecureDoc V8.2SR1 or subsequent versions, macOS devices installed with 8.2SR1 or later will not respond to any PBConnex-defined functionality. However, macOS devices running earlier ver- sions of SecureDoc for macOS will continue to work with PBConnex if so configured.

PBConnex can be combined with the AutoBoot feature. Implementing this for users requires the fol- lowing to be set:

• the group needs to have the AutoBoot option enabled

• the PBConnex AutoBoot option needs to be enabled for the SDConnex being used for the user's device to communicate with SES (set in the communication options of the installation package -see "Profile Communication Options" on page 137 for Windows packages, page 1 for Mac packages)

• the selected SDConnex needs to be configured to support PBConnex AutoBoot (see "Registering and Configuring SDConnex Service" on page 345)

The AutoBoot feature either sends a temporary keyfile to the user's machine each time it boots, or the keyfile can be cached and used for subsequent authentication requests, with the user providing the pass- word to the keyfile. Caching is set up in the communication options of the installation package (see "Pro- file Communication Options" on page 137 ), When keys/assignments to device/groups change, a new preboot keyfile will be sent, with a new AutoBoot keyfile cache. Since AutoBoot keyfiles are created with a random password, in this circumstance the password may fail, but users can request that the AutoBoot keyfile be sent again in those circumstances.

About Groups, Folders, and PBConnex

Overview

Since devices actually perform the step of connecting to the SDConnex server where PBConnex network- brokered device access is being configured, either

1. Users need to be in the same group as the devices to which they are to be permitted access, or

2. the Users must be in a sub-group of the Device Group.

Devices can be

1. manually added to groups or

About Groups, Folders, and PBConnex

1. their membership in a group can be imported (in the same ways as Users, below), or

2. devices can be located in a folder that is associated with a group.

Users can become members of groups (or of sub-groups) in one of these ways:

•they are manually moved to a group

•their group membership was established in Active Directory and the Active Directory wassynchronized with SES (through ADSync).

Note the following: PBConnex network authentication and auto-boot functionality depends on thegroup containing Devices.

Users can be associated with device groups either by

•adding them to the Group, or

•by making a user group become a sub-group to the Device-containing group

Note: If a group of devices is a sub-group to a group of Users, the PBConnex settings in the UserGroup will have no effect for PBConnex authentication or auto-boot purposes.

Note: A simple rule of thumb to remember this is that it is the Device that is reaching out to PBConnex at Pre-Boot on behalf of the User.

An example will illustrate:

If PBConnex-driven Auto-Boot is required for a number of devices, those devices should be added into a Group and the PBConnex Auto-Boot Settings applied to that device-containing group.

So, if (say) one were to set the PBConnex Auto-Boot settings in a group that contains only Users, even though a device sub-group is added to it, that entire group structure will not Auto-Boot since the mas- ter group does not directly contain any devices. The Auto-boot settings of a User-Only or User super- group will not be used in either PBConnex Auto-Boot or PBConnex Network-brokered Authentication.

To correct this, make the User Group into a Sub-Group of the device group in question, and the devices would auto-boot correctly when they can reach the SDConnex server running PBConnex.

Similarly, if it is desirable that users be able to perform PBConnex-brokered authentication using their domain credentials, then the User Group containing those users should be a sub-group of the Device Group on which they wish to authenticate.

That the Device group should take the superior position in group relationships is made particularly clear when considering the use of PBConnex Auto-Boot:

In that scenario, there is no need at all for Users to be considered; Devices in a PBConnex Auto-Boot Group will communicate with PBConnex before a user enters any credentials. As soon as the device communicates, PBConnex will check the device’s Device group settings to determine if it is going to per- mit it to Auto-Boot.

The fact there may be a user present is of no consequence during PBConnex Auto-Boot - the user will not be asked to authenticate until the device Auto-Boots to the Windows Login screen.

More About Groups

In addition to the normal purpose of a group, for PBConnex purposes, group membership determines whether members of that group have or do not have access to the devices in, or associated with, that group.

For example, say that all members of the sales department can, in general, use any of the devices associated with that department. However, only the sales manager should have access to device X, which houses the sales tracking system. To handle this situation, you could have two groups:

• one containing all members of the sales department and all devices in that department (either directly added or contained in a folder associated with the group), granting access to the devices for all those users

• one containing all members except the sales manager and device X, denying access to that device for those users

Since “deny” is processed before “allow”, a user other than the sales manager will not gain access to device X.

Groups do not have a hierarchical relationship with each other. However, groups can be associated with other groups by being specified as a “sub-group” of another group.

Membership in a sub-group is the same as membership in a group.

Sub-groups inherit the properties of groups. For example, making Group A a sub-group of Group B means that all members of Group A have access to Group B’s keys. The group and sub-group remain separate entities, however, and are subject to change due to synchronization with Active Directory.

More About Folders

The allow/deny policy of a group is inherited for devices in folders associated with that group. However, it can be either inherited or blocked from devices in sub-folders. Using the example above, you could have:

• one group containing all members of the sales department except for the sales manager

• one group containing just the sales manager

• one folder containing all but device X, with device X in a subfolder

You associate the first group and the folder, with an “allow” policy, but for the subfolder you do not inherit this policy, therefore denying access to that device to all members of the sales department. You associate the second group and the subfolder with device X and grant access to that device for that group (which has only a single member).

Group Properties

Group properties consist of:

• the keys assigned to them (keys are shared with other related groups)

• the privileges that determine the kinds of functions users can do with the devices in the group

• whether or not AutoBoot is in effect for devices in this group (see “About Preboot Authentication (PBA)” on page 35 for details) — this remains distinct even if groups are related

Configuring PBConnex

• whether users in the group are allowed or denied access to the devices in the group (either placed there directly or through association of their folder to the group) — if a group has neither allow or deny access defined, it has the access defined for the groups to which it is a sub-group; if those groups contain both “allow” and “deny” access, however, the “deny” access takes precedence

• whether or not users in the group will, on first connection through PBConnex, have a local copy of the key stored on their machine (this will be used, if a wired or wireless network connection cannot be made, for PBA)

• parent groups (the groups the group is related to)

• FFE network folders (view only)

Note: Although groups specify privileges, users also gain privileges based on the settings in the key file created for them during deployment. Those privileges are combined with those in the group. For example, a user with admin rights in their key file will also have admin rights to all group devices they have access to, even if the group privileges grant only user rights.

Configuring PBConnex

Follow these steps to configure PBConnex:

1. Place users in groups manually (right-click on the user and choose Member of Groups, or right-click on the group and choose Add Users to the Group) or through Active Directory synchronization — see “Importing and Synchronizing User Records with Active Directory ” on page 101.

2. Set global options for PBConnex — see “Setting PBConnex Global Options” on page 122.

3. Deploy, to all relevant devices, a profile that grants the use of PBConnex on that device — see

“Profile Communication Options” on page 137.

1. Set up group PBConnex access policies — see “Setting PBConnex Access Policies (Group)” on page 124.

2. Add devices to groups either manually (right-click on the user and choose Member of Groups, or right-click on the group and choose Add Devices to the Group) or through association (see “Associating Devices (in Folders) with Groups” on page 124).

Note: Until groups are configured for PBConnex, users created through the deployment process will still be able to access their encrypted devices by using their local key.

Setting PBConnex Global Options

Choose Tools >> Preboot Network (PBConnex) >> PBConnex Global Options.

Setting PBConnex Access Policies (Group)

Setting PBConnex Access Policies (Group)

Open the group (double-click on the group name in the console or right-click and choose

Group Properties) and click PBConnex Access Policies.

Choose whether group users are allowed (Allow) or not allowed (Deny) access to devices in this group.

If you want the key file protecting the device to be stored on the client device (allowing conventional authentication, that is, authentication done locally, not using the network), check Save Key File to client machine.

Note: A user whose Active Directory account is locked cannot gain access to a device unless the Save Key File option is chosen.

Parent groups are listed on the Member of Groups tab of the group properties.

Sub-groups are listed on the bottom-right pane of the SES console as “Group members of the group”.

Note: Although it appears that you can set different access policies for sub-groups, in reality they inherit the policies of their parent group.

Associating Devices (in Folders) with Groups

Right-click on the folder containing the devices you want associated with the group (and, therefore, with the users in that group) and choose Member of Groups, then choose the groups to which the devices in the folder should be associated.

- or -

In the folder properties of a folder containing the devices you want associated with the group, click on Member of groups, click Add Group, and then choose the group to which the devices in the folder should be associated.

Checking PBConnex Access

To see which devices a user is allowed or denied access to, choose Tools >> Preboot Network (PBConnex) >> Check PBConnex Access >> By User and choose a user from the list, or right-click on the user record and choose Check PBConnex Access.

To see which users are allowed or denied access to specific devices, choose Tools >> Preboot Network (PBConnex) >> Check PBConnex Access >> By Device and choose a device from the list or right-click on a device record and choose Check PBConnex Access.

Resetting User Login

Once login limits (see “Setting PBConnex Global Options” on page 122) are reached, you need to reset them in order to allow users access to shared devices again.

Choose Tools >> Preboot Network (PBConnex) >> Reset User’s Failed Login and do one of the following:

• To reset the failed login of a specific user on a specific client device, select a user and a client device and click Reset.

• To reset the failed login of a specific user on all client devices in the groups, select a user and click Reset User.

• To reset the failed login on all users and client devices in the groups, click Reset All User.

Deleting Groups

Deleting a group will not delete its users/devices, its sub-groups, or the users/devices in its sub-groups. What will be deleted is the relationship between the group and its contents. To delete a group, select it and press Delete, or right-click on it in the Groups tab and choose Delete Group.

C. 8

Depending on which Device Category you chose, the available Device Profile Types available will be one Installation Packages for Windows

When SecureDoc server is upgraded to version 9.1 from previous ver- sions (6.5 or earlier)

Note: Starting from SecureDoc Enterprise Server V9.0 a new feature that permits tracking the deployedF state of endpoint devices installed with SecureDoc. This functionality did not exist for clients still running an older version of the client software (e.g. V6.5 or earlier). Since those earlier-version Installation Packages did not have settings that would have define the Deployed state of devices, any devices installed from previous-version installation packages will have a Deployed state of "Unknown". By editing the Deployment rules and saving the Installation Package, that will bring it up to Version 9.0 compatibility, and devices installed from it after the change will show their correct Deployment status.

When SecureDoc Server is upgraded to V9.0SR2 from previous versions (including to V9.0)

When SecureDoc Server is upgraded to V9.0SR2 from previous versions (including to V9.0)

Testing Candidate Devices for Compatibility with SecureDoc Pre-Boot

In V9.0, WinMagic has introduced a new "SecureDoc Pre-Boot Compatibility Test" tool, which will tem- porarily install SecureDoc's Pre-Boot, interrogate the details of the computer and determine whether the device should be compatible with SecureDoc's Pre-Boot Authentication. Please see Appendix F for details on how to install and run the SecureDoc Pre-Boot Compatibility Test tool.

Overview of Steps For Creating Windows Installation Packages

1. Set up SES options (see “Setting SES Global Options” on page 56).

2. Create Create a device profile (see "About Device Profiles" on page 128).

3. Set installation package options (see "Configuring Installation Package Settings" on page 253).

4. Create installation package files (see "Creating Installation Package Files" on page 288).

Once you have completed this whole process once, thereafter any changes you make to the profile can be manually applied to a client device (by right-clicking on the device) or to an entire folder of devices (by right-clicking on the folder) and choosing Assign profile to devices.

Alternatively, you can have changed profiles automatically apply to those client devices that originally received them by using the Automatically update device's profile settings when profiles are modified option in the SES General Options (see “General Options” on page 56).

Note: Automatic profile updates using the last-mentioned SES General Option is convenient, but customers should be cautioned that in organizations with a lot of devices, it can cause mass profile updates to endpoint devices. SecureDoc has mitigated this network load by not permitting the SES server to notify client devices that such changes are pending, but rather it applies these changes to the devices when the client devices perform their next available network "touch point" with the SDConnex server.

Note: Recommendation: The ideal time to make profile changes that will affect a large number of devices is (if practical) to apply the change to the profile details in the SES Server at a point after the normal periods of high SES communication load (such as first thing in the morning as users log on to their computers for the first time). In this way, as client devices "touch base" with the SDConnex server, they will download and apply the profile changes in a more or less time-staggered way, and do it during a point in the work day where immediacy of communication with the SDConnex server is not as important as it is during the start of the working day.

About Device Profiles

A profile sets most of the parameters that will define the long-term behavior of the SecureDoc client, as well as some of the SecureDoc installation settings that you want performed on client devices. Once you have set up a profile, you associate it with installation package settings to have it used in the package sent to client devices. Unlike package settings, profile settings can be changed, and can be deployed to devices that had previously been installed with the SecureDoc client software and take effect, after installation has taken place.

The profile determines general aspects of how SecureDoc will behave and look on the client device, for example, what the Preboot Authentication (Boot Logon) screen looks like, what kind of communication is available between the client device and the SES server, and so on. You can create as many profiles as are necessary — for example, you might create one profile for stand-alone client devices and another for those on the network. Alternatively, you might use different profiles for different groups in your enterprise.

Each profile consists of the following groups of data:

• General options, to specify how SecureDoc behaves on the client device — see "SecureDoc Profile General Options " on page 131

About Device Profiles

• boot text and color options, to specify the appearance and content of Boot Logon program on the client device — see "Text, Color and Logo Options for Boot Logon (PBA)" on page 224

• disk access control to limit or monitor access to encrypted or decrypted disks — see "Disk Access Control (SecureDoc Enterprise for Windows clients only)" on page 229

• boot configuration options, to specify other options of the Boot Logon program on the client device — see "Boot Configuration Options " on page 231

• port control options, to optionally specify which devices can be attached to a client device

— see "Port Control Options (SecureDoc for Enterprise for Windows Only)" on page 251

Note: In Version 8.2, WinMagic introduced into SES a pre-configured XML file called KnownConfigs.xml that contains "ideal" device type-specific settings for specific makes and models of computers, as a means of ensuring that customers always have the most up-to-date configuration settings where such settings are helpful in deploying SecureDoc to devices that have unusual or specific requirements. Such settings are helpful in deploying SecureDoc to devices that have unusual or specific requirements. the application of such an XML file, instances of devices encountering issues during the installation SecureDoc and subsequent initial encryption will be dramatically reduced.

Note: As new device types come into the market, Administrators can simply download the newest version of the override XML file and proceed with SecureDoc installation by including the updated XML file into their existing Installation Packages. The XML file will be automatically copied into each installation package from the "master" copy, which is stored in the same directory in SES (normally C:\Program Files\WinMagic\SDDB- NT\Binary Installation Files\WindowsPC) where the version's installation executables are stored (and from which they are copied into individual installation packages).If for some reason a customer decides not to use this file, it can simply be deleted from the package before deploying the package to endpoints.

To create a profile:

1. Click Profiles in the navigation pane.

2. Right-click on the information pane and choose Add profile. A Selection prompt screen will appear, as in the image below. Across the top can be seen 3 radio buttons which define Device Categories. The category options are: Endpoint (typically a hardware client type, such as a laptop or desktop); VDI, which is for a Virtualized Desktop environment such as XenDeskTop from Citrix, or VMWare Horizon 7; or CloudVM which is for a Public or Private Cloud-hosted Infrastructure-as-a-Service virtual device. Note that when you choose one of these Device Category radio buttons, the list of available Device Profile types will be filtered to show only those Profile Types that can be defined for that Device Category.

3. Select the desired Device Category radio button, then from the drop-down list, select the desired Device Profile type.

4. Click OK and the SecureDoc Profile screen appears.

Depending on which Device Category you chose, the available Device Profile Types available will be one or more of:

1. Click the profile data buttons to define the profile:

   • General (SecureDoc) options — "Profile General Options " on "Profile General Options " on page 131

   • Boot text and color options — "Text, Color and Logo Options for Boot Logon (PBA)" on "Text, Color and Logo Options for Boot Logon (PBA)" on page 224

   • Port control options — see "Port Control Options (SecureDoc Enterprise for Windows clients only) on "Port Control Options (SecureDoc for Enterprise for Windows Only)" on page 251

   • Boot configuration options — see "Boot Configuration Options " on "Boot Configuration Options " on page 231

   • Disk access control — see "Disk Access Control (SecureDoc Enterprise for Windows clients only)" on "Disk Access Control (SecureDoc Enterprise for Windows clients only)" on page 229

2. When you are finished, click Save.

SecureDoc Profile General Options

Profile General Options

Options in the General screen set the general parameters for SecureDoc behaviour on all the client devices that receive the installation package associated with this profile.

To access the tab, open the Profile screen (either as part of creating a profile or by double- clicking an existing profile) and click General options.

Profile Communication Options

Options in the Communication tab specify the communication available from client devices (those that receive the installation package built on this profile, or have this profile applied by the SES Administrator to replace a previously applied/installed profile), click General options, then click Communication.

Note: The use of Bitlocker is covered in Chapters 10, and customers wishing to utilize Bitlocker for disk encryption should see Chapter 10 before continuing with the remainder of the Device Profile settings.

Profile Communication Options

Implementation of HTTPS / TLS 1.3 for Pre-Boot Login (PBL) is introduced within SecureDoc. This fea- ture enables support for alternative Transport Layer Security (TLS) modes in SDConnex and Profile, offering three distinct settings:

1. Compatibility with HTTPS or TLS 1.3 where available.

2. Mandatory use of TLS 1.3.

3. Mandatory use of HTTPS.

Please note, while TLS 1.3 is supported, it does not currently support Pre-Boot Unlock (PBU) as ref- erenced in issue SD-41290. Similarly, HTTPS support, though enabled, does not currently support Pre- Boot Unlock (PBU) as outlined in issue SD-45618.

For environments running SES 9.1 and above, the process involves configuring SDConnex. Access the Communication tab on SDConnex and navigate to the Transport Layer Security (TLS) settings, where you'll select the option "Force use of HTTPS."

Create a package by following these steps: begin by establishing a profile that includes the Password key file and enforces the usage of HTTPS. Within PBConnex, enable the setting for "Force use of HTTPS" under the "TLS Encryption" section.

Regarding PBLU Preboot, it's important to note that HTTPS for PBU is not supported in version 9.1 (ref- erenced by issues SD-41290 and SD-45618). If TLS 1.3 or HTTPS is enabled, a warning message will be displayed.

Develop a profile including Network phone settings and enforce the usage of HTTPS. Within PBConnex, set the "Force use of HTTPS" feature and configure the Network phone settings along with the Identity Provider (IDP) list.

PBLU Preboot currently does not support HTTPS for PBU in version 9.1, a limitation highlighted by issues SD-41290 and SD-45618. However, the out-of-band (OOB) feature for PBU will be implemented and supported in version 9.2.

Utilize the Profile/Package from step 3.1 to deploy the client, resulting in a successful deployment of the package on the client. Subsequently, apply the Profile/Package from step 3.2 for the second client deployment, also achieving a successful client package deployment. Moving forward, within SES, create a PBN group inclusive of PBN Autoboot/User settings.

Add device to group

Install the ME Enterprise application and ensure that the ME status reflects as 'Online – User Registered'.

Access the IdP portal page for login and navigate to the Mobile tab. Follow the instructions provided there to successfully register the user on the phone.

User will be shown on phone as below

Sign in to preboot by using the Out-of-Band (OOB) method. Wait for the PBConnex icon to turn green at preboot and then position the cursor in the Password field to activate the OOB function.

The Authentication prompt is shown on phone

Approve it, authenticate by FaceID/TouchID then Login Preboot successful

Access preboot login by using the PBN Autoboot/User method. Wait for the PBConnex icon to turn green at preboot.

Access SDCC login using the Out-of-Band (OOB) method, which is supported for versions 9.0 SR3 and above. Open SDCC and select the Login button. A blue pop-up will display with the message "Please ensure you have the WinMagic Authenticator app open on your phone to perform network authen- tication."

The Authentication prompt is shown on phone

Approve it, authenticate by FaceID/TouchID then Login SDCC successful

Profile Credential Provider Options

Options in the Credential Provider tab affect the way Boot Logon functions on all Windows clients that install the installation package built on this profile. Operating Systems affected by Credential Provider settings are: Windows 7, Windows 8/8.1, Windows 10 and Windows 11 client devices, as well as Win- dows Server 2008 and later versions.

To access the tab, open the Profile screen (either as part of creating a profile or by double- clicking an existing profile), click General options, then click Credential Provider

Password Provision Options

Introducing UI settings for Password Provision options, this feature enables the provision of the Win- dows password to requesting applications using a hotkey or clipboard functionality. It enables the auto- matic pasting of the Windows password into password fields, facilitating the auto-submission of login forms on third-party applications or websites. Additionally, this feature includes the functionality to enable the automatic alteration (rotation) of the Windows password once it is submitted via the pass- word provisioning hotkey. Following the password provisioning event, SecureDoc initiates an attempt to

change or rotate the Windows password within 15 seconds. Functionality to provision Windows pass- word to requesting applications via a hotkey or clipboard.

Enable Windows password autofill to third-party applications (with a hot-key combination).

Allow for the automatic insertion of the Windows password into password fields and the automatic sub- mission of login forms for third-party applications or websites. The functionality of the settings below is dependent on the activation of this feature.

Enable Windows password rotation upon autofill.

Activate the automatic alteration (rotation) of the Windows password after its submission using the password provisioning hotkey. The subsequent option (AutoRotateWinPwd) will operate when this set- ting is enabled.

Automatically rotate Windows password upon autofill.

When enabled, SecureDoc will attempt to alter or rotate the Windows password within 10 seconds fol- lowing the password provisioning event. If this feature is disabled, users will receive a notification prompting them to rotate the password. Clicking on the notification with the left mouse button will trig- ger the password rotation process, and the outcome (success or failure) will be displayed through another notification. Upon rotation, the new password will be randomly generated, adhering to a

length equal to or greater than the minimum password length specified in the SecureDoc keyfile. The Windows password rotation function aligns with the Password Sync (PwSync) setting of SecureDoc.

PwSync operates fully until the Windows password is randomized during rotation, at which point PwSync is paused, and only the user knows the SecureDoc password. Activating the "Enable Windows password autofill" setting will prompt a reverse synchronization during the subsequent Windows login or unlock, where the Windows password will revert to the SecureDoc password, and the user's ENC file will be updated. A notification will be presented to the user in this scenario.

Note: Windows AD password policy may not permit changing Windows password more often than once per 24 hours. In this case, password change will happen next time possible upon password rotation request or Windows password resyncing back to SD password.

Note: Autofill password will not work at Windows Logon. Instead, SDCP should be used to manage this case. There is no need to change the managed Windows password on LogonUI, SDCP will prompt you to do so if required.

Important items to note about this feature in the first phase.

• SecureDoc Password Provision should ONLY be used for applications that use your current Win- dows password. For applications not using Windows passwords, users will need to know and man- age passwords for third-party apps.

• Specific permissions are needed in Azure AD to rotate passwords.

Presently, this feature exclusively caters to Windows passwords. Upon the rotation or alteration of the password, users will be required to re-authenticate with their federated applications. It's important to note that this functionality is solely compatible with Windows and does not extend support to Mac, Linux, or mobile devices.

In the subsequent phase, our aim is to expand our support to manage other applications and passwords, not limited to Windows passwords, thereby offering a more comprehensive range of support services.

UI Setting in SES Console:

Access the Password Manager Options located within Profile > General > Credential Provider in the nav- igation menu.

Note: If the option “Use SecureDoc Credentials to log into Windows” is disabled, the “Password Man- ager Options” will be grayed out.

UI Setting in SES WEB:

Access the Password Manager Options under Profile > Key File Dual Authentication in the navigation menu.

Note: If the option “Use SecureDoc Credentials to log into Windows” is disabled, the “Password Man- ager Options” will be grayed out.

UI Setting in SD Control Center:

Access the Password Manager Options within the Options menu under Credential Provider.

Note: If the option “Use SecureDoc Credentials to log into Windows” is disabled, the “Password Man- ager Options” will be grayed out.

After enabling Password Manager Options, right-click on SDPin’s icon in the system tray Select Win- dows Password Options

Windows Password Options show with default hotkeys: Meta+Ctrl+Alt+V (Meta is called Windows key with a window icon)

End-user can change the hotkeys to anything else. (e.g., Ctrl+Shift+T…)

How to Windows Provision Options Work

Enable Windows password autofill to third-party applications (with a hot-key combination).

If this option is the sole one enabled, the passwords for both the SecureDoc (SD) keyfile and Windows have been synchronized. When an end-user logs in to a third-party application or a website using the same password as the one for SD/Windows, they simply input the valid username and press the des- ignated combination keys in the password field. This action enables the proper functioning of the auto- fill Windows password.

Example:

1. SD package has been deployed to the client

2. After the primary user has achieved the secure moment, SD keyfile’s password will be synchronized with the Windows password.

3. Try to log in to https://www.office.com or Outlook365 application, fill in the valid Windows user- name (Azure AD account) then press the combination keys in the password field The password will be auto-filled in, and log in to the website successfully.

Enable Windows password autofill to third-party applications (with a hot-key combination) and Win- dows password rotation upon autofill.

Once the Windows password has been automatically filled in, SecureDoc (SD) will generate a noti- fication to inquire whether the user intends to change the password to a random one or not.

Example:

1. SD package has been deployed to the client

2. After the primary user has achieved the secure moment, SD keyfile’s password will be synchronized with the Windows password

3. Try to log in to https://www.office.com or Outlook365 application, fill in the valid Windows user- name (Azure AD account) then press the combination keys in the password field The password will be auto-filled in, and log in to the website successfully.

4. SDPin will prompt a notification

1. Right-click to dismiss the notification or left-click to automatically change Windows password

Note: Windows AD password policy may not permit changing Windows password more often than once per 24 hours. In this case, password change will happen next time possible upon password rotation request or Windows password resyncing back to SD password.

1. After changing Windows password to a random one, right-click on SDPin’s icon in the system tray 

Select Windows Password Options

1.  Click “View Password”

Note: Currently there is no protection against viewing the password. In future versions, a request to view managed Windows passwords will require authentication to SecureDoc keyfile.

Note: The random password will be applied to Windows only. It means:

1. Windows login or access to websites and applications through native Windows Logon will utilize the random password provided.

2. For Preboot, SDCP, SDCC, SES Web, or IDP Portal logins, the system will use the old password.

3. The combination keys will not function during native Windows logon, SDCP, or SDCC access attempts.

Enable Windows password autofill to third-party applications (with a hot-key combination), Win- dows password rotation upon autofill and automatically rotate Windows password upon autofill.

When activated, SecureDoc will attempt to alter or rotate the Windows password within 10 seconds fol- lowing the password provisioning event.

A notification will appear after the password has been changed. Subsequently, this notification will van- ish after 10 seconds.

Profile Media Encryption Options

These options allow you to control how users encrypt their removable media. Unless you have specified a default key, removable media is encrypted with the first key in the key file that was not used to encrypt the full disk (typically, this is a user’s group key), standard encryption and no media-specific password. If you use these options, make sure users know the choices they have available and ensure that the key file deployed by this installation package has the Convert Removable Media privilege.

Note: Removable media does not include floppy disks.

To access the tab, open the Profile screen (either as part of creating a profile or by double- clicking an existing profile), click General options, then click Media Encryption.

To control what users can do with encrypted removable media, set up the disk access settings: see “Disk Access Control (SecureDoc Enterprise for Windows clients only)” on page 229.

Removable Media Encryption has been designed to interact with environments depending on the level of security which is required. It is important to determine the level of security which is needed before customizing the options in SES for the users. Through these customizations users will be able to interact with SecureDoc to create a secured removable media device.

The following is a summary of the different levels of security which can be used for encrypting a removable media device.

Encrypted Full-Media-Encrypted media protected by a password can be accessed from a machine that does not have SecureDoc installed on it. Install Media Viewer (downloadable from WinMagic’s web site, http://www.winmagic.com/resource-centre/software-downloads) on the machine and, when prompted for the removable media password, enter it to gain access to the encrypted media.

Profile SecureDoc File Encryption Options (SecureDoc Enterprise for Windows only)

Note: The File and Folder Encryption (FFE) functionality in the previous versions of SecureDoc has now been renamed as SecureDoc File Encryption (SFE).

The SecureDoc File Encryption configuration through the profile simply determines whether or not the profile allows the possibility for client-side SecureDoc File Encryption. Users must have the Config SFE privilege in order to use SecureDoc File Encryption through the added functionality in the Windows Explorer right-click context menu on an endpoint device. If the user already exists, modify his/her user record record to grant him/her the Config SFE privilege, then remove the user from the device, and add them again to it, to trigger the transmission of a new key file (containing the added Config SFE privilege) for that user to the device. When this option is selected, the device users will be able to view the SecureDoc File Encryption option in SecureDoc icon in the Windows taskbar menu. Using this option, the client device users can create the SecureDoc File Encryption policies locally.

Note: Server side SecureDoc File Encryption is handled through SFE policies. See "Creating and Assigning SFE Policies" on page 314 and “Creating Installation Packages for Windows” on page 81.

SFE Global Application Access Lists

The SFE Global Application Access Lists application enables the SecureDoc client device users to view and control the applications that access the encrypted files in a SecureDoc File Encryption folder. The client device users can allow or deny access to these applications.

The SFE Global Application Access Lists consists of two lists:

• White List: - Applications in this list can decrypt the files within SecureDoc File Encryption folder(s) and display their contents in clear text. White-List applications will be able to open, read, write, move, or delete files, with no restrictions.

• Gray List: - Any unwanted applications (e.g. malware, antivirus, background applications, etc.) can be put into the Gray List in order to keep the sensitive files stored in the SFE folder safe and secure. Similarly, this can be used to ensure that certain document types (e.g. Word, Excel, etc) cannot be decrypted when used as attachments to emails, by gray- listing Outlook.exe or similar email applications. The “Gray List” applications cannot decrypt the files. Thus, the contents cannot be viewed (or saved) by gray-listed applications in clear text.

Many applications (e.g. svchost.exe, SearchProtocolHost.exe) may be trying to access the files in the background. Each time an application accesses a file and if this application is not in both the lists, a pop-up “An application wants to access an encrypted file” appears (only if the Config SFE option in SES Console is enabled) asking you to determine whether that application should be put in the White List or Gray List.

For example, if “Dropbox” application is added to the Gray List, the files are synchronized to the cloud in encrypted form. If these files are accessed using the Dropbox application, then the contents of those files will not be decrypted. Thus, data will always remain encrypted and secure. Similarly, if a Microsoft program (e.g. Word) is added to the White List and when these files are accessed using Microsoft Word application, then the contents of these files will be decrypted. The files can be edited, moved or deleted.

IMPORTANT: All applications or processes not listed under the White or Gray Lists, will automatically be considered a Gray List application, and therefore won’t be able to decrypt SFE files.

Persistent Encryption

This feature helps retain the encrypted files/folders are always encrypted even when they are trans- ferred to other locations and/or media.

Limitations for Persistent Encryption

IMPORTANT: Persistent Encryption should not be applied to the User Profile folder - it can result in data corruption or loss, since many applications and services require access to files in the user profile. If any of these applications are in the Gray List of persistent encryption, the system can become unstable, so WinMagic's recommendation is to NOT use Persistent Encryption on the entire user profile folder.

Users must have administrator privileges to run executable (.exe) files from SFE folders.

• If Explorer.exe and Dllhost.exe is in the Gray List, the Send to Compressed File option will not work for SFE.

• If dllHost.exe is in the Gray List, users will not be able to view image files using Windows Photo Viewer, as Windows Photo Viewer uses dllhost.exe for processing.

• If dllhost.exe is in the Gray List, the "Send to Compressed (zipped) File" option in the Windows Explorer context menu will not work for SecureDoc File Encryption (SFE).

• Google Drive and One Drive root folders (e.g. C:\Users\<user name>\Google Drive; C:\Users\<user name>\One Drive) cannot be encrypted using SecureDoc File Encryption.

• The video, audio, and executable files added to the encrypted Google Drive older cannot be encrypted. Only text-related files are encrypted in this folder.

• On Windows 8, 10 and 11 Operating Systems, if explorer.exe is included in the Gray List, the Windows Metro Apps will not be able to open files in the SecureDoc File Encryption (SFE) folder.

• On Windows 8, 10 and 11 Operating Systems (OS), the pre-existing files on Google Drive will not be encrypted on the cloud after adding the Google Drive Folder to the White List using SecureDoc File Encryption (SFE).

Note: Persistent Encryption has been dropped from the SES product as of version 9.1. Due to issues brought about in Windows 11, stability issues that resulted in the creation of duplicated files, as well as low consumer uptake of this feature, it has been decided that Persistent Encryption will be dropped from the product in version 9.1.

Enabling SecureDoc File Encryption:

Note: Select the Config SFE option from the user Privileges groupbox (Tools -> Key File) to allow the device users to create SFE policies locally.

• 1. Open the Profile screen (either as part of creating a profile or by double-clicking an existing profile).

  2. Click General options.

  3. Select SecureDoc File Encryption.

Select the desired option(s):

• • • Users may encrypt specific Files and Folders: When this option is selected in conjunction with the Config SFE option in the global options, the SecureDoc File Encryption

functionality defined by SecureDoc File Encryption Policies will become access- ible/enabled on any devices that have the combination of a profile with this option enabled, a SFE policy, and the user has been provided with the Key that the SFE policy defines as being used to encrypt the in-policy folder(s). This option was formerly called: Enable SecureDoc File Encryption.

• • • Allow users to decrypt and encrypt files using the Windows context menu: This option allows the client device users to decrypt and/or encrypt files locally. When this option is selected, the Encrypt (or Decrypt) with SFE Utility option will be available in Windows context menu.

Profile Advanced Options

To access the tab, open the Profile screen (either as part of creating a profile or by double- clicking an existing profile), click General options, then Advanced Options.

These options control other, more advanced, aspects of SecureDoc operations.

Note: All the new users will be protected with a random password. The Protect new users with Generic password is no longer available from SES v7.1 onwards. If the generic password option is enabled in the older installations (e.g. version 6.5 or lower), then it will be upgraded to random password option when the SecureDoc server is upgraded to version 7.1.

Hardware reset OPAL Self-Encrypting Drives following warm reboot.

Due to the nature of OPAL SED management, such disk drives will remain in an unlocked state if their host devices is warm-rebooted.

Although this can be a useful feature for non-encrypted disks, it also constitutes a security vulnerability since devices could be subjected to a "Forced Restart Attack" (see article: "4 SED Attacks and How to Mitigate Them" at https://www.winmagic.com/blog/4-sed-attacks-and-how-to-mitigate-them/).

To combat this vulnerability, it is possible to leverage the Hardware Reset drive firmware feature which will, when enabled, force the OPAL SED to lock upon Warm Reboot of the device.

WinMagic has incorporated functionality into the Device Profile to support such a Hardware Reset, which will force devices to go through full Pre-Boot Authentication upon warm reboot.

This feature is not enabled by default. A new flag in SDProfile.spf informs the SecureDoc client during deployment as to whether or not it should attempt to enable the Hardware Reset feature on a sup- ported OPAL SED.

To enable this functionality, manually add the following section and settings clause to the Profile's .SPF file.

[SED]

SEDHardResetEnable=1

Note: If a user doesn't yet have a key file on a computer and the expectation is that PBConnex-brokered access to the device should trigger the transmission of a new Key File for that user onto the device, then either: A) The PBConnex group that governs PBConnex-brokered access to the device must have the option entitled "Save key file locally" enabled, or… B) The “Create Boot key file for Windows User(s)” feature in the Device Profile’s Advanced Options panel must be enabled.

Hardware Authentication

The Hardware Authentication panel is new in version 9.1, as in the images below:

TPM protection for Key Files (for devices with TPM available). This option consists of a drop-list that defines whether or not the device TPM will be used to further protect Key Files stored on the device. It contains the following options:

One Time Password

Developing the OTP feature, aiming to facilitate users' access to Windows by implementing a One-Time Password (OTP) generated on their mobile devices. The goal is to assist users in authenticating to a SecureDoc-protected Endpoint by offering a recovery and login method through an OTP received on their phones.

Examples supporting this need include scenarios where Bluetooth Low Energy communication is dis- abled, the user is offline, or the Mobile Device's TPM is unavailable. The proposed solution entails allow- ing users to log into Windows using an OTP from their mobile device, entered at Pre-Boot, thereby enabling the SecureDoc-protected endpoint to boot into Windows.

This feature ensures the use of OTP for logins in Preboot, SDCP, SDCC, and Remote Desktop, while also providing the capability to bypass MFA checks for Windows login using OTP.

1. Setup OTP phone:

   1. Create a profile with options

MagicEnpoint Enterprise - Identity Provider list, for instance: https://doremi.asia:7100

Under "Hardware authentication," activate the setting to prompt users to enroll OTP protection on their mobile phones. This action necessitates enabling MagicEndpoint in the Communication options.

• 1.  Deploy the package to the client

  2. After the primary user has been achieved

  3. SD prompts a warning to setup OTP

  4.  Click OK

  5. SD prompts a dialog “Enroll Phone One-Time Password (OTP) Recovery”

• 1. Use the phone (Android/iPhone) and launch WMAuthenticator app

  2. Navigate to Menu/Accounts/[+] then Scan the QR code Now OTP setup has been updated successfully.

  3.  Click on the user then The One-Time Password is shown as asterisks.

  4.  Close the dialog “Enroll Phone One-Time Password (OTP) Recovery”

1. Login Preboot with OTP phone

   1. At preboot, enter the UserID

   2.   Click “F6" then “Login Options” shows

   3. Select “Login Options”

   4.   Select “Phone OTP” then The “Password” field changes to “Phone OTP Blue Code”

   5. Launch WMAuthenticator on phone then Menu then Account then Select the account name

• 1. Tap on the “Blue Code” and verify on phone then The One-Time Password is shown.

SES Administrator Manual

v9.2 SR1

• 1.  Enter the One-Time password to SD

  2.  Click “Login” then Login preboot with OTP successfully and load Windows automatically without entering Windows’s password.

  3. In Windows, SD requires to change the SD’s password.

• 1. Click OK

• 1. Enter and confirm the new password and click “OK” then SD’s password has changed successfully and synchronized to Windows’s password.

1. Login SDCP with OTP phone

Precondition:

- Enabled option: “Use SecureDoc Credentials to log into Windows”

• 1. At SDCP screen

  2.  Click on “Login with SecureDoc Password/PIN” to change to “Login with Phone OTP”

  3.  Launch WMAuthenticator on phone to get the One-Time password.

  4. Enter the One-Time Password in SDCP

  5.  Click the arrow button to log in Login SDCP successfully with OTP

  6. In Windows, SD will require to change SD’s password.

1. Login SDCC with OTP phone

   1. Launch SDCC

   2.  Click on “Login with SecureDoc Password/PIN”

• 1. Select “Login with Phone OTP”

  2. Launch WMAuthenticator on phone to get the One-Time

  3. Enter the One-Time password to SDCC

  4.  Click “Login” then Login SDCC successfully and SD will require to change SD’s password.

1. Login SDCP with OTP phone and bypass Multi-factor Authentication

Precondition:

• Enabled option: “Use SecureDoc Credentials to log into Windows”

• Enabled option: “Enforce Multi-factor Authentication for SecureDoc Windows Logon

  1.  At SDCP screen

  2.  Enter the SD’s password and login.

  3. Multi-factor Authentication is required.

  4.  Launch WMAuthenticator on phone to get the One-Time

  5. Enter the One-Time password to the blank box at “Alternatively you can login with OTP Password form your Phone to bypass Two-Factor Authentication of SecureDoc

  6.  Click “Login with OTP” Login SDCP successfully without MFA.

  7. In Windows, SD will require to change SD’s password.

1. Login Remote Desktop (RDP) with OTP phone

Precondition:

• Enabled option: “Add SecureDoc login enhancement to remote desktop client”

• Primary laptop with SD installed

• Loaner laptop with/without SD installed

  1.  On Primary user, run “Remote Desktop Connection”

  2.  Enter IP address of loaner laptop

• 1. Click “Connect” button

  2. Click On “Login with SecureDoc Password/PIN”

  3.  Select “Login with Phone OTP”

• 1. Launch WMAuthenticator on phone to get the One-Time

  2. Enter the One-Time password to the “One-Time password” field

• 1. Click “Login” then RDP to the loaner laptop successfully.

Profile Trusted Devices (SecureDoc for Enterprise Only)

Use this feature to specify which USB-connected SEDs are to be considered trusted, that is, allowed to be used as is on the client device and whose innate encryption functionality is considered to be strong enough.

Devices not on this list will be encrypted automatically (if so configured in the Media Encryption set- tings) or will prompt the user to encrypt them (if so configured in the Media Encryption settings).

To access the tab, open the Profile screen (either as part of creating a profile or by double- clicking an existing profile), click General options, then Trusted Devices.

WinMagic provides a list of common trusted SEDs: to load the list, click Load Default List. If necessary, you can remove a selected SED from the list or click Add to add a new one. You are prompted to either enter the device details or trust a device model. If you select Enter device details to trust, when you click Next you are prompted to enter identifying information (VID, PID, etc.) about the device.

If you select Trust a device model, when you click Next you see a list of the device models currently attached to the machine on which the SES console is operating. Select a model and click Add Selected Device Model.

For devices that are attached to the Trusted Devices list, the Disk Access Control (DAC) restrictions will not be applied.

Text, Color and Logo Options for Boot Logon (PBA)

Boot text and color options control the way Boot Logon appears on all client devices that install the installation package using this profile. These options enable you to customize Boot Logon to reflect information relevant to your enterprise.

To access the options, open the Profile screen (either as part of creating a profile as explained on "About Device Profiles" on page 128 or by double-clicking an existing profile), and click Boot text and color.

You can set the appearance of the header, the prompt text, the logo, and the colors of the Boot Logon screen. You can enter text that will appear as prompts or, for visually impaired users, you can enter special text that will invoke sounds that act as prompts.

Note: If visually impaired users enter incorrect information, no sound is emitted.

If you plan to use a customized background, the graphic file needs to meet these requirements:

• 24 bit .bmp format

• 1024 x 768 pixels

• when zipped (SecureDoc zips the file for you), no larger than 0.5MB (you will be warned if your file exceeds this size)

Only computers with a high resolution monitor (the most common type) will display the customized logo — other monitors will show the default Boot Logon display. Customized logos will also not appear on devices using Permanent AutoBoot, which do not show the Boot Logon screen.

Note: Although the Device Profile settings can specify a Customized Background image to be used, once defined in the Device Profile such customized background images can only be applied to new SecureDoc installations. It is not possible to define a customized background in a Device Profile, then deploy that new customized background to an existing SecureDoc-protected device by changing the Device Profile through use of the remote command functionality (e.g. Apply Device Profile). Other aspects of the new Device Profile (e.g. feature settings) will be applied, but

Note: a) must be applied on the device itself through the SecureDoc Control Center by a user having Administrative rights, or b) using the bkimport.exe tool that became available in SES V8.2, which is installed on the client device as a standard element of the V8.2 installer. For more information on bkimport.exe, please consult section C 23, in the subsection entitled: Using bkimport.exe to alter the Pre-Boot Background image

• 1.  Change the settings as desired by clicking the button corresponding to the prompt area you want to customize. A new screen appears, allowing you to enter new text for that area.

Note: Lock Prompt text (which appears when three unsuccessful attempts to login to the encrypted device have been made) cannot exceed 16 lines of text, with a maximum of 81 characters (including spaces) per line.

For visually impaired users, enter the words “</beep1, beep2/>”, etc. as prompt texts: each trailing number (1, 2, 3, etc.) indicates a relative pitch/frequency setting, with 2 being higher than 1, 3 being higher than 2, and so on. Add as many beeps as you want. For instance, to have different sounds for the key file and the password prompt, you could enter:

• • • “</beep1, beep2/>” at the Key File prompt, or

    • “</beep1, beep2, beep3, beep4/>” at the Password prompt.

Note: Use of beep codes for visually impaired users does not work for devices that boot into UEFI, so the above settings will not have any effect on devices that utilize SecureDoc's Pre-Boot for Native UEFI Devices (PBU).

• 1. When the new prompt text is complete, click OK. You are returned to the previous screen.

Note: The total prompts (header, password, and key file) should be no more than 23 lines of text, with 81 characters (including spaces) per line.

• 1. To change the color of the prompt text, click Text Color. For standalone SecureDoc users, this option is available only if Boot Logon is installed and you have a high resolution monitor. If using

the standard Boot Logon screen, which has a white background, you cannot choose the white or grey text color.

• 1. Optionally, click Import Customized Background and browse to the location of a graphic file to use as the background for the Boot Logon screen. (See file requirements on the previous page.) Check Update boot-screen background image when updating Boot Logon: the new background will appear at the next Boot Logon.

As you change text and color options, the screen previews how Boot Logon will appear to the user.

1. "Background Theme:"

   • Its options are "Modern" or "Classic"

   • The option chosen determines whether the new Modern pre-boot Background is dis- played, or the Classic. Modern offers some beneficial additional functionality, such as automatic typeface re-scaling, to permit use of longer strings without run-on or having strings overlay other screen objects.

Note: Imported customized backgrounds will not be previewed. A message appears beside the OK button to indicate that one has been imported.

Disk Access Control (SecureDoc Enterprise for Windows clients only)

Disk Access Control (SecureDoc Enterprise for Windows clients only)

Disk Access Control options let users lock or monitor functions performed on the different disks (both encrypted and not encrypted) on their computer. It is typically used to prevent sensitive data from being copied onto unencrypted removable media. Setting up these options in your installation package determines the default behaviour for those users. For example, you might want to ensure that, by default, users cannot write to unencrypted removable media.

Each profile contains a default access control profile. You can also set up temporary disk access control profiles, if necessary. Once those expire, the default access control profile will be used.

You can set up disk access control profiles that determine access to each possible drive and for any removable media drive. Disk access control affects drives, not media. For example, a zip drive can be under disk access control, and that control applies to any zip disk put in that drive. However, each separate flash drive inserted into a USB port is treated separately as a virtual drive.

Note: The new removable media settings apply any time the media (for example, the zip disk) is inserted into the drive, even if that media has been inserted before.

Disk access control can be used, for example, to:

• block all write access to a USB drive, thereby preventing data from leaving the device or preventing data being written to it while on the Internet

• block read/write access to a USB drive, thereby preventing others from loading software onto the machine.

This function protects against accidents rather than malicious attacks. If a disk is not encrypted, restricting access to it is not enough — a user could still boot from a DOS diskette and bypass the restriction altogether.

Disk Access Control (SecureDoc Enterprise for Windows clients only)

To access these options, open the Profile screen (either as part of creating a profile as

explained on "About Device Profiles" on page 128 or by double-clicking an existing profile), and click Disk Access Control. The Disk Access Control screen appears:

To create a temporary disk access profile:

1. Click Add and enter a profile name in the Access Control Profiles area.

2. Select the new profile in the Access Control Profiles area and from the Use temporary Profile drop-down list below it.

3. Set the Duration in Mins. and the Start Time for the temporary profile.

4. Select the desired options for the Removable Media / WPD devices. For more information on these options, see the table below :

Note: The Windows Portable Devices feature only supports devices that are connected through USB; it does not support other connections, i.e. Bluetooth or other wireless connections to Windows Portable Devices. It supports the Media Transfer Protocol (MTP) mode only, thus devices that are not using this mode should be considered standard storage, and the Removable Media option within the Disk Access Control settings should be used for this case.

Note: By default, No Restrictions is enabled and it means that there are NO POLICIES on the devices. The users can perform all tasks as usual.

Note: It is recommended that you do not use the "no access'" option for USB keys, since Windows will assume these are unformatted and prompt for formatting, repeatedly.

1. Click OK.

Boot Configuration Options

Boot Configuration options control the different customizable options for Boot Logon on the client devices that install the installation package built on this profile.

The options are organized into four categories:

• General options (see “Boot Configuration General Options” on page 232)

• Keyboard layout options (see “Displaying optional numeric-only Challenge Text in Challenge Response” on page 242)

• Advanced options (use only in consultation with WinMagic technical support)

• Wireless settings (see "Depending on which Device Category you chose, the available Device Profile Types available will be one Installation Packages for Windows" on page 126

Boot Configuration General Options

NOTE: If you configure a device to utilize the PBLU Pre-Boot, AND that device encounters Pre-Boot errors under PBLU, after a defined maximum number of failed Pre-Boot errors it will "fail over" to PBU (which is more tolerant of variable hardware).

In SES V8.5, a new option has been added to the Profile .spf file which permits defining a specified num- ber of failed Pre-Boot Linux for UEFI (PBLU) boot attempts before SecureDoc Pre-Boot automatically switches from PBLU to Pre-Boot for Native UEFI (PBU) boot processing.

Customers had encountered issues booting into PBLU (e.g. where they either did not have an attached monitor connected to an enabled port, or their devices have had certain ports disabled to work around a known issue with Intel GFX combined with Sleep mode, which can cause Blue Screen halts when using PBLU using all display ports).

This new option permits the SES Admin to manually define (in the Profile's .spf file) a more lenient num- ber of Pre-Boot attempts under PBLU, thereby permitting technicians more time to resolve any issues before the device would switch permanently to PBU mode (after which it would require the additional steps of having a user with Admin rights logging in to SDCC to switch it back and then updates boot logon to reinstate PBLU-based Pre-Boot).

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

Section name: "SDSpace"

Key name: "PbluFailureCounterMaxValue" Valid key values: 0...255

Key value meanings:

• 0 - PBLU Failure counter is disabled (never switch to PBU)

• 1...255 This new PBLU Failure counter may take a value between 1 and 255.

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

Smartcard + password authentication; User ID is derived from Smart Card used in Windows

Note: This section applies only to SecureDoc Enterprise for Windows client device profiles.

This option comes very handy in a scenario where users perform pre-boot login using their smartcards, especially the smartcards that have very long User ID. It is difficult for users to remember and key in these long User IDs at pre-boot logon screen.

Using the Smartcard + password authentication; User ID is derived from Smartcard use in Windows option in SES Console allows the users to log in at pre-boot just by entering their password (no need to enter their User ID / User Name anymore).

Enabling the Smartcard option in SES Console:

Note: This feature works with .net Gemalto V+ smart cards only.

Before enabling this feature, you must configure the environment required to use this feature by per- forming the following steps:

Note: Make sure Gemalto smartcard certificates are valid and contain the Principal Name in the Subject Alternative Name field.

1. Create a token-protected keyfile by loading the Gemalto smart card certificate into the user account that you desire to use for testing purposes.

2.  From the Boot Configuration window, select the SmartCard + password authentication; User ID is derived from SmartCard use in Windows option. This option allows the smart card users to login at pre-boot using their passphrase only (without entering their user ID / user name).

Note: When this option is selected, the Enable enhanced smartcard authentication option in SecureDoc Control Center (SDCC) is automatically enabled. Alternatively, if this option is not enabled in SES console, users may manually enable this feature in SD Control Center.

Note: For UEFI devices, select the PBLU: Linux Pre-boot for UEFI devices option from the UEFI Boot Loader group-box.

1. Click OK.

Once the package is deployed onto a client device, the pre-boot logon screen will not show up the user ID field.

Displaying optional numeric-only Challenge Text in Challenge Response

Although Challenge-response device access recovery applies to most device types plus RMCE-encrypted media, a new option has been added that permits displaying a second numeric-only Challenge String. This has been included to permit optional integration with a customer's own Interactive Voice Response (IVR) systems, so that users may enter a Chal- lenge string into their IVR system using only the numerals on a telephone keypad.

To enable this functionality, customers must manually enter a new value into the SecureDoc Device Profile, entitled "ShowNumericChallenge", so an example of this new setting would be:

ShowNumericChallenge=1

When this value is set to 1, SecureDoc's boot logon should display both the usual hexa- decimal "Challenge Number", followed on the line below by a numeric-only Challenge Num- ber.

Boot Configuration Keyboard Layout Options

Boot Configuration Advanced Options

In Advanced Boot Settings, the options listed are as follows:

Note: Note: It is strongly recommended to contact WinMagic Technical Support before altering these values

Note: Advances in BIOS and EHCI controllers have made this setting unnecessary, and it will be removed in a future version of SecureDoc Enterprise Server and the SecureDoc Client.

In PB Connex, the options listed are as follows:

Boot Configuration Network Access Control

Additional considerations for users requiring 802.1X-protected wired network communication

Customers using 802.1X-protected wired network environments, and which utilize SecureDoc's native UEFI (PBU) at Pre-Boot will experience issues with their SecureDoc Clients spending excessive time at pre-boot, which may become unacceptable if there are multiple SDConnex Servers.

The reason for the delay is that these devices using SecureDoc's native UEFI (PBU) at Pre-Boot will attempt to connect to each of their SDConnex Servers and then need to wait for these SDConnex server connections to time-out since Certificate-protected 802.1X communication is not possible within the context of UEFI. The greater the number of SDConnex servers, the greater the delay before control would be returned to the user.

This issue does not occur if devices are configured to use either Pre-Boot Linux (PBL) or the Linux-based Pre-Boot for UEFI (PBLU), which do support 802.1X-protected networks.

Port Control Options (SecureDoc for Enterprise for Windows Only)

The solution for this (if it applies to your organization) is implemented in this version which permits

PBU to act like SecureDoc's V4 pre-boot in legacy mode, permitting deployment of a single profile, which retains PBLU networking, but disables PBU networking, thus ensuring there is no lengthy pause while PBU tries each of a lengthy list of SDConnex servers.

This solution is implemented by adding a new optional setting into the SecureDoc Profile:

To make this change: Add new option "PbuIgnoreNetworkStack" manually to the SecureDoc profile. When set to a non-zero value, PBU-configured devices will ignore the UEFI Network Stack.

For customers that require this functionality, this non-zero option must be added to the [SDSpace] sec- tion of SD profile as follows:

---------- beginning of SDProfile.spf file ----------

... <other settings > [SDSpace]

... <other settings > PbuIgnoreNetworkStack=1

... <other settings >

---------- end of SDProfile.spf file ----------

Once the above clause has been added to the SDSpace section of SDProfile.spf, close and save the updated SDProfile.spf file and use it inside the Installation Package to deploy SecureDoc to endpoint devices.

Port Control Options (SecureDoc for Enterprise for Windows Only)

Basic user interface devices such as keyboards and mice are white listed by default, as are hardware-based encrypted USB devices.

1. Click the Port Control profile option. The Port Control screen appears.

Note: USB storage devices attached to ports are locked by default: to allow them to be accessed, use Port Control to authorize access by specific devices.

1. Check Install port control.

Port Control Options (SecureDoc for Enterprise for Windows Only)

1. To block unauthorized USB devices, check the Block unauthorized USB devices option

and click Authorized Devices. (You are warned of additional steps needed for token-based key files.) Follow the steps below.

1. A list of currently authorized devices appears.

1. To authorize more device types, click Add. A panel will appear, as in the image below, which will prompt you to choose an authorization method based on device class, device model, or distinct device. If you authorize devices by model, the device’s vendor ID and product ID are the factors used to determine if a device make/model is authorized. Note that more than one device could match these conditions, for example if one has multiple USB sticks of the same make and model. If you choose the “distinct device” option, the device’s vendor ID, product ID, and serial number are used to determine if a device is authorized. Only one device (e.g. a single USB memory stick) could match these criteria.

1. If authorizing a new USB device, insert it into the computer.

2. Choose the authorization method and click Next. A list of the USB devices previously inserted and currently inserted in the computer appears.

To limit the display to only those devices currently connected, clear the Show previously connected devices option.

1. Select a device and click Finish. The device is added to the list of authorized devices.

2. Continue to add as many devices as you wish.

Configuring Installation Package Settings

Overview

Installation package options specify:

• the general behavior of the installation on the client device (see "General Settings for Installation Packages" on page 255)

• the privileges to be stored in the key file created for the client device as part of the automatic process (see "Key File Settings for Installation Packages" on page 260)

• authentication questions to be asked of users receiving this installation package (see "Authentication Question Settings for Installation Package" on page 261)

• administrative settings for this installation package (see "Users Settings for Installation Package" on page 262)

Once you have created an installation package (which is essentially as a set of parameters in the SES database), you use it to create the actual installation package files that are distributed to client devices.

Installation packages must be associated with a specific profile. The same profile can be associated with any number of installation packages.

1. Click Installation packages in the navigation pane.

2. Right-click on the information pane, and choose Add Package. A Selection prompt screen will appear, as in the image below. Across the top can be seen 3 radio buttons which define Device Categories. The category options are: Endpoint (typically a hardware client type, such as a laptop or desktop); VDI, which is for a Virtualized Desktop environment such as XenDeskTop from Citrix, or VMWare Horizon 7; or CloudVM which is for a Public or Private Cloud-hosted Infrastructure-as-a-Service virtual device. Note that when you choose one of these Device

Category radio buttons, the list of available Installation Package types will be filtered to show only those Package Types that can be defined for that Device Category.

1. Click the Endpoint radio button, then select the desired Installation Package type, and the SecureDoc Installation Package screen appears.

2. Set the options (as described in following sections) and click OK.

General Settings for Installation Packages

Key File Settings for Installation Packages

Authentication Question Settings for Installation Package

Choose which of the authentication questions created through SES global options (see “Key File Options” on page 80) you want used for this installation package. This is required for self-help password recovery to work.

To add a question from the list established in SES global options, click Add and choose from the available questions. To remove one from the installation package, select it and click Remove.

Note: The number of questions (n) a user must answer is defined in the Global settings (Tools | Options, General Panel, click on the Password rules button). The Administrator may opt to include up to seven questions to the Installation Package, even if the Password Recovery settings define that the user must answer fewer than seven questions.Doing this provides users with a degree of choice as to which (n) of the up to seven the user will answer, so they may choose those questions whose answers they're most likely to remember over the long term.

Note: Questions can be any number of characters long, though for the sake of clarity and readability, and so that they are not truncated or wrap to a new line, WinMagic recommends the questions be kept reasonably short (e.g. <= 70 characters).

Users Settings for Installation Package

Use this screen to add a user (administrative or other) to the package and, therefore, to add that user’s keys to the key file for the package. This gives such users access to the encrypted device. Administrative users must have admin rights and, if protection is token-based, a loaded certificate.

Note: Users defined here will be added to the client device before encryption begins.

Click Add and choose the admin user to add (these are organized by folder). This function results in a second key file being created on the client device, protected by the admin user’s certificate or user’s password.

Note: Password-based key files for these users will be created only if the client device can connect to SDConnex.

Setting up Device Provisioning Rules

Background

SecureDoc Key File deployment has been re-designed to make SecureDoc Full Disk Encryption process less disruptive, yet seamless and more robust by eliminating certain complexities and challenges that were associated with the key file deployment in the previous versions of SecureDoc.

Sources of complexity, such as:

• expiry of initial passwords that could lock out a device,

• unknown password changes or users forgetting their passwords, these frustrating issues have been either eliminated or substantially mitigated. Key Features

The following will explain the key points surrounding new Key File deployment functionality:

Provisioning State

This is useful in a scenario where the intended owner of a device is not known at the point when SecureDoc is being installed or the SES administrators do not know who runs SecureDoc installation on a device.

When the Provisioning State option is used, devices will be encrypted but SES will send down the key files to the devices only when the owner(s) of the devices are identified. Until that time, the device continues to be in a provisioning state. Device provisioning can be set up with or without pre-boot

logon, i.e. silent deployment or pre-boot logon using the temporary user credentials provided by the SES administrators.

• Auto-boot: This is similar to silent deployment where users do not perform pre-boot authentication.

  • In this scenario, there will be automated authentication to the device (through auto- boot) which permits the user to authenticate to the device at Windows as usual

  • This option will prove to be valuable where devices may be installed and made ready, but then may sit in storage or be shipped to the user(s) that will ultimately be the “own- ers” of the devices

  • It also eliminates the need to provide users with temporary credentials to log in to the

device (often referred to as an “Initial password”.

• Device access requires Pre-Boot Authentication to a Temporary user account: To use this mode, the SES administrators will previously have created a temporary user account (Creation of temporary user accounts is covered later in this document).

  • This option is valuable in the scenario where yet again the intended or the ultimate user of the device may not be known at the time the device is going to be installed with SecureDoc, but it is desirable to ensure that only someone that knows the temporary user credentials can access the device at pre-boot.

  • The device users can gain access to devices so installed by using the temporary login

credentials provided by the SES administrators. For information on how to create tem- porary user accounts, see the Add Temporary User Accounts in SES Console section in this document.

Note: As soon as the owner of a device has been identified, the key files of the owner will be made available on that device and the temporary user’s key files will be removed. Thereafter the temporary user account can no longer be used to log into that device.

Non-Provisioning State (Device Provisioning is not configured)

In this state, devices will be encrypted as soon as the owner of the device is identified and his/her key files are sent down to the device immediately.

Note: When using the Non-Provisioning state, if the user decides not to assume ownership of a device (by cancelling the dialog panel that prompts the user to confirm the device ownership), then the deployment of the device will not proceed.

Note: If it is intended to user Tokens or Smart Cards to protect authentication to devices, this option must be used, since it moves very quickly to ensure that the user will convert from a Password-protected key file to Token-protected key file.

Visual Status Indicators for Deployed State and Device Owner

Along with the improvements relating to provisioning devices and defining access during the installation and provisioning stages, the SecureDoc administrators can now view a device’s current deployed state (i.e. Deployed; Temp user; Temp autoboot; Unknown; and No Provisioning) as well as the identification of the owner statuses (i.e. a given user will have Yes/No defining whether that user is the owner of a given device, or not) in the SES Console under the Devices tab.

The Provisioning Rules tab allows the SES administrators to define the provisioning rules for devices. The devices can be in either provisioning or non-provisioning states, as defined below:

Lastly, the Provisioning Rules tab allows SES Administrators to define whether the Deploying User is to be the last user that logged into the device or a specific (defined) user account.

NOTE: If the option is taken to use a specific account as the Deploying user, then the checkbox at the top of the panel "Do not create and send down deploying user Key File" must not be checked/enabled.

Configuring Device Provisioning Rules Setting up environment

Select key file option(s) for Windows Accounts in SES Console

Select the desired options for key files for Windows accounts. For more details, refer to the Profile Advanced Option section in this manual.

Add users to the Exclusion List

Note: Ignore this if you have already added users in the exclusion list while creating Profiles.

Certain categories of users are unlikely to become the “owning” users of devices. Commonly, this will include the IT technicians or Desktop administrators that prepare or “stage” devices for other users. SecureDoc permits barring such technicians/admins from being considered as possible device “owners” by adding them to an Exclusion list defined in the Device Profile.

If wishing to exclude one or more specific users from being the owner of a device, define a list of such excluded users in the exclusion list of users (Profiles Advanced Options, option name “Exclude the fol- lowing accounts(s), shown in image below, near the bottom of the panel. To exclude multiple users, use a comma-delimited list (e.g. JohnD, FrankF).

Note: The user accounts included in this exclusion list can NEVER be the owners of the device. The exclusion list can be modified. However, if the SecureDoc deploying user is

Add Temporary User Accounts in SES Console

included in the exclusion list, and if the SES administrators do not want to send down the deploying users’ key files to the client device, then select the Don’t send down deploying user key file option in the Provisioning Rules settings panel.

If wishing to set up a provisioning state where users can gain access to devices by logging into them using temporary login credentials, a pre-requisite is to have previously defined one or more temporary user accounts in SES Console. The “temporariness” trait is a new element in the User Record within SES, and can only be applied to NEW user accounts (so, for example, an AD-imported user account or any other pre-existing user account cannot be subsequently turned into a Temporary account).

The temporary users have the least privileges. They are primarily only used for logging in at pre-boot. They can log in to SecureDoc Control Center (SDCC) as well , but they cannot perform any operations. The password of a temporary user cannot be changed on the client. However, the password can be changed from SES console.

Note: For the client devices that are enabled with Fast Startup, the Temp User is shown in the System Slot 0; however, please be advised that the key file of this Temp User is removed from device(s).

Note: Only password-based temp user accounts can be created, not the token-based temp user accounts.

1. Log into SES console.

2. In the Users tab, right-click anywhere and select the Add User option.

3. Select the Temporary option from the Type drop-down menu.

4. Enter the password and the other details of this user.

5. Click Create.

Key File Deployment Options and Use Case Scenarios

Note: When the SES administrators make changes to the global password rules, then the existing package(s) password rules will not change. However, when a key file is created and sent down from SES during online installations, the changed global password rules will be applied, not the old password rules of the existing package(s).In case of offline installations, the old installation package rules will apply.

The following table explains the various options and use case scenarios for the key file deployment:

Configuring & Deploying Installation Package with Provisioning State

Option 1: Auto-boot and automatically identify the device owner without any prompt

Note: This option is similar to NOT selecting the "Hide Pre-boot Until User's Credentials are synchronized" option and the user must log into the Boot Logon with initial password during encryption. (That option had been available in earlier versions of SES, up to and including version 6.5). In this scenario, the device owner is identified automatically as the first User to log in at the Windows login screen.

The first logged in Windows user (except those users listed in the excluded Windows users list) will auto- matically be considered the owner of the device. In the event an excluded user should be first to log in, then until such a time as a non-excluded user logs in to Windows, the device will continue to auto-boot into Windows logon and remain in the provisioning state.

Note: If any Windows user (e. g. Technician) has been added to the exclusion list (Profiles -> Advanced Options) then this user will NEVER become the owner of that device. The device will remain in the provisioned stage until its proper owner has been identified.

1.  Log into SES console.

2. Set up the desired global options (Tools – Options)

3. In the Profiles window, click the General tab.

4. Select the Synchronize SecureDoc with Windows password (bi-directional) option to have the user’s Windows password used, automatically, as the SecureDoc key file password. Changes to the Windows password automatically apply to SecureDoc and changes to the SecureDoc password apply to Windows.

Note: The user’s Windows password must not be blank.

1. Select the Synchronize with matching Windows Accounts only to have password synchronization apply only if the name of the Windows account is the same as the SecureDoc account name. (Optional)

2. Click OK.

3. In the Installation Package settings window, select the Provisioning Rules tab.

4. Select the Enable a provisioning state to allow access to device until its owner has been identified option.

5. Select the Device(s) will auto-boot to Windows logon option.

6. If you do NOT want to send the key file for the deploying user, select the Do not create and send down deploying user keyfile option. If the "Automatically identify owner without having to prompt user" option is enabled, a sub-option becomes available, entitled: "Allow offline identification". If this sub-option is enabled, it permits the SecureDoc Client to complete the recognition of the logged-in user as the Owner of the device, and will create a local key file for that owning user, even though the device might not be capable of communicating with the SES Server at that moment (e.g. device is offline).

7. In the Owner Identification Rules group box, select the Automatically identify owner without having to prompt user option.

8. In the Device location group box, choose the location where the device should be stored in SES during and after SecureDoc deployment.

   • Owner Folder: Choose this option if you desire to store the device in the same folder as the user account who performs the secure moment during the deployment. This is a default option.

   • Registration Folder: Choose this option if you desire to keep the device in the folder the computer was originally created under during the initial registration process.

   • Specified Folder: Choose this option to select the exact folder the device will be saved during the registration.

9. Click OK.

Note: If the Synchronize SecureDoc with Windows password (bi- directional) option is not selected in the Device Profile associated with this Installation Package, a message will appear that states: “Provisioning can be used only if Synchronize SecureDoc with Windows password profile option is turned on. Do you want to turn this option on?”. If such a message appears, Click Yes on it, which will cause the Windows password sync and the Password- sync only when Windows Account matches SecureDoc Account options to be enabled automatically within the device profile associated with this Installation Package.

Deploying Packages

1. Create Installation Package files.

2. Deploy the package to the client devices.

3. After the SecureDoc installation, the Windows login screen appears.

4. Enter the password and the device will log into Windows. The SecureDoc will be deployed on this device and the deployed state is shown as “Deployed” in the SES Console under the Devices tab.

Note: Until a non-excluded user logs in to Windows, the device will continue to auto- boot into Windows logon and will remain in the provisioning state. In such a scenario, the deployed state will be shown as “Temp Autoboot” in the SES Console under the Devices tab.

Option 2: Auto-boot and manually identify the device owner with a prompt

Note: This option is similar to using the "Hide Pre-boot Until User's Credentials are synchronized" (Silent Deployment) option that was available in the earlier version of SES (version 6.5 or lower). In this scenario, the device owner is identified manually.

The SecureDoc agent will display a message (after auto-booting into Windows logon) prompting the logged-in Windows user to enter his/her login credentials if he/she is the owner of that device.

Once the user confirms the ownership of the device, then that user will be considered as the owner of the device.

Until ownership has been confirmed, the device will continue to auto-boot into Windows logon, and will keep displaying the ownership confirmation screen, remaining in the provisioning stage.

1.  Perform the steps 1 through 10 described in the Option 1.

2. In the Owner Identification Rules group box, select the Users will be prompted to confirm device ownership; First to confirm will be device owner option.

3. Perform the step 13 described in the Option 1.

4. Click OK.

Note: If the Synchronize SecureDoc with Windows password (bi-directional) option is not selected, a message “Provisioning can be used only if Synchronize SecureDoc with Windows password profile option is turned on. Do you want to turn this option on” is displayed. Click Yes. The Windows password sync and the Synchronize with matching Windows accounts only options will be turned on.

Deploying Packages

1. Create Installation Package files.

2. Deploy the package to the client devices.When the SecureDoc installation is complete, the computer reboots and the Windows login screen appears.

3. Enter the password and the device will log into Windows and a confirmation prompt appears, as in the image below:

1. Enter the Windows login credentials, if the user is the owner of the device.

2. Click OK.

Note: If the user is NOT the owner of the device, click the Later button. In this scenario, the device will keep displaying the ownership confirmation screen, remaining in the provisioning stage. In such a scenario, the deployed status will be shown as “Temp Autoboot” in the SES Console under the Devices tab.

1. After the completion of encryption, the boot logon screen appears.

2. Enter the login credentials. SecureDoc will be deployed on this device and the deployed state is shown as “Deployed” in the SES Console under the Devices tab.

Note: If the logged in user is a non-excluded Windows user (see discussion of excluded users earlier in this document), then SES will push down the key files of this user to the device.

Option 3: No auto-boot (Using the Temporary user accounts) and automatically identify the device owner without a prompt

Note: This option is similar to when NOT using the "Hide Pre-boot Until User's Credentials are synchronized" option and the user must log into the Boot Logon with initial password during encryption that was available in the earlier version of SES (version 6.5 or lower). In this scenario, the device owner is identified automatically.

Any user that knows the defined temporary login credentials can access the device; however, once the “owner” of the device has been identified, the device will be provisioned and the defined temporary account CANNOT be used to log into that device anymore.

Note: The SES administrators have the option to exclude certain users (e.g. Technicians) from being automatically identified as the device owners by adding their User IDs to the exclusion list in the Profiles – Advanced Options.

1.  Perform the steps 1 through 8 described in Option 1.

2. Select the option entitled Users can access device(s) at Pre-Boot using this Temporary user account. This option prompts the users to authenticate at pre-boot logon using the temporary user ID and Password associated with the Installation Package under which SecureDoc was installed.

3. Click the Browse button to navigate to temporary users window.

4.  In the Owner Identification Rules groupbox, select the Automatically identify owner without having to prompt user option.

5. Perform the step 12 described in the Option 1.

6. Click OK.

Note: If the Synchronize SecureDoc with Windows password (bi-directional) option is not selected, a message “Provisioning can be used only if Synchronize SecureDoc with Windows password profile option is turned on. Do you want to turn this option on” is displayed. Click Yes. The Windows password sync and the Synchronize with matching Windows accounts only options will be turned on.

Deploying Packages

1. Create the Installation Package files.

2. Deploy the package to the client devices. When the SecureDoc installation is complete, the Pre- boot logon screen appears.

3. Use the temporary login credentials to authenticate at pre-boot. SecureDoc will be deployed on this device and the deployed state is shown as “Temp User” in the SES Console under the Devices tab.

Note: When the first Windows user logs into Windows, the key file(s) of that user will be sent down to the device and the temporary user’s key file(s) will be removed from that device. The temporary user login credentials can no longer be used to log into that device. The deployed state will change from “Temp User” to “Deployed”.

Option 4: No auto-boot (Using the Temporary user accounts) & manually identi- fying the device owner with a prompt

Note: For the client devices that are enabled with Fast Startup, the Temp User is shown in the System Slot 0; however, please be advised that the key file of this Temp User is removed from device (s).

Note: This option is similar to when NOT using the "Hide Pre-boot Until User's Credentials are synchronized" option and the user must log into the Boot Logon with initial password during encryption that was available in the earlier version of SES (version 6.5 or lower). In this scenario, the device owner is identified manually thorough a prompt.

Any user that knows the defined temporary login credentials can access the device; the SecureDoc cli- ent agent will display a screen (after the user has authenticated at Windows logon with legitimate Win- dows credentials) that prompts the user to confirm if he/she is the device’s owner. Once the user has confirmed ownership of the device, then that user will be considered as the owner of the device. Until then, the device needs to be authenticated at pre-boot, displays the confirmation message and remains in a provisioning stage.

1.  Perform the steps 1 through 3 described in Option 3.

2. In the Owner Identification Rules groupbox, select the Users will be prompted to confirm device ownership; First to confirm will be device owner option.

3. Perform the step 13 described in the Option 1.

4. Click OK.

Deploying Packages

1. Create the Installation Package files.

2. Deploy the package to the client devices.

3. When the SecureDoc installation is complete, the computer reboots and the Windows login screen appears.

4. Enter the password and the device will log into Windows and a confirmation prompt appears:

5.  Enter the Windows password.

6. Click OK.

Note: If the user is NOT the owner of the device, click the Later button. In this scenario, the device will re-display the ownership confirmation screen after each reboot, remaining in the provisioning stage.

1. After the completion of encryption, the boot logon screen appears.

2. Enter the login credentials. SecureDoc will be deployed on this device and the deployed state of the device will be shown as “Deployed” in the SES Console under the Devices tab.

Note: If the logged in user is a non-excluded Windows user (see discussions of excluded users earlier in this document), then SES will push down the key files of this user to the device.

Note: For the client devices that are enabled with Fast Startup, the Temp User is shown in the System Slot 0; however, please be advised that the key file of this Temp User is removed from device(s).

BLE: New Keyfile Protection Type: Phone Push Integration New Feature: Keyfile Protection Type for Phone Push

We're adding a new keyfile protection type, `KF_PROT_PHONE_PUSH = 0x00000400`. The client needs to send this type to the server.

This ensures the server knows if the keyfile needs to be updated when switching from BLE PUSH to BLE only.

What's Needed:

1. Keyfile Update: The client should send the new protection type to the server.

2. Profile Change Handling: Update the system to handle changes from BLE PUSH to BLE only, updating the keyfile if needed.

Steps:

1. Add the new keyfile protection type.

2. Ensure the client sends this protection type to the server.

3. Update the system to handle profile changes and update the keyfile if necessary.

By adding this new feature, we'll ensure keyfile management is accurate and improve security and func- tionality for users.

Resolving MagicEndpoint App Issues with Android Phones and Windows Dynamic Lock

BLE Pairing and Dynamic Lock Test: Resolving Issues with MagicEndpoint App and Android Phones Using Windows Dynamic Lock

To ensure a seamless experience with the Dynamic Lock feature in Windows and the MagicEndpoint app, it is essential to understand the functionality and compatibility of your devices. Dynamic Lock enhances security by automatically locking your PC when your paired Bluetooth device is out of range. However, certain Android phones may change their device name, leading to issues with Bluetooth pair- ing and password conversion.

The Dynamic Lock feature in Windows may not function correctly with certain Android phones due to changes in the device name, causing issues with Bluetooth pairing and password conversion.

Using iPhone Devices:

iPhones do not experience this issue and work seamlessly with the Dynamic Lock feature. Pair your iPhone with your PC to ensure reliable operation of the Dynamic Lock feature.

Recommendations for Android Users:

If you encounter issues with Dynamic Lock on your Android phone, consider using an iPhone for this fea- ture.

Stay updated with the latest software versions for both your Android phone and the MagicEndpoint app, as future updates may address these issues.

Additional Information:

Dynamic Lock Feature: This Windows feature uses Bluetooth to detect when your paired device (like a smartphone) is out of range and locks your PC for security.

MagicEndpoint App: This app facilitates secure authentication and access management, and it requires stable Bluetooth pairing to function correctly.

By following these steps and recommendations, you can ensure a reliable and secure experience with the MagicEndpoint app and Windows Dynamic Lock, allowing for smooth and automatic locking of your PC when your Bluetooth device is out of range.

Configuring and Deploying Installation Package with Non-Provisioned State

This option is useful in a scenario where the SES administrators do not want to keep a device in a pro- visioning stage and intend to use the password confirmation option so that the users will be prompted to confirm their login credentials. The device will be “provisioned” when the first Windows user logs into that device.

Note: If the user cancels out of the confirmation prompt, the installation will fail and the device will NOT be encrypted. The confirmation prompt will re-appear at each device reboot until the owner of the device has been defined, after which encryption will be able to continue through to completion.

Note: Offline installation for non-provisioning packages is not supported.

1. Log into SES console.

2. Set up the desired global options (Tools Options).

3. (Optional - For Active Directory Users only). In the Profiles window, click the General tab and select the Synchronize SecureDoc with Windows password (bi-directional) option to have the user’s Windows password used, automatically, as the SecureDoc key file password. Changes to the Windows password automatically apply to SecureDoc and changes to the SecureDoc password apply to Windows.

4. In the Installation Package settings window, select the Provisioning Rules tab.

5. In the Owner Identification Rules section, select the Users will be prompted to confirm device ownership: first to confirm will be device owner option.

6. Perform the step 13 described in the Option 1.

7. Click OK.

Deploying Packages

1. Create the Installation Packagefiles.

2. Deploy the package to the client devices.

3. When the SecureDoc installation is complete, the SecureDoc confirmation prompt appears:

1. Enter the Windows password and confirm the same.

2. Click OK. The SecureDoc will be deployed on this device and the deployed state is shown as “Deployed” in the SES Console under the Devices tab.

Viewing the deployed and device owner statuses Deployed Status

A new column called Deployed State has been added in the Devices tab in the SES console. This column indicates the SecureDoc deployment status of a device, i.e. deployed, temp user, temp auto- boot , unknown, and No Provisioning.

Device Owner Status

In the Users having access to the device table under Devices tab, a new column called Owner has been added. This column provides the details regarding the device’s ownership – whether or not the user is the owner.

Creating Installation Package Files

Creating Installation Package Files

Once installation package settings are configured, you can create installation package files:

1. Right-click on the installation package in the information pane and choose Create package files.

2. The files necessary for the installation package are created in the RemotePackage folder created by SES installation, in a subfolder given the package name, under a subfolder given the database’s name.

Note: Once installation package files have been created, they are automatically updated when any changes are made to the profile or installation package options.

Numerous files are created by this process:

• Boot_msg.txt - which contains all the possible error messages a user could see at boot logon time — you can edit this file if necessary

• PackageSettings.ini- configuration file

• SecureDoc_64.exe - installation executables for 64 bit client machines

• SDConnex.cer - certificate file used to validate client machine connecting to SDConnex server

• SDProfile.spf - file containing profile settings media encryption, disk access, port control, CD/DVD encryption, etc.)

• SecureDoc_32.exe - for non-64 bit client devices EXE files require user intervention.

• KnownConfigs.xml - Newly added in V8.2 is the KnownConfigs.xml file that will contain information the SES Installation process will incorporate regarding installation requirements of specific makes/models of computer. The contents of this file will guide the SecureDoc installer to handle potentially problematic device types by applying known-to- be-appropriate configuration options that are unique per device type.

NOTE: Although it is recommended to leave this file in place and allow the SecureDoc installer to use this "best practices" approach to handling potentially problematic hardware, if you do not wish to util- ize this auto-configuration functionality, simply delete or change the file extension of this file (e.g.

KnownConfig.xml.NotUsed).

SCIMSync - Directory Synchronization Service Based on SCIM 2.0 Protocol

SCIMSync - Directory Synchronization Service Based

on SCIM 2.0 Protocol

SCIMSync - Directory Synchronization Service Based on SCIM 2.0 Protocol

SCIM simplifies managing user identities in cloud applications by standardizing how information is shared. This reduces the time and errors involved in adding and maintaining user data, ensuring secure and organized availability across different platforms.

SCIMSync manages user and group data between the client and server. The client sends requests, and the server responds. The client controls how often to sync, whether daily or more frequently. SES acts as the server to handle adding, deleting, and listing users and groups. SCIM focuses on syncing users, not logging them in. The SCIM username and password are unique and should be saved in OKTA and the SCIM settings for basic access.

SCIM Sync Support

The System for Cross-domain Identity Management (SCIM) specification is designed to make managing user identities in cloud-based applications and services easier. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy mod- els. Its intent is to reduce the cost and complexity of user management operations by providing a com- mon user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence: make it fast, cheap, and easy to move users in to, out of, and around the cloud.

Pre-requisites:

• SES installed and configured

• IDP installed and configured Configuration Steps:

• Launch “SeucreDoc Services Configuration -> SDConnex Service -> SCIM Server” tab then enable the service

• Add SCIM Client registration by clicking “Add” button at panel SCIM Client registration

Client Name: Any name you wish to

Client Type: Microsoft Entra ID for Azure or Other for any other Service Providers

Auth Type: Bearer or Basic (it depended on SP supported)

Username, password and Bearer are defined any by admin

• After settings configured, click “Apply” button at bottom of the panel then restart the SDIDP web ser- vice

• Test the SCIM synchronization (e.g. uses SCIM Test app integrated in OKTA and using Runscope app for testing as below)

NOTE: Default SCIM server url -> https://<IDP Host:PORT>/scim This suite runs the following tests:

SCIMSync - Directory Synchronization Service Based on SCIM 2.0 Protocol

1. Check that the integration exists in your Okta org.

2. Add a new random user in Okta.

3. Assign that user to the integration in Okta.

4. Verify that the user was created on your SCIM server.

5. Update the user firstName attribute in Okta.

6. Verify that the user attribute was updated on your SCIM server.

7. Deactivate the user in Okta.

8. Verify that the user was deactivated on your SCIM server.

9. Reactivate the user in Okta.

10. Reassign your integration to the user in Okta.

11. Verify that the user was reactivated and assigned on your SCIM server.

12. Remove your integration from the user in Okta.

13. Verify that the user is deactivated on your SCIM server.

C. 9

Creating Installation Packages for Mac FileVault 2 Computers

SecureDoc can manage the encryption of Apple Mac computers through management of Apple's native encryption tool for OS X, Apple FileVault 2.

Follow the instructions here to create a profile/package for FileVault 2 implementations. See "Creating Installation Packages for Mac Computers" for instructions on how to create a SecureDoc for Mac profile/package.

Creating a Profile/Package for FileVault 2

Currently, installation packages for Mac cannot be sent remotely by SES and must be copied to CD, USB media, or a shared network drive and then run on the client machine to start SecureDoc installation. SED users should not use sleep mode on their encrypted devices.

The steps involved in creating a Mac installation package and installing SecureDoc on a FileVault 2 client device are as follows:

1. Set up SES options (see “Setting SES Global Options” on page 56)

2. Create a profile to manage a device using the native encryption engine ("Creating FileVault2 Profile " below

3. Set installation package options for FileVault 2 (" Creating Installation Packages for Mac FileVault 2 Computers" above).

4. Create installation package files ("Creating Installation Package Files " on page 302) on page 183.

5. Install the software on the Mac computer (see the separate User Guide). All the accounts on the device receiving this package are added to the Unlock List and given access to the encrypted disk. Changes to Unlock List membership can be made through SES: "Mac FileVault2-Specific Commands" on page 415

About Profiles

A profile sets most of the parameters for the SecureDoc installation that you want performed on client devices. Once you have set up a profile, you associate it with installation package options to have it used on client devices. Unlike package settings, profile settings can be changed, and take effect, after installation has taken place.

The profile determines general aspects of how SecureDoc will behave and look on the Mac, for example, what kind of communication is available between it and the SES server, how many failed logins are allowed, and so on. You can create as many profiles as are necessary, or use different profiles for different groups in your organization.

Creating FileVault2 Profile

1. Click Profiles in the navigation pane.

2. Right-click on the information pane and choose Add profile. Click the Endpoint radio button, then from the dropdown list, choose SecureDoc Enterprise for macOS.

3. The Mac FileVault profile dialog appears.

1. Enter a profile name.

2. Click General Options.

1. Complete the FileVault Management tab.

Check this checkbox to enable the use of FileVault2 encryption on Apple Mac endpoint devices.

Enable FileVault2 Encryption

Note: In SES V8.2SR1 the SecureDoc Pre-Boot for macOS devices (SecureDoc "On Top" of FileVault 2, abbreviated as SDOTFV2) was removed from the product line. As a result, any settings for SDOTFV2 have been removed, such as the settings in this panel that were in previous versions, as well as the Boot Text and Color panel, which no longer applies. Further, since the SecureDoc Pre-Boot for FileVault 2 no longer exists, any macOS devices installed with the SecureDoc V8.2SR1 (or later version) client software will no longer be able to participate in PBConnex groups for network-brokered authentication or PBConnex AutoBoot. However, macOS

devices running earlier versions of the SecureDoc client software will continue to be able to work with PBConnex in the ways described above.

Mac User Accounts:

1. Complete the Communication tab.

1. Optionally, complete the Media Encryption tab (for more about media encryption, see "Media Encryption Options").

1. Click OK then Save to save the profile settings.

Creating Installation Packages for FileVault2

1. Click Installation packages in the navigation pane.

2. Right-click on the information pane and choose Add package. When prompted for a package type, Click on the Endpoint radio button, then choose SecureDoc Enterprise for macOS.

3. The Mac FileVault package dialog appears.

Creating Installation Packages for FileVault2

1. Set the options (as described below) and click OK.

Creating Installation Package Files

Once installation package settings are configured, you can create installation package files:

1. Right-click on the installation package in the information pane and choose Create package files.

2. The files necessary for the installation package are created in the RemotePackage folder created by SES installation, in a subfolder given the package name.

C.

Creating Installation Packages for BitLocker o Windows Machines

n

10

Enterprises may choose to use Microsoft's BitLocker Full-Volume Encryption instead of SecureDoc encryp- tion for various reasons such as ease of configuration, low purchase costs and better OS compatibility or they may be slowly migrating from BitLocker to SecureDoc and are looking for support in transitioning from BitLocker encryption to SecureDoc. To satisfy those customers, SecureDoc supports management

of devices encrypted with BitLocker as well as configuration to enable BitLocker encryption when deploying a SecureDoc package.

Crypto-Erase Function