Close menu

The feature for mobile passwords

The feature for mobile passwords

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).
Managing of the SyncStates
Use any of the CLI commands listed below to manage the SyncStates of synced mobile devices:

The doRemoveDevice command

Syntax:

carbonio mobile doRemoveDevice {account} {device_id}

Usage example:

carbonio mobile doRemoveDevice john@example.com Appl79032X2WA4S

Removes John’s Appl79032X2WA4S device SyncState

The doResetDevice command

Syntax:

carbonio mobile doResetDevice {account} [attr1 value1 [attr2 value2...

Usage example:

carbonio mobile doResetDevice john@example.com Appl79032X2WA4S

Resets John’s Appl79032X2WA4S device SyncState

The doResetAccount command

Syntax:

carbonio mobile doResetAccount {account}

Usage example:

carbonio mobile doResetAccount john@example.com

Resets all the device states for John’s account