The many settings that may be modified to provide access to Carbonio features via mobile devices are described in this section. You need console access to update the settings because they are presently only accessible through the CLI.
This section teaches the commands and frequently used sub-commands necessary for the administration of all mobile device features while describing the most frequent tasks.
For a COS, enable Carbonio Mobile Synchronisation.
To enable or disable the COS-level options, use the corresponding instructions. However, keep in mind that each user has the ability to override these settings.
Carbonio Mobile for a Single User to be Enabled
When you enable the Carbonio Mobile Module for a single user, you give that person permission to utilise all of the module’s mobile features.
Disable Sync for a Device and an Account
In some circumstances, it may be beneficial to prevent some of a user’s devices from syncing with the server. In certain circumstances, the following command can be used:
In this case, id is the device’s unique identification and account-uuid is the UUID of the user account to which the device belongs.
Use the command to get synchronisation back.
Only that device’s synchronisation will continue if you supply the device_id id; else, all user’s devices will have their synchronisation restarted.
The feature for mobile passwords
Global and Delegated Admins can configure an extra password for an account to be used only for Exchange ActiveSync authentications using the mobile password feature.
Using this feature has the following key advantages:
- Regardless of any other password policies, compel set-and-forget secure passwords. In this approach, it won’t be necessary to reset the password kept on all mobile devices synchronised with an account in the event that the account password changes.
- Do not reveal the true password if the device or client has been accessed without authorization.
Both the account password and the mobile password will not be accepted for Webmail, POP3, IMAP, or SMTP logins.
How to Create a Mobile Mailbox Password
Please refer to the section Create New Credentials: Mobile Apps for additional details on how the Carbonio Auth module handles mobile passwords.
Carbonio Mobile and SyncStates are two examples.
A collection of data concerning the synchronisation with a mobile device is retained on the server and is known as the SyncState (short for Synchronisation Status). Each time a device connects to Carbonio Mobile, the following processes happen:
- To synchronise the local Folders with those on the server, the device requests a folderSync operation.
- One SyncKey is transmitted for each local folder, but if this is the device’s initial connection to the server, it sends a single SyncKey set to 0.
- In response, the server provides a list of accessible directories.
- The server sends one SyncKey per folder.
- To synchronise all outstanding items, the device requests an itemSync operation.
- The synchronised objects are kept on the server in the SyncState.
- The device sends a ping to maintain the connection following the itemSync action.
- As long as the synced account is unchanged, step 4 is repeated.
The device terminates the current connection (the one kept alive by the ping command) every time a new item is added to the mailbox or an existing item is updated. This process is repeated steps 3 and 4 each time.
The itemIDs saved in step 3 and the SyncKeys saved in step 2 are combined to form the SyncState. According to the userID/deviceID unique pair, the server saves it.
Request for Sync
The actual synchronisation procedure, called a Sync Request, is begun either by Carbonio Mobile or by the client. Any changes made to the mailbox since the last request are synced to the device during a sync request, and vice versa.
When: A sync request is sent.
- SyncState modifications
- Client-side force synchronisation
- The device sends a fresh ping when the existing one expires (the client specifies the keepalive duration).
Taking care of the SyncStates
Use any of the CLI commands listed below to manage the SyncStates of synced mobile devices:
DoS filter for Carbonio mobile’s advanced settings
A specific DoS Filter component is part of Carbonio Mobile, which boosts security and stability. When a device consistently connects at a rate higher than the selected limit, the filter will engage and “jail” the device for a certain amount of time, blocking any connections from it.
By restricting clients who are making too many requests owing to defects or malfunctions, this increases stability and security by preventing Denial of Service attacks and freeing up resources for all other customers.
Configuration
The Carbonio CLI command carbonio config global set|get|clear may be used to fully configure the Mobile DoS Filter at the global level. The carbonio config info attribute [name], where [name] is one of the following, may be used to access specific information for each property:
- mobileAntiDosServiceThe Mobile DoS Filter service is now enabled. standard false;
- MobileAntiDosServiceJailDuration: The length of the synchronisation “jail” in milliseconds. Standard 600000;
- Time window used by mobileAntiDosService to compute the connection ratio. If a device submits additional mobileAntiDosServiceMaxRequests requests during this time interval, the prison is activated. Standard 30000 ms;
- Maximum requests received during mobileAntiDosServiceTimeWindow milliseconds are specified by mobileAntiDosServiceMaxRequests. Standard 150;
Using the Mobile DoS Filter
The system retains the timestamp of the most recent mobileAntiDosMaxRequests requests in memory while the anti-dos service is active and mobileAntiDosMaxRequests is higher than 0. All new requests from this device/account are rejected for mobileAntiDosJailDuration milliseconds if the maximum number of request timestamps have been saved and all of the stored requests are within the time window.
A warning is added to server alerts and an email is sent to the administrator when the rate has been exceeded.
Mobile Performance Tuning for Carbonio
To fine-tune Carbonio Mobile in accordance with system performance, Carbonio Mobile offers three helpful choices.
The carbonio config command may be used to change any option via the CLI.
When Should Performance Tuning Settings Be Edited?
For most instances, the default settings ought to be ideal. However, if you encounter any of the issues listed below, please use the recommended fix.
Filters for EAS
The protocol version used for synchronisation in the EAS protocol is set at the initial handshake and is never altered. The client selects a protocol version from a list of all accessible versions presented by the server.
To guarantee that the correct version is utilised, EAS filters can be used to restrict the EAS version that is accessible to a certain group of users or clients.
The getAllEASFilters and doMoveEASFilter commands are described in the section below titled “Managing EAS Filters.” Multiple EAS filters may be configured and will be examined in a sequential manner.
A description of an EAS filter
There are 5 components to an EAS filter:
The kind of the filter rule is defined by type.
Parameter
the filtering identity, such as an email address or a brand of equipment.
Mode
determines whether the programme will present a fixed list or limit the versions that are accessible.
field easversions
contains the protocol versions that the filter has enforced.
Whether further filters are used after the present one has successfully matched is determined by the blocking Boolean value.
Managing EAS Filters
The four specific commands listed below are used to manage EAS filters using the CLI.
Loggers for mobile accounts
A user’s full EAS logs can be produced into a specialised logfile by mobile account loggers, which have a different verbosity than the sync.log file. This makes troubleshooting possible more quickly.
The following conditions must be followed while establishing an account logger:
- The intended customer
- The verbosity of the log, or log_level
- The specific log_file
- While the logger is active, the window_size that will be enforced across all devices synchronising with the account
Account Logger Management The following commands are the only ones that may be used to manage account loggers through the CLI:Device control with Allow/Block/Quarantine (ABQ)
Mobile devices connected to the server can have their access controlled specifically using the “Allow/Block/Quarantine” option. As a “pre-emptive” security measure, it responds to the first connection to the server and is designed to make sure that only authorised devices may complete synchronisation with the server. A complete administrator is now able to monitor every mobile device connected to their network. Only CLI tools are available for now.
If ABQ will start alongside Carbonio at startup is determined by the global Boolean parameter abq_enabled_at_startup. Although the property is set to true by default, it is advised to change it to false if it isn’t being utilised to conserve server resources.
Run the following command, then restart mailboxd, to disable the ABQ:
The result of carbonio mobile getServices should show ABQ as not operating (i.e., the value for ABQ’s running property should be false) to confirm that ABQ was deactivated.
Components
There are three basic logical parts that make up the ABQ feature:
- Unified Device Control List
- authorising engine
- the CLI toolset
In an ABQ-enabled environment, whenever an administrator changes a device’s status, the device will be forced to re-sync folders with the server depending on the issued state, causing an immediate re-route to either a Dummy Data that will explain what has happened to the user, or to the real mailbox to perform the re-sync.
Modes AB
Every time a mobile device tries to synchronise with the server, the ABQ function is activated. It may be configured to one of four potential modes: “Permissive,” “Interactive,” “Strict,” or “Disabled.” This characteristic applies to every cluster and is global.
Mode Control for ABQ
The following command should be used to check the mode:
The following command can be used to switch the ABQ mode:
Dummy Data is a feature that uses fake emails and a fake mailbox to block devices in permissive, interactive, and strict modes or to put them on hold while waiting for authorization (Interactive Mode).
Dummy Emails are predetermined email messages that are synced to a device in Quarantine or Block state to inform the user, whilst the Dummy Mailbox is a virtual mailbox consisting solely of an Inbox folder that will be synchronised to the device when this is in either Quarantine or Block status. The sync state of a device is reset each time its ABQ status is altered.
Dummy data have been included to ensure that the user is aware of what is occurring because the alternative would be to force the synchronisation to fail without providing the user with a descriptive answer, which would likely result in a major increase in support calls.
With the carbonio mobile setABQMessage message command, simulated emails may be quarantined and blocked. Messages can be tailored at the global or domain level, and several languages can be set.
Notifications
Email notifications about quarantined devices can be sent to administrators at predetermined intervals determined by the abqNotificationsInterval configuration property, which is represented in milliseconds:
The following command may be used to check the interval:
The following command can be used to modify the interval:
The abqNotificationsInterval is typically set to 0, which means that no notifications will be sent.
Service Status for ABQ
The following command may be used to verify the status of the ABQ service:
Using the Mobile module’s default service control, the service may be started or stopped:
Devices are always permitted to sync when mode is Disabled since the ABQ service is not launched automatically.
ABN QCL
Three Rule commands (deleteRule, listRules, and setRule) are part of the ABQ’s own set of CLI commands. With the exception of accepting regular expressions that adhere to the Java regex patterns standard (ERE with doubled backslashes), they have the same syntax as their equivalent delete, list, and set commands.
allow A particular command for a device in quarantine that changes the device’s status to Allowed.
block
A particular command for quarantined devices that changes the status of the device to Blocked.
Delete everything.Rule
Add or remove a device from each list.
import
This command imports a list of device IDs from a file and always needs two inputs: the “status” that the imported device(s) should be set to and an input file containing a list of device IDs separated by newlines.
Given the content of the file /tmp/list:
# import /tmp/list from carbonio mobile abq Devices Androidc133785981 and Androidc1024711770 can synchronise with any account thanks to the feature called “Allowed,” however device SAMSUNG1239862958 can only synchronise the user@example.com account.
the two listsRules
List the ABQ status of all devices. Only devices with that particular state will be displayed in the list thanks to the “status” argument’s filtering.
Typical output is set and set.Rule
For each single device (known or unknown), set any status.
setNotificationInterval
Set the time between notifications for newly quarantined devices.
The Contact Book Service
This function, which is a component of the Mobile module, offers an LDAP Address Book to which Outlook clients may connect in order to access the GAL of the system, the user’s personal address books, and other address books specified by the Administrator.
As the point of connection for the Outlook clients, this service serves as the foundation of the LDAP Address Book functionality.
All mailbox services’ exposed port 8636 is used by the service, which employs the SSL encryption protocol.
In order to increase system security, this endpoint is read-only.
Using LDAP to access the address book
Only Outlook clients may access the LDAP Address Book using the same login information used for the Exchange ActiveSync connection (email address and either their password or a specific Mobile Password).
Customers can use the service by dialling the mailbox server that hosts their mailbox’s port 8636.
Another alternative would be to create unique firewall rules, as described in the technique below, to route port 8636 from the proxy to the AppServer. This procedure necessitates editing a few system files and assuming the mailbox server is situated at the local IP 10.129.67.1.
- Switch on IPv4 IP forwarding
- Add the following firewall rules to your proxy’s iptables script:
Address and Contact Books
The LDAP Address book gives users access to the following things by default:
- contacts and address books that belong to the user.
- The GAL of the user.
The LDAP Address Book does not display the address books of other users, including shared address books.
List every Address Book that is now visible in the LDAP Address Book.
multiple Address Books: Using the carbonio mobile addressBook subcommands, an administrator can control multiple Address Books at the domain and global levels.
List every Address Book that is now visible in the LDAP Address Book.
Update the LDAP Address Book with a fresh Address Book.
Delete a contact book from the LDAP contact book
The address book will be available to either Global or Domain users depending on the value of the first argument of the add and delete sub-command.
Both sub-commands also need the FolderID of the address book that is being added and the email address or UUID of the address book owner.
Examples
This command adds the user@example.com user’s folder 7 (the default /Contacts folder) to the LDAP Address Book of every user in the system.
This command adds the user@example.com user’s folder 7 (the default /Contacts folder) to the LDAP Address Book of every user in the example.com domain.
Outlook’s LDAP Search will reveal additional Address Books by separating the owner’s reveal Name and the Address Book name with a slash, for example, “John Doe/EMEA Distributors”.
Setup for Outlook
Simply follow these procedures to access the LDAP Address Book from Outlook:
- Go to the Address Books tab in the Account Settings section and click Add.
- Press Next after selecting Internet Directory Service (LDAP).
- after entering the mailbox server’s direct URL, select the Check the “This server requires me to log in” box, then enter your email address and password (or current mobile password, if applicable).
- Choose “More Settings”
- The Use Secure Socket Layer option should be selected after entering the server’s URL as the Display Name and port 8636 in the Connection tab.
- Leave the input box empty and choose Custom as the search basis in the Search tab.
- To finish the procedure, click Ok to exit the More Options window and Next to open the Add Account window.
Contact Book Naming
Own Address Books in Outlook that are accessed over LDAP are titled with a slash character before the name of the folder, for example, “/Contacts”.
The name of the datasource is also included in GAL entries and Address Books, for example, “InternalGAL/_zextras”.
The folder name, such as “John Doe/EMEA Partners,” and the owner’s Display Name are included in other users’ Address Books.