Have a Question?
Zextras Mobile Synchronisation for a COS should be enabled.
Take Note of the Settings Hierarchy
User-level settings take precedence over COS-level options.
Allow Zextras Mobile for One User
By enabling the Zextras Mobile Module for a single user, you grant that user access to all of the Zextras Mobile Module’s mobile features.
How to Make Zextras Mobile Available to a Single User
Mobile Passwords and You Mobile Passwords and You
The Mobile Password feature enables Global and Delegated Admins to create a new password for an account that will only be used for Exchange ActiveSync authentications.
The following are the primary advantages of utilising this feature:
- Enforce set-and-forget secure passwords, regardless of any other password policy, so you don’t have to change the password kept on all mobile devices synchronised with an account if the Zimbra password for this account changes.
- Avoid revealing the true password in the event of unauthorised access to the device/client.
A Mobile Password will not be accepted for Webmail/POP3/IMAP/SMTP logins, and neither will the account password.
How to Configure a Mobile Password for a Mailbox
The Zextras Auth module handles mobile passwords; further details may be found in the section Create New Credentials: EAS.
Mobile Device Management is also known as Mobile Provisioning.
What is Mobile Device Management (MDM – also known as provisioning)? 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 remote device wipe.
MDM enables managers to efficiently regulate and restrict the usage of business mobile devices in order to minimise unsafe or unethical behaviour.
MDM is also a valuable tool for corporate Bring Your Own Device policy, allowing users to connect their own mobile devices to corporate servers while minimising the risk of security breaches.
Provisioning Options Are Available for Your Client
Not every provisioning capability is available on every client. For particular information on the MDM features supported by your device, please consult the manufacturer and internet resources.
MDM and Zextras Suite
Zextras Suite includes comprehensive MDM capabilities through the Exchange ActiveSync protocol version 14+.
Mobile policies may be activated at the COS and mailbox levels, allowing for both one-time setup and user-based customization. Mobile Management Options are provided in both circumstances under the Mobile tab.
Provisioning Alternatives
Provisioning options include the following:
- Enable Mobile Device Management: Select whether or not to utilise mobile policies for the current user/COS.
- Allow non-provisionable devices: Allow the user to synchronise any non-provisionable device.
- Allow for just limited policy enforcement on the device: Allow the user to sync any device that does not support one or more rules.
Policy Enforceability
Enforceable Policies are provided just beneath the Mobile Devices list, and are organised into the following categories:
- Sync Options: Configure the synchronisation spans and limitations.
- Device settings allow you to enable or deactivate device functions such as the camera, WiFi, portable storage, and Bluetooth.
- Device Security Settings: Force an unlock code and specify the code’s minimal criteria.
- Enable or deactivate conventional device programmes such as the browser and POP/IMAP client, as well as unsigned apps.
There are additionally two lists for managing application whitelists and blacklists:
Applications that have been approved
A list of authorised applications that may be customised.
Applications That Are Blocked
A list of prohibited programmes that will not be used on the device.
Password for Mobile Device
The mobile password function, while theoretically identical, is not part of Mobile Device Management and may be used with any version of the EAS protocol.
The SyncStates Zextras Mobile and the SyncStates Zextras
The SyncState (short for Synchronisation Status) is a collection of information concerning synchronisation with a mobile device that is retained on the server. When a device establishes a connection with Zextras Mobile, the following events occur:
The device requests that a folderSync action be performed in order to synchronise the local Folders with those on the server.
- One SyncKey is delivered for each local folder (or a single SyncKey set to ‘0’ if this is the device’s initial connection to the server).
- The server responds with a list of directories that are accessible.
- The server sends one SyncKey per folder.
- To synchronise all due items, the gadget requests an itemSync action.
- The synchronised objects are saved in the SyncState by the server.
- Following the completion of the itemSync operation, the device sends a ‘ping’ instruction to maintain the connection.
- Step 4 is performed as long as there are no modifications to the synced account.
When a new item is added to the mailbox or an existing item is changed, the server alerts the device, which terminates the active connection (the one kept alive by the ping command) and repeats processes 3 and 4.
The SyncState is made up of the SyncKeys stored in step 2 and the itemIDs saved in step 3. The server saves it based on the unique userID/deviceID pair.
Request for Synchronisation
The actual synchronisation procedure is initiated by either Zextras Mobile or the client. Any update in the mailbox that has occurred since the last request is synchronised to the device during a sync request, and vice versa.
A sync request is generated when:
- The SyncState variable changes.
- A client-side sync is required.
- The current ping expires, and the device sends a fresh one (the client specifies the keepalive time).
Managing the Advanced SyncStates Settings
Mobile DoS Filter by Zextras
To boost security and stability, Zextras Mobile features a dedicated DoS Filter component. The filter will activate anytime a device exceeds the selected connection rate over time and will “jail” the device for a certain amount of time, denying any connections from it.
This enhances both security and stability by preventing clients that are conducting too many queries owing to faults or malfunctions, freeing up resources for all other clients.
Configuration
- The Mobile DoS Filter is completely set through CLI, and the following characteristics are used:
- mobileAntiDosServiceEnabled: the Mobile DoS Filter service is enabled. The default value is false;
- mobileAntiDosServiceJailDuration: synchronisation “jail” duration (in milliseconds). 600000 is the default value.
- To compute the connection ratio, use the mobileAntiDosServiceTimeWindow period of time. If a device submits more than mobileAntiDosServiceMaxRequests requests in this time interval, the prison is activated. 30000ms is the default value.
- mobileAntiDosServiceMaxRequests specifies the maximum number of requests that may be received within the mobileAntiDosServiceTimeWindow milliseconds. The default value is 150.
With zxsuite config global set|get|clear, all attributes are set at the global level. Specific information for each property is available via the zxsuite config info element [propertyname].
How Does a Mobile DoS Filter Work?
When the anti-dos service is active and mobileAntiDosMaxRequests is larger than zero, the system retains the timestamp of the most recent mobileAntiDosMaxRequests requests in memory. All new requests from this device/account are rejected for mobileAntiDosJailDuration milliseconds if the maximum number of request timestamps have been saved and all stored requests are within the time range.
When the rate is exceeded, an email is sent to the administrator and a notification is sent to the server alerts.
Autodiscover by Zextras
Zextras Autodiscover is Zextras’ implementation of the Autodiscover protocol, which allows mail clients to specify the proper server settings automatically, eliminating the need for human configuration. This is a really helpful feature that is also secure because it requires an SSL trustworthy certificate to function.
If you use a mobile password, you must make this modification.
This command allows you to simply alter certain settings:
Mobile Performance Tuning by Zextras
Zextras Mobile has three essential options for fine-tuning the application based on system performance.
Latency in Notifications
ZxMobile_NotificationsLatency is the number of seconds that pass between an event on the server and notification to the mobile device.
Make use of Instant Notifications.
ZxMobile_UseInstantNotficiations controls whether immediate notifications are enabled or disabled. If true, it overrides Notifications Latency as well.
Ping Heartbeat Max
The maximum interval between ping commands is defined by ZxMobile_MaxPingHeartbeat.
All settings may be changed using the Administration Zimlet or the zxsuite config command at the command line.
When to Change Performance Tuning Options
The default settings should be adequate in most cases. If you encounter one or more of the issues listed below, please use the appropriate remedy.
Shared Folders and You (together with Your Mobile)
It is possible to synchronise folders that are not owned by the user to mobile devices using Zextras Suite. This applies to all Exchange ActiveSync item types, so you’ll be able to sync any shared email folder, contact book, calendar, or task list to mobile devices.
Specific functionality accessible on mobile devices may vary depending on the client in use.
Syncing a Shared Folder to Your Mobile Devices
Users may pick which shared folders to sync with their mobile devices to provide more control over synchronisation.
Enable Shared Folder Mobile Synchronisation
To enable mobile synchronisation for a shared folder, do the following:
- Access the Zimbra Web Client.
- To sync, right-click the shared folder.
- In the drop-down option, select Folder Sync Settings.
- Mark the checkbox Check the Enable synchronisation for this folder box.
- Click OK.
The new folder will be synchronised with any mobile device that is linked to the account.
Disable Shared Folder Mobile Synchronisation
To prevent a shared folder from synchronising with a mobile device, do the following:
- Access the Zimbra Web Client.
- To sync, right-click the shared folder.
- In the drop-down option, select Folder Sync Settings.
- Uncheck the box Check the Enable synchronisation for this folder box.
- Select OK Restrictions.
The constraints for shared folder synchronisation are as follows:
A mountpoint referring to a whole account share cannot be synced.
It is not feasible to sync a shared folder subfolder since doing so would result in an incomplete folder tree.
A read-only share cannot be synced because the Exchange ActiveSync protocol does not support the idea of a read-only resource. Synchronising a read-only folder will result in severe discrepancies between the client and server, as well as several errors.
Filters for EAS
The protocol version used for synchronisation in the EAS protocol is specified at the initial handshake and is never modified. The server displays a list of all possible protocol versions, from which the client selects one.
EAS filters are a method of restricting the EAS version available to a group of users or clients in order to verify that the correct version is utilised.
Multiple EAS filters can be configured and assessed in the order specified (see the getAllEASFilters and doMoveEASFilter commands in the section Managing EAS Filters below).
The EAS Filter’s Anatomy
An EAS filter is made up of five parts:
The kind of filter rule is defined by this property.
Parameter
Filtering identification (for example, device brand or email address).
Mode
This option specifies whether the software will limit the available versions or present a fixed list.
field of easversions
Contains the protocol versions that the filter enforces.
If the current filter is successfully matched, the blocking Boolean value determines whether further filters are performed.
EAS Filter Administration
The following four specialised command are used to control EAS filters via the CLI.
Account Loggers for Mobile Devices
Mobile account loggers are specialised loggers that can output the totality of a user’s EAS logs into a separate logfile with a different level of verbosity than the sync.log. This facilitates faster troubleshooting.
The following parameters must be given while creating an account logger:
- The desired account.
- The log’s log_level (verbosity).
- The log_file is dedicated.
- While the logger is active, the window_size will be enforced on all devices synchronising with the account.
Management of Account Loggers Account loggers may only be managed through the CLI using the following commands:
ABQ – Device Control Allow/Block/Quarantine ABQ Service
Granular access control of mobile devices connected to the server is possible using the “Allow/Block/Quarantine” option. It’s a “pre-emptive” security feature, which means it activates at the initial connection to the server and is designed to guarantee that only authorised devices may complete synchronisation with the server. This enables a complete administrator to monitor all mobile devices in their network. At the moment, only CLI tools are available.
The global Boolean property abq_enabled_at_startup determines whether ABQ starts with the Zextras Suite. While the property is set to true by default, it is recommended that it be changed to false if it is not utilised to conserve server resources.
To disable the ABQ, use the following command before restarting mailboxd:
To confirm that ABQ was disabled, the result of zxsuite mobile getServices should show that it is not operating (i.e., the value for ABQ’s running property should be false).
Components
The ABQ feature is made up of three primary logical components:
- a List of Device Controls
- an Authentication Engine
- a collection of CLI utilities
When an administrator changes a device’s status in an ABQ-enabled environment, the device is forced to re-sync folders with the server, resulting in an immediate re-route to either a Dummy data that explains what happened to the user, or to the real mailbox to perform the re-sync.
Modes ABQ
Every mobile device that attempts to synchronise with the server triggers the ABQ function, which may be configured to one of four modes: “Permissive”, “Interactive”, “Strict”, or “Disabled”. This characteristic applies to the entire cluster.
Permissive
Because the Authorization Engine is not operational, the synchronisation will proceed after authenticating the user and validating their account status for safety. Specific devices can still be prohibited, but non-blocked devices will always be able to sync.
Interactive
The Device Control system will check the “Device ID” given by the device against the list of approved devices after authenticating the user and validating their account status for safety reasons:
The synchronisation will proceed if the device/user pair is in the “allowed” list.
- If the device/user couple is not in the device list but is in the “allowed” list, synchronisation will proceed.
- If the device/user couple is not in the device list but is in the “allowed” list, synchronisation will proceed.
- If the device is not in the “allowed” list, synchronisation will be halted, a dummy email informing the user of the device’s “Quarantine” status will be sent, and the connection will be put to “Quarantine” status.
Administrators can be alerted at predetermined intervals, and each notification email will only contain new Quarantined devices. They will then be able to use the relevant CLI tools to allow or prohibit synchronisation for each device.
Strict
The Device Control system will check the “Device ID” given by the device against the list of approved devices after authenticating the user and validating their account status for safety reasons:
- If the device/user pair or the device alone is on the “allowed” list, synchronisation will proceed.
- If the device is not in the “allowed” list, the synchronisation will be marked as “Blocked,” no data will be synchronised, and a bogus email informing the user of the device’s “Blocked” status will be sent.
Disabled
ABQ is turned off, no checks are run, and no policies are enforced.
Mode Control ABQ
The following command can be used to determine the current mode:
The following command can be used to modify the ABQ mode:
Dummy information
The function employs “dummy emails” and a “dummy mailbox” to hold devices while they wait for authorisation (Interactive Mode) or to warn them of their “Blocked” status (Permissive Mode, Interactive Mode, and Strict Mode).
The Dummy Mailbox is a virtual mailbox that only has a “Inbox” folder and is synchronised to the device when it is in Quarantine or Block state. Dummy Emails are prefabricated email messages that are synchronised to a device in Quarantine or Block status in order to notify the user. These messages are not now customisable, but will be in the future. When a device’s ABQ status is altered, the device’s sync state is reset.
This was developed to ensure that the user understands what is going on; otherwise, forcing the synchronisation to fail with no descriptive answer for the user would likely result in a considerable increase in support requests.
Personalised ABQ emails
The zxsuite mobile setABQMessage message command may be used to quarantine and block simulated emails; messages can be tailored at the global or domain level, and various languages can be set.
Administrators can be alerted about quarantined devices via email at a certain interval provided by the abqNotificationsInterval configuration parameter, which is given in milliseconds:
The following command may be used to determine the interval:
The interval can be adjusted by using the following command:
The abq Notifications Interval is set to 0 by default, which means that no notifications are sent.
Service Status in ABQ
The following command may be used to verify the ABQ service status:
The service may be terminated or started using the Mobile module’s default service control:
When the mode is set to Disabled, the ABQ service does not start automatically, but devices can always sync.
The ABQ CLI
The ABQ comes with its own set of CLI commands, which includes three Rule commands (deleteRule, listRules, and setRule). They use the same syntax as the delete, list, and set commands, with the exception that the Rule commands take regular expressions that must adhere to the Java regex patterns standard (ERE with doubled backslashes).
Allows a specified command to be issued to a quarantined device and changes the device status to Allowed.
block
A command for quarantined devices that changes the device status to Blocked.
remove and removeRule
Remove an item from all lists.
import
This command imports a list of device ids from a file and always requires two parameters: an Input File containing a list of Device IDs separated by a newline, and the “status” of the imported device(s).
Given the file /tmp/list and its contents, run the following command:
Devices androidc133785981 and androidc1024711770 can sync regardless of account, however device SAMSUNG1239862958 can only sync the user@example.com account.
list after listRules
List the ABQ status of all devices. The “status” input will narrow the list to only display devices in that state.
Output sample:
put up and set upRule
Change the state of any single device (known or unknown).
setNotificationInterval
Set the interval for receiving notifications about new quarantined devices.
Mobile CLI Zextras
The index of all zxsuite mobile commands may be found in this section. The whole reference may be found in the section ZxMobile CLI Commands.
ABQ allow ABQ block ABQ delete ABQ delete ABQ deleteABQ rule import ABQ list ABQ listABQ set rules ABQ set rulesNotificationset interval ABQRule addressBook add domain addressBook add global addressBook list domain addressBook list global addressBook remove domain addressBook remove global addressBook remove global addressBook remove domain addressBook remove global deleteABQMessage domain deleteABQMessage global doAddAccountLogger doAddEASFilter doDeleteEASFilter doMoveEASFilter doRemoveDevice doRemoveLogger doRestartService doResumeDeviceSync doSimulateSync doSuspendDeviceSync doStartService doStopService doWipeDevice domain duplicateABQMessage global getABQMessage domain global getABQMessage global getAccountLoggers obtainAllDevices obtainAllEASFilters obtainDeviceInfo obtainDeviceList obtainProperty obtainProvisioning getServices setABQMessage domain setABQMessage global setABQMessage initABQMessagesetProvisioning setSharedFolderSync property