Zextras Mobile

This is legacy documentation that is not updated anymore. For the most up to date version, please refer to our Documentation Hub

https://docs.zextras.com/index.html

Enable Zextras Mobile Synchronization for a COS

How to Enable Zextras Mobile for all Users in a Class Of Service

From the Administration Console

To enable Zextras Mobile for all users in a COS from the Administration Console:

  • Open the Zimbra Administration Console.

  • Double-click the Class Of Service you want to edit (on the left, under Configuration → Class of Service).

  • Click the Mobile tab.

  • Check the Enable mobile synchronization button.

From the Zimbra CLI

To enable Zextras Mobile for all users in a COS from the CLI:

  • As the 'zimbra' user run: zmprov mc COSName zimbraFeatureMobileSyncEnabled TRUE

How to Disable Zextras Mobile for all Users in a Class Of Service

From the Administration Console

To disable Zextras Mobile for all users in a COS from the Administration Console:

  • Open the Zimbra Administration Console.

  • Double-click the Class Of Service you want to edit (on the left, under Configuration → Class of Service).

  • Click the Mobile tab and uncheck the Enable mobile synchronization button.

From the Zimbra CLI

To disable Zextras Mobile for all users in a COS from the CLI:

  • As the 'zimbra' user run: zmprov mc COSName zimbraFeatureMobileSyncEnabled FALSE

Note about Settings Hierarchy

COS-level settings are overridden by user-level settings.

Enable Zextras Mobile for a Single User

By enabling the Zextras Mobile Module for a single user you authorize a single user to use all the mobile functions of the Zextras Mobile Module.

How to Enable Zextras Mobile for a Single User

From the Zimbra Administration Console

To enable Zextras Mobile for a single user from the Administration Console:

  • Open the Zimbra Administration Console.

  • Double-click the user you want to edit (on the left, under Manage → Accounts).

  • Click the Mobile tab.

  • Check Enable mobile synchronization.

From the Zimbra CLI

To enable Zextras Mobile for a single user from the CLI:

  • As the 'zimbra' user run: zmprov ma user@example.com zimbraFeatureMobileSyncEnabled TRUE

How to Disable Zextras Mobile for a Single User

From the Zimbra Administration Console

To disable Zextras Mobile for a single user from the CLI:

  • Open the Zimbra Administration Console.

  • Double-click the user you want to edit (on the left, under Manage → Accounts).

  • Click the Zextras Mobile tab and uncheck Enable mobile synchronization.

From the Zimbra CLI

To disable Zextras Mobile for a single user from the CLI:

  • As the 'zimbra' user run: zmprov ma user@example.com zimbraFeatureMobileSyncEnabled FALSE

Note about Settings Hierarchy

User-level settings override COS-level settings.

The Mobile Password Feature

Mobile Passwords and You

The Mobile Password feature allows Global and Delegated Admins to set an additional password for an account to be used for Exchange ActiveSync authentications only.

The main benefits of using this feature are:

  • Enforce set-and-forget safe passwords, regardless of any other password policy, so that you won’t need to change the password saved on all mobile devices synchronized with an account should this account’s Zimbra password change.

  • Avoid the real password to be disclosed in case of unauthorized access to the device/client.

A Mobile Password will not be valid for Webmail/POP3/IMAP/SMTP logins, and the account password will not be valid for mobile logins.

How to Set a Mobile Password for a Mailbox

Mobile Passwords are handled by the Zextras Auth module, more information can be found at this link.

Mobile Device Management a.k.a. Mobile Provisioning

What is Mobile Device Management?

Mobile Device Management (MDM - also known as provisioning) allows an administrator to define a set of rules and security settings that are applied Over The Air to one or more mobile devices, ranging from PIN policies to Allowed/Blocked app lists and including one time commands, such as the remote wipe of the entire device.

MDM effectively allows administrators to limit and restrict the use of corporate mobile devices to avoid risky or improper behaviors.

MDM is also a priceless aid for Bring Your Own Device corporate policies, allowing users to connect their personal mobile devices to the corporate servers, while reducing the risk of security breaches to a minimum.

Provisioning Features Available on Your Client

Not all provisioning features are available on all clients. Please refer to your device’s manufacturer and online resources for specific information about the MDM features supported by the device itself.

Zextras Suite and MDM

Zextras Suite features advanced MDM features through the Exchange ActiveSync protocol version 14+.

Mobile policies can be enabled at COS and mailbox levels, allowing both a quick one for many setup and user-based customized management. In both cases, Mobile Management Options are available in the Mobile tab.

Provisioning Options

The following provisioning options are available:

  • Enable Mobile Device Management: Enable or disable the use of mobile policies for the current user/COS.

  • Allow non-provisionable devices: Allow the user to synchronize any device that does not support provisioning.

  • Allow partial policy enforcement on device: Allow the user to synchronize any device that does not support one or more applicable policies.

By default, MDM is disabled in Zextras Mobile. To enable navigate to Zextras Suite → Mobile → Advanced Settings and check the “Enable Mobile Device Management” option

Enforceable Policies

Enforceable Policies are available right below the Mobile Devices list, grouped in the following categories:

  • Sync Settings: Set synchronization spans and limits.

  • Device Settings: Enable or disable device features such as camera, WiFi, removable storage or Bluetooth.

  • Device Security Settings: Force an unlock code and define the minimum requirements for the code itself.

  • Device Applications: Enable or disable standard device applications such as the Browser and POP/IMAP client or unsigned apps.

Two lists are also available for application whitelist/blacklist management:

  • Approved Applications: A customizable list of approved applications.

  • Blocked Applications: A customizable list of blocked applications that won’t be usable on the device.

Mobile Password

While conceptually similar, the mobile password feature is not part of Mobile Device Management and can be used with any version of the EAS protocol.

SyncStates

Zextras Mobile and the SyncState

The SyncState (short for Synchronization Status) is a set of information kept on the server about the synchronization with a mobile device. Each time a device establishes a connection with Zextras Mobile, the following steps take place:

  • 1. The device requests a folderSync operation to synchronize the local Folders with the ones on the server.

`    One SyncKey per local folder is sent (or a single SyncKey set to '0' if this is the first connection between the device and the server)   `

  • 2. The server replies with a list of available folders.

`    One SyncKey per folder is sent by the server.`

  • 3. Then, the device requests an itemSync operation to synchronize all due items.

`    The server stores the items synchronized in the SyncState.`

  • 4. After completing the itemSync operation, the device sends a 'ping' command to keep the connection alive.

`    Step 4 is repeated as long as no changes happen to the synchronized account.`

Every time a new item is stored on the mailbox or an old item is modified, the server notifies the availability to the device, which closes the active connection (the one kept alive by the ping command) and repeats steps 3 and 4.

The SyncState is the combination of the SyncKeys saved on step 2 and the itemIds saved on step 3. It’s saved by the server per the userId/deviceId unique pair.

Sync Request

The Sync Request is the actual synchronization process, started by either Zextras Mobile or by the client. During a sync request, any change in the mailbox that happened since the last request is synchronized to the device and vice versa.

A sync request is issued when:

  • The SyncState changes.

  • A sync is forced client-side.

  • The current ping expires and a new one is sent by the device (the keepalive duration is defined by the client).

Managing the SyncStates

Via the Administration Zimlet

Zextras Mobile provides two options in the Administration Zimlet to manage the SyncStates of synchronized mobile devices:

  • Reset Device: Resets the device’s SyncState for a single account, forcing a full re-synchronization the next time the device connects to the server.

  • Wipe Device: Removes all the device’s SyncState and history from the server. Useful when a mobile device is not used anymore or is assigned to a different employee in the same company.

Via the CLI

To manage the SyncStates of synchronized mobile devices via the CLI, use one of the following commands:

The doRemoveDevice command

Syntax:
   zxsuite mobile doRemoveDevice {account} {device_id}

PARAMETER LIST

NAME            TYPE
account(M)      Account Name
device_id(M)    String

(M) == mandatory parameter, (O) == optional parameter

Usage example:

zxsuite mobile doRemoveDevice john@example.com Appl79032X2WA4S
Removes John's Appl79032X2WA4S device SyncState

The doResetAccount command

Syntax:
   zxsuite mobile doResetAccount {account}

PARAMETER LIST

NAME          TYPE
account(M)    Account Name

(M) == mandatory parameter, (O) == optional parameter

Usage example:

zxsuite mobile doResetAccount john@example.com
Resets all the device states for John's account

The doResetDevice command

Syntax:
   zxsuite mobile doResetDevice {account} [attr1 value1 [attr2 value2...

PARAMETER LIST

NAME            TYPE            DEFAULT
account(M)      Account Name
device_id(O)    String          all

(M) == mandatory parameter, (O) == optional parameter

Usage example:

zxsuite mobile doResetDevice john@example.com Appl79032X2WA4S
Resets John's Appl79032X2WA4S device SyncState

Advanced Settings

Zextras Mobile DoS Filter

Zextras Mobile includes a dedicated DoS Filter component to improve both security and stability. The filter will kick in whenever a device exceeds the chosen connection rate over time and will "jail" the device for a set period of time, refusing any connections from it.

This improves both security, helping to prevent Denial of Service attacks, and stability by blocking clients that are performing too many requests due to bugs or malfunctioning saving resources for all other clients.

The Mobile DoS filter is disabled by default, and can be enabled as needed via CLI.

Configuration

The Mobile DoS Filter is entirely configured via CLI, using the following attributes:

  • mobileAntiDosServiceEnabled: enable the Mobile DoS Filter service. Default false;

  • mobileAntiDosServiceJailDuration: duration (in milliseconds) of synchronization "jail". Default 600000;

  • mobileAntiDosServiceTimeWindow interval of time to calculate the connection ratio. The jail is triggered if a device sends more than mobileAntiDosServiceMaxRequests requests in this time window. Default 30000ms;

  • mobileAntiDosServiceMaxRequests maximum number of requests received within mobileAntiDosServiceTimeWindow milliseconds). Default 150;

All attributes are set at global level with zxsuite config global set|get|clear. Specific info for each property can be obtained via zxsuite config info attribute [propertyname].

How Mobile DoS Filter works

When the anti-dos service is running and mobileAntiDosMaxRequests is greater than 0, the system stores in memory the timestamp of the last mobileAntiDosMaxRequests requests. If the maximum number of request timestamps has been stored and all stored requests are within the time window, all new requests from this device/account are dropped for mobileAntiDosJailDuration milliseconds.

When the rate has been exceeded, a warning is sent via email to admin and added to server notifications.

Issuing the command zxsuite mobile doRestartService anti-dos will reset all jails and counters.

Zextras Autodiscover

Zextras Autodiscover is Zextras implementation of the Autodiscover protocol, which allows mail clients to automatically configure the appropriate server settings, avoiding the necessity of a manual configuration. This is a very useful functionality and it is also secure, since it also needs an SSL trusted certificate to work.

How to enable Zextras Autodiscover

To use Zextras Autodiscover you have to edit the jetty template configuration file /opt/zimbra/jetty/etc/jetty.xml.in on all the mailstore servers.

The file is by default as follows:

<Call name="addRule">
  <Arg>
    <New class="org.eclipse.jetty.rewrite.handler.RewritePatternRule">
            <Set name="pattern">/autodiscover/*</Set>
            <Set name="replacement">/service/autodiscover</Set>
    </New>
  </Arg>
</Call>

<Call name="addRule">
  <Arg>
    <New class="org.eclipse.jetty.rewrite.handler.RewritePatternRule">
            <Set name="pattern">/Autodiscover/*</Set>
            <Set name="replacement">/service/autodiscover</Set>
    </New>
  </Arg>
</Call>

<Call name="addRule">
  <Arg>
    <New class="org.eclipse.jetty.rewrite.handler.RewritePatternRule">
            <Set name="pattern">/AutoDiscover/*</Set>
            <Set name="replacement">/service/autodiscover</Set>
    </New>
  </Arg>
</Call>

You need to change it to:

<Call name="addRule">
  <Arg>
    <New class="org.eclipse.jetty.rewrite.handler.RewritePatternRule">
            <Set name="pattern">/autodiscover/*</Set>
            <Set name="replacement">/service/extension/autodiscover</Set>
    </New>
  </Arg>
</Call>

<Call name="addRule">
  <Arg>
    <New class="org.eclipse.jetty.rewrite.handler.RewritePatternRule">
            <Set name="pattern">/Autodiscover/*</Set>
            <Set name="replacement">/service/extension/autodiscover</Set>
    </New>
  </Arg>
</Call>

<Call name="addRule">
  <Arg>
    <New class="org.eclipse.jetty.rewrite.handler.RewritePatternRule">
            <Set name="pattern">/AutoDiscover/*</Set>
            <Set name="replacement">/service/extension/autodiscover</Set>
    </New>
  </Arg>
</Call>

This change is mandatory if you use mobile password.

You can also easily change this settings with this command:

sed -i 's|/service/autodiscover|/service/extension/autodiscover|g' /opt/zimbra/jetty/etc/jetty.xml.in

Zextras Mobile Performance Tuning

Zextras Mobile provides three useful options to fine-tune Zextras Mobile according to system performance.

Performance Tuning Settings

Available Settings

  • Notifications Latency (ZxMobile_NotificationsLatency): The seconds of delay between an event on the server and its notification to the mobile device.

  • Use Instant Notifications (ZxMobile_UseInstantNotficiations): Enable/Disable instant notifications. Overrides Notifications Latency if true.

  • Max Ping Heartbeat (ZxMobile_MaxPingHeartbeat): Maximum interval between 'ping' commands.

All settings can be edited in the Administration Zimlet or via CLI using the zxsuite config command.

When to Edit the Performance Tuning Settings

Default settings should be optimal for most situations. If you experience one or more of the problems below, please apply the proper solution.

Problem Solution

High system load

Disable instant notifications

High system load after disabling instant notifications

Raise notification latency

Mobile users experience high network usage

Disable instant notifications and tweak notifications latency

Devices can connect but sessions are interrupted frequently

Adjust Max Ping Heartbeat according to your network configuration

Items are synchronized from server-to-device with an excessive delay

Lower notification latency or enable instant notifications

Shared Folders

Shared Folders and You (and Your Mobile)

With Zextras Suite, it’s possible to synchronize folders that are not owned by the user itself to mobile devices. This applies to all item types available through the Exchange ActiveSync protocol, so you’ll be able to sync any shared email folder, address book, calendar or task list to mobile devices.

Specific features available on mobile devices might differ, based on the client in use.

Not all clients support the synchronization of multiple address books, calendars or task lists via Exchange ActiveSync.

How to Sync a Shared Folder to Your Mobile Devices

To allow a higher level of control over synchronization, users can choose the shared folders to synchronize with their mobile devices.

Enable Mobile Synchronization for a Shared Folder

To enable mobile synchronization for a shared folder:

  • Log in to the Zimbra Web Client.

  • Right-click the shared folder to sync.

  • Select Folder Sync Settings in the drop-down menu.

  • Select the checkbox Enable synchronization for this folder checkbox.

  • Press OK.

The new folder will be synchronized to any mobile device connected to the account.

Disable Mobile Synchronization for a Shared Folder

To exclude a shared folder from syncing with a mobile device:

  • Log in to the Zimbra Web Client.

  • Right-click the shared folder to sync.

  • Select Folder Sync Settings in the drop-down menu.

  • Clear the checkbox Enable synchronization for this folder checkbox.

  • Press OK.

Restrictions

The following restrictions apply to shared folder synchronization:

  • It’s not possible to sync a mountpoint referring to a full account share.

  • It’s not possible to sync a subfolder of a shared folder, as doing so would return an incomplete folder tree.

  • It’s not possible to sync a read-only share, as the Exchange ActiveSync protocol does not envision the concept of a read-only resource. Synchronizing a read-only folder will cause severe inconsistencies between the client and the server, along with many errors.

EAS Filters

In the EAS protocol, the protocol version used for the synchronization is defined during the initial handshake and never changed. The server presents a list of all available protocol versions and the client chooses one among that list.

EAS filters are a way to limit the EAS version available to a subset of users or clients to ensure that the proper version is used.

Multiple EAS filters can be set up and will be evaluated in sequential order (see the getAllEASFilters and doMoveEASFilter commands below).

Anatomy of an EAS Filter

An EAS filter is composed of 5 parts:

  • Type: Defines the type of filter rule.

  • Parameter: The filtering identifier (e.g. device brand or email address).

  • Mode: Defines whether the software will limit the available versions or provide a fixed list.

  • easversions field: Contains the protocol versions enforced by the filter.

  • Blocking boolean value: Defines whether other filters are executed once the current one is successfully matched.

Managing EAS Filters

EAS filters are managed through the CLI using the following four dedicated commands.

  • zxsuite mobile getAllEASFilters

This command lists all existing filters.

Sample Output:

        filters

                ID                                                          0
                mode                                                        fixed
                rule                                                        [type = or; rules = [[type = contains; rule = outlook/] OR [type = contains; rule = microsoft.outlook]]
                easversions                                                 14.0
                blocking                                                    true

                ID                                                          1
                mode                                                        limit
                rule                                                        [type = contains; rule = samsung]
                easversions                                                 2.5
                blocking                                                    false

                ID                                                          2
                mode                                                        limit
                rule                                                        [type = always]
                easversions                                                 14.1
                blocking                                                    false

  • zxsuite mobile doAddEASFilter

This command adds a new EAS filter.

zxsuite mobile doAddEASFilter

Syntax:
   zxsuite mobile doAddEASFilter {and|or|regex|contains|account} {text|people@example.com|account=example@ff.com,contains=android} {add|subtract|fixed|limit} {easversions} [attr1 value1 [attr2 value2...]]

PARAMETER LIST

NAME              TYPE               EXPECTED VALUES
type(M)           Multiple choice    and|or|regex|contains|account
parameter(M)      String             text|people@example.com|account=example@ff.com,contains=android
mode(M)           Multiple choice    add|subtract|fixed|limit
easversions(M)    String[,..]
blocking(O)       Boolean            true|false

(M) == mandatory parameter, (O) == optional parameter

Usage example:

zxsuite mobile doAddEASFilter contains android fixed 2.5,12.0,14.1
Adds a protocol filter that will restrict the pool of available EAS versions to 2.5, 12.0 and 14.1 if the user agent name
contains the string 'android'.

zxsuite mobile doAddEASFilter and account=user@example.com,contains=android fixed 14.1 blocking true
Adds a protocol filter that will restrict the pool of available EAS versions to 14.1 if the user agent name
contains the string 'android' only for user@example.com. No more EAS filters will be evaluated after this one due to the 'blocking' directive.

  • zxsuite mobile doDeleteEASFilter

This command deletes an existing EAS Filter.

zxsuite mobile doDeleteEASFilter
command doDeleteEASFilter requires more parameters

Syntax:
   zxsuite mobile doDeleteEASFilter {id}

PARAMETER LIST

NAME     TYPE
id(M)    Integer

(M) == mandatory parameter, (O) == optional parameter

Usage example:

zxsuite mobile doDeleteEASFilter 2
Removes the filter with id = 2.
To show a list of the filters, use the
	zxsuite mobile getAllEASFilters
command.

  • zxsuite mobile doMoveEASFilter

This command is used to move EAS filters to a different position in the filter queue.

zxsuite mobile doMoveEASFilter
command doMoveEASFilter requires more parameters

Syntax:
   zxsuite mobile doMoveEASFilter {from} {to}

PARAMETER LIST

NAME       TYPE
from(M)    Integer
to(M)      Integer

(M) == mandatory parameter, (O) == optional parameter

Usage example:

zxsuite mobile doMoveEASFilter 0 5
Moves the filter with id = 0 to the position 5.
To show a list of the filters, use the
	zxsuite mobile getAllEASFilters
command.

Mobile Account Loggers

Mobile account loggers are dedicated loggers that can output the entirety of a user’s EAS logs into a dedicated logfile, with a different verbosity than the one of the sync.log. This allows for quicker troubleshooting.

When creating an account logger, the following parameters must be specified:

  • The target account.

  • The log_level (verbosity) of the log.

  • The dedicated log_file.

  • The window_size to enforce on all devices synchronizing with the account while the logger is running.

Account loggers are removed automatically when the mailboxd is stopped or restarted and do not usually survive a mailboxd crash. Log files won’t be affected.

Account Logger Management

Account loggers can only be managed via the CLI through the following commands:

zxsuite mobile doAddAccountLogger

zxsuite mobile doAddAccountLogger
command doAddAccountLogger requires more parameters

Syntax:
   zxsuite mobile doAddAccountLogger {account} {debug|info|warn|err|crit} {log_file} [attr1 value1 [attr2 value2...]]

PARAMETER LIST

NAME              TYPE               EXPECTED VALUES
account(M)        Account Name
log_level(M)      Multiple choice    debug|info|warn|err|crit
log_file(M)       Path
window_size(O)    Integer            a value > 0

(M) == mandatory parameter, (O) == optional parameter

Usage example:

zxsuite mobile doaddaccountlogger john@example.com info /tmp/john_logger
Creates an info account logger for john's account to file /tmp/john_logger

zxsuite mobile doaddaccountlogger john@example.com info /tmp/john_logger window_size 1
Creates an info account logger for john's account to file /tmp/john_logger with window size set to 1.

zxsuite mobile doRemoveLogger

zxsuite mobile doRemoveLogger
command doRemoveLogger requires more parameters

Syntax:
   zxsuite mobile doRemoveLogger {logger_id|"all_loggers"}

PARAMETER LIST

NAME            TYPE               EXPECTED VALUES
logger_id(M)    Multiple choice    logger_id|"all_loggers"

(M) == mandatory parameter, (O) == optional parameter

Usage example:

zxsuite mobile doremovelogger 5
Removes the account logger with ID = 5

zxsuite mobile getAccountLoggers

Sample output:

zxsuite mobile getAccountLoggers

        loggers

                id                                                          7
                level                                                       DEBUG
                name                                                        AccountLogger
                description                                                 Logging account user@example.com using level debug, log file /tmp/user.log
                remove command                                              zxsuite mobile doRemoveLogger 7

ABQ - Allow/Block/Quarantine device control

ABQ Service

This is legacy documentation that is not updated anymore. For the most up to date version, please refer to our Documentation Hub

https://docs.zextras.com/index.html

The "Allow/Block/Quarantine" feature allows for granular access control of mobile devices connecting to the server. It’s a "pre-emptive" type of security feature, meaning that it acts upon the first connection to the server and it’s made to ensure that only authorized devices can finalize synchronization with server. This allows a full administrator to keep track of all mobile device used in their network. Presently only CLI tools are provided; a web GUI will be released in the future.

Components

The ABQ feature is composed of three main logical components:

  • a Device Control List

  • an Authorization Engine

  • a set of CLI tools

Device Control List

The Device Control List, also known as the "ABQ List", holds the information about allowed devices within the config engine. Devices can be added to the Device Control List via CLI based on their “Device ID” which can be obtained via CLI.

It is also possible to further limit access by limiting the accounts that can synchronise with the server on a specific device.

On module startup, if the Device Control List is empty all mobile devices previously recognized by the Zimbra server will be imported as Allowed.
Authorization Engine

The Authorization Engine takes care of checking devices against the Device Control List and setting their ABQ status to the appropriate value.

Each rule is applied to all accounts connecting using a device it is a device id. It applies to a specific account connecting using that device if it has the format device_id/account_id or device_id/accountName

CLI Toolset.

The CLI Toolset allows administrators to interact with the device control list and with the synchronization status of a device, specifically to:

  • Display the Device Control List

  • Display all Quarantined and Blocked Devices

  • Add one or more devices to the Device Control List

  • Move a device from “Quarantine” to “Allowed” or “Blocked”

  • Change the synchronization status of a device

Every time the administrator changes a device’s status in an ABQ-enabled environment, depending on the issued state the device will be forced to re-sync folders with the server resulting in an immediate re-route to either a dummy virtual mailbox that will explain to the user what’s happened, or to the real mailbox to perform the re-sync.

ABQ Modes

The ABQ feature is triggered for every mobile device that tries to synchronize with server, and can be set to one of four possible modes: "Permissive", "Interactive", "Strict” and "Disabled". This attribute is Global for all the cluster.

"Permissive" mode:

The Authorization Engine is not active, so after authenticating the user and checking their account status for safety reasons, the synchronization will continue. It is still possible to block specific devices but non-blocked devices will always be allowed to sync.

"Interactive" mode:

After authenticating the user and checking their account status for safety reasons, the Device Control system will check the "Device ID" sent by the device against the list of allowed devices:

  • if the device/user couple is in the "allowed" list the synchronization will continue.

  • if the device/user couple is not in the device list but device is in the "allowed" list the synchronization will continue.

  • if the device is not in the “allowed” list the synchronization will be paused, a dummy email notifying the user of its "Quarantine" status will be sent and the connection will be set to "Quarantine" status.

Administrators can be notified at regular intervals, and every notification email will only include new Quarantined devices. They will then be able to allow or deny the synchronization for each device using the appropriate CLI tools.

"Strict" mode:

After authenticating the user and checking their account status for safety reasons, the Device Control system will check the "Device ID" sent by the device against the list of allowed devices:

  • if the device/user couple or the device by itself is in the "allowed" list the synchronization will continue.

  • if the device is not in the “allowed” list the synchronization will be put in "Blocked" state, no data will be synchronized and a dummy email notifying the user of the device’s "Blocked" status will be sent.

"Disabled" mode:

ABQ is disabled, no checks are triggered and no policies are enforced.

ABQ Mode Control

The current mode can be checked by running the following command:

zxsuite config global get attribute abqMode

The ABQ mode can be changed running the following command:

zxsuite config global set attribute abqMode value [Permissive|Interactive|Strict|Disabled]

Dummy data

The feature makes use of “Dummy emails” and a “Dummy mailbox” to put devices on hold while waiting for authorization (Interactive Mode) or to notify their “Blocked” status (Permissive Mode, Interactive Mode and Strict Mode).

The Dummy Mailbox is a virtual mailbox consisting of only an “Inbox” folder that will be synchronized to the device while this is in either Quarantine or Block status. Dummy Emails are predefined email messages that are synchronized to a device in Quarantine or Block status to alert the user. For now these messages aren’t customizable, and will be localized in the future. Whenever the ABQ status of a device is changed, the device’s sync state will be reset.

This was designed to make sure the user knows what’s happening, the alternative being forcing the synchronization to fail with no descriptive response for the user itself – which would likely cause a significant overhead on support calls.

Custom ABQ emails

Quarantine and block dummy emails can be customized by using the zxsuite mobile setABQMessage message command.

Messages can be customized globally or by domain, and multiple languages can be set.

The zxsuite mobile setABQMessage command accepts the following parameters:

Parameter Type Value Default

configLevel

string

global,domain

global

domain

string

only if config != global

messageClass

enum

blocked,quarantined

language

enum

locale (e.g. "en-us")

system default

from

string

Admin Address

reply_to

string

N/A

subject

string

Built-in default

body_plain

string

Built-in default

body_plain_file

path

Path to the file to use as plain text body

N/A

body_html

string

Built-in default

body_html_file

path

Path to the file to use as html body

N/A
Setup Example

Given two files, /tmp/quarantine_body.txt and /tmp/quarantine_body.html containing the French language plaintext and html message bodies and the support@example.com support email address, the following command will set the quarantine message for the example.com domain without affecting other domains or users:

zxsuite mobile setABQMessage domain example.com quarantined fr from support@example.com body_plain_file /tmp/quarantine_body.txt body_html_file /tmp/quarantine_body.html

Before being able to customize the ABQ messages, a default must be set using default as the language in the command, e.g.

zxsuite mobile setABQMessage global quarantined default […​]

Notifications

Administrators can be notified via email of quarantined devices at a specific interval defined by the abqNotificationsInterval configuration attribute, expressed in milliseconds:

The interval can be checked by running the following command:

zxsuite config global get attribute abqNotificationsInterval

The interval can be changed running the following command:

zxsuite config global set attribute abqNotificationsInterval value [delay in milliseconds]

By default, the abqNotificationsInterval is set to 0 - meaning that no notifications will be delivered.

ABQ Service Status

The ABQ service status can be checked running the following command:

zxsuite mobile getServices

The service can be stopped or started using the default service control of the Mobile module:

zxsuite mobile doStartService abq
zxsuite mobile doStopService abq

When mode is Disabled ABQ service won’t automatically start and devices are always allowed to sync.

ABQ CLI

A list of all ABQ CLI commands can be displayed running:

$ zxsuite mobile abq

Allow/Block/Quarantine mobile devices management

    list                    - List devices.
                              zxsuite mobile ABQ list [attr1 value1 [attr2 value2...] ]

    import                  - add/import devices
                              zxsuite mobile ABQ add [attr1 value1 [attr2 value2...] ]

    allow                   - Allow synchronization for a quarantined device
                              zxsuite mobile ABQ allow {device_id}

    block                   - Deny synchronization for a quarantined device
                              zxsuite mobile ABQ block {device_id}

    set                     - Set synchronization status for a device
                              zxsuite mobile ABQ set {device_id} {Allowed|Blocked|Quarantined}

    delete                  - Delete device from ABQ
                              zxsuite mobile ABQ delete {device_id}

    setNotificationInterval - Set the notification interval for new quarantined devices
                              zxsuite mobile ABQ setNotificationInterval {45m|6h|1d|0}
ABQ "list" Command

List all devices ABQ status. The "status" argument will filter the list in order to only show devices in that specific status.

$ zxsuite mobile abq list
List devices.

Syntax:
   zxsuite mobile ABQ list [attr1 value1 [attr2 value2...] ]


PARAMETER LIST

NAME        TYPE    EXPECTED VALUES
status(O)   String  Allowed|Blocked|Quarantined

(M) = mandatory parameter, (O) = optional parameter

Example:

[zimbra@mail ~]$ zxsuite mobile abq list

        devices

                device_id   androidc133785981
                status      Quarantined

                device_id   androidc1024711770
                status      Blocked

                device_id   SAMSUNG1239862958
                status      Allowed
ABQ "import" Command

This command imports a list of device ids from a file, and always requires two parameters: an Input File with a list of Device IDs separated by a newline and the "status" the imported device(s) will be set to.

[zimbra@mail ~]$ zxsuite mobile abq import
command import requires more parameters

Syntax:
    zxsuite mobile ABQ import {Path to file} {Allowed|Blocked|Quarantined}

PARAMETER LIST

NAME            TYPE        EXPECTED VALUES
input_file(M)   String      Path to file
status(M)       String      Allowed|Blocked|Quarantined

(M) = mandatory parameter, (O) = optional parameter

Usage example:

zxsuite mobile ABQ import /path/to/file Allowed

Example:

[zimbra@mail ~]$ zxsuite mobile abq import /tmp/list Allowed
3 devices added

[zimbra@mail ~]$ cat /tmp/list
androidc133785981
androidc1024711770
SAMSUNG1239862958/user@example.com

In the example above, devices androidc133785981 and androidc1024711770 are allowed to sync entirely regardless of the account, while device SAMSUNG1239862958 can only synchronise the user@example.com account

ABQ "allow" Command

This is a specific command for quarantined device, and sets device status to Allowed.

$ zxsuite mobile abq allow
Allow synchronization for a quarantined device

Syntax:
   zxsuite mobile ABQ allow {device_id} [attr1 value1 [attr2 value2...]]

PARAMETER LIST

NAME            TYPE      EXPECTED VALUES
device_id(M)    String
account(O)      String    27ee8dd9-d813-4ca7-a988-580df0027a58|user1@example.com

(M) = mandatory parameter, (O) = optional parameter
ABQ "block" Command

This is a specific command for quarantined device, and sets device status to Blocked.

$ zxsuite mobile abq block
Deny synchronization for a quarantined device

Syntax:
   zxsuite mobile ABQ block {device_id} [attr1 value1 [attr2 value2...]]

PARAMETER LIST

NAME            TYPE      EXPECTED VALUES
device_id(M)    String
account(O)      String    27ee8dd9-d813-4ca7-a988-580df0027a58|user1@example.com

(M) = mandatory parameter, (O) = optional parameter
ABQ "set" Command

Set any status for any single device (either known or unknown).

$ zxsuite mobile abq set
Set synchronization status for a device

Syntax:
   zxsuite mobile ABQ set {device_id} {Allowed|Blocked|Quarantined} [attr1 value1 [attr2 value2...]]

PARAMETER LIST

NAME            TYPE      EXPECTED VALUES
device_id(M)    String
status(M)       String    Allowed|Blocked|Quarantined
account(O)      String    27ee8dd9-d813-4ca7-a988-580df0027a58|user1@example.com

(M) = mandatory parameter, (O) = optional parameter
ABQ "rule" Commands

This set of commands allows to manage ABQ rules via custom regular expressions.

Mobile ABQ regular expressions comply with the "Java regex patterns" standard (ERE with doubled backslashes).

  • zxsuite mobile abq setRule - equivalent of the set command for regex-based rules

zimbra@mail:~$ zxsuite mobile abq setRule
command setRule requires more parameters

Syntax:
   zxsuite mobile ABQ setRule {regex} {Allowed|Blocked|Quarantined} {order} [attr1 value1 [attr2 value2...]]

PARAMETER LIST

NAME         TYPE      EXPECTED VALUES
regex(M)     String
status(M)    String    Allowed|Blocked|Quarantined
order(M)     Long
domain(O)    String    Domain name|id

(M) == mandatory parameter, (O) == optional parameter

Usage example:

zxsuite mobile ABQ setRule "android.*" Blocked 10 domain example.com

  • zxsuite mobile abq deleteRule - equivalent of the delete command for regex-based rules

Syntax:
   zxsuite mobile ABQ deleteRule {regex} [attr1 value1 [attr2 value2...]]

PARAMETER LIST

NAME         TYPE      EXPECTED VALUES
regex(M)     String
domain(O)    String    Domain name|id

(M) == mandatory parameter, (O) == optional parameter

Usage example:

zxsuite mobile ABQ deleteRule "android.*" domain example.com

  • zxsuite mobile abq listRules - equivalent of the list command for regex-based rules

Standard and regex-based rules can be freely mixed and matched.

Community Article:

https://community.zextras.com/zextras-suite-3-1-8-added-features-to-abq/

An in-depth article about the setRule, deleteRule, listRules commands, including an important section about the order of evaluation or Regular Expressions.

ABQ "delete" Command

Delete a device from all lists.

$ zxsuite help mobile abq delete
Delete device from ABQ

Syntax:
   zxsuite mobile ABQ delete {device_id} [attr1 value1 [attr2 value2...]]

PARAMETER LIST

NAME            TYPE      EXPECTED VALUES
device_id(M)    String
account(O)      String    27ee8dd9-d813-4ca7-a988-580df0027a58|user1@example.com

(M) = mandatory parameter, (O) = optional parameter
ABQ "setNotificationInterval" Command

Set notification interval for new quarantined devices.

$ zxsuite mobile abq setNotificationInterval
command setNotificationInterval requires more parameters

Syntax:
    zxsuite mobile ABQ setNotificationInterval {45m|6h|1d}

PARAMETER LIST

NAME            TYPE        EXPECTED VALUES
interval(M)     String      45m|6h|1d

(M) = mandatory parameter, (O) = optional parameter

Usage example:

Set notification of new quarantined devices every 45 minutes
    zxsuite mobile abq setNotificationInterval 45m
Set notification of new quarantined devices every 6 hours
    zxsuite mobile abq setNotificationInterval 6h
Set notification of new quarantined devices once every day
    zxsuite mobile abq setNotificationInterval 1d
Disable notifications of new quarantined devices
    zxsuite mobile abq setNotificationInterval 0

Zextras Mobile CLI

This section contains the index of all zxsuite mobile commands. Full reference can be found in the dedicated section.

ABQ allow | ABQ block | ABQ delete | ABQ deleteRule | ABQ import | ABQ list | ABQ listRules | ABQ set | ABQ setNotificationInterval | ABQ setRule | addressBook add domain | addressBook add global | addressBook list domain | addressBook list global | addressBook remove domain | addressBook remove global | deleteABQMessage domain | deleteABQMessage global | doAddAccountLogger | doAddEASFilter | doDeleteEASFilter | doMoveEASFilter | doRemoveDevice | doRemoveLogger | doResetAccount | doResetDevice | doRestartService | doResumeDeviceSync | doSimulateSync | doStartService | doStopService | doSuspendDeviceSync | doWipeDevice | duplicateABQMessage domain | duplicateABQMessage global | getABQMessage domain | getABQMessage global | getAccountLoggers | getAllDevices | getAllEASFilters | getDeviceInfo | getDeviceList | getProperty | getProvisioning | getServices | initABQMessage | setABQMessage domain | setABQMessage global | setProperty | setProvisioning | setSharedFolderSync