Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.
Sodium Sync allows the synchronization of data from one directory server to another using LDAP, X.500 DAP or LDIF files.
Key features of Sodium Sync:
- Synchronization is very easy to set up.
- Sodium Sync binds to two directory servers
- Data for each synchronization flows in one direction
- Multiple synchronizations can be supported by a single Sodium Sync
- A single GUI can be used to access both directory servers and managing synchronization.
- Scheduled replication handled by a background service
- Simple profiles for common synchronization types.
- Robust high performance operation.
- Filtering and data mapping functionality for advanced synchronization.
- Streamed implementation enables efficient synchronization of large directory information trees.
- Scheduling synchronizations handled by a background process,
- Monitoring of scheduled synchronizations.
- Flexible LDIF support.
- Strong authentication and Signed operations over X.500 DAP
- Strong authentication and TLS with LDAP
Target Deployment
Sodium Sync can be used to synchronize data between any pair of directories. A key target for Sodium Sync is synchronization of data from Microsoft Active Directory to Isode's M-Vault. Sodium sync will also synchronize data from M-Vault to Active Directory and with most LDAP servers. A typical scenario is where local data (e.g., users, certificates and CRLs) from Active Directory is synchronized to M-Vault that acts as part of a distributed directory deployment. This will often be used with high security deployments of M-Vault that require use of digital signatures on all update operations.
When replicating data between two M-Vault servers, it will generally make sense to replicate data using X.500 DISP. A discussion of approaches to replication and synchronization, with consideration of the best approach to use is given in the Isode white paper Replicating and Synchronizing Data Between Directory Servers.
Simple Use of Sodium Sync
For many deployments, setup of Sodium Sync is very straightforward. This product overview shows simple deployment first, and subsequently looks at advanced features.
Configure Bind Profiles for Both Directories
A pre-requisite to setting up synchronization is to establish a bind profile from Sodium to each of the directories being synchronized. Sodium can then be used to easily locate the parts of each directory that will be replicated. The screenshot below shows a Sodium connection to Active Directory.
Choose Synchronization Type
When creating a new Synchronization, Sodium Sync offers the choice of some standard synchronization profile types:
The current release of Sodium Sync provides profiles for synchronization from Active Directory to M-Vault, and for synchronizing M-Vault to M-Vault. It is likely that further profiles will be added to support additional scenarios. Once created, the two simple profiles give a simple view. This has a graphic to illustrate the full synchronization, and two tabs that need to have data completed.
Set Source and Target
The source and target for synchronization must be set. This is done by selecting a Sodium bind profile for source and target, and specifying the directory name used for source and target, which may be different:
Define Scheduling
Synchronization profiles may be run manually. This is a sensible approach for testing and for some deployments. For automatic operation, a schedule must be specified, either as an interval between synchronizations, or the time for a daily synchronization. When the first schedule is set up, the Windows service or Unix process to run the synchronizations must also be configured.
Operational Management of Synchronization
When unscheduled tasks are run from the Sodium GUI, status and errors are shown interactively. Sodium Sync manager, shown above can be run at any time to check on the status of synchronizations. This screen shows defined tasks, when they are next scheduled to run, and notes any errors on the last run. When there are problems, this screen can be used as an entry point to diagnose problems and to access error logs.
Any errors are also logged as Isode events. These events can be monitored using any of the approaches available as a part of the Isode event system described here. In particular, events may be:
- Viewed with Isode's Event Viewer.
- Monitored using SNMP, with TRAPs providing information on new events.
Performance and Scaling
The basic operational mode of Sodium Sync does a "full update" on each run. This works by reading data from both directories, and then applying any necessary changes to the target directory. This is robust, straightforward, and works with any LDAP or DAP directory.
Sodium Sync works by streaming data, and minimizes the amount of data it holds at any time. This enables it to scale to synchronize very large directory information trees. Paged results may be used.
On a small system, with fast directory servers, typical performance for Sodium Sync is around 40 entries per second (2.000 entries per minute). This makes it practical to synchronize a few thousand entries with updates at short intervals, and up to a few hundred thousand entries on a daily schedule.
LDIF Support
Sodium Sync supports use of LDIF (LDAP Data Interchange Format) in various ways, including:
- Loading by Synchronization from LDIF. Where a full directory load is needed at intervals, LDIF can be generated and Sodium Sync will determine changes relative to the live directory and then make modifications. This approach is often preferable to "delete and replace", and also enables additional attributes to be added to the live directory.
- Output synchronization changes to LDIF.
- Apply changes from change LDIF
- Compare two LDIFs to generate a change LDIF
- Compare two directory sub-trees and generate a delta as LDIF. This can be useful for comparing two similar directories.
Synchronization by Email and 'Air Gap'
Sodium Sync provides capabilities to generate LDIF changes relative to an automatically stored reference copy. This enables Sodium Sync to generate a sequence of change LDIFs, and for another copy of Sodium Sync to robustly apply them, checking for duplicates, missing updates and out of order changes. It can also drive 'transport' programs before or after it runs. This provides capability to replicate between directory servers using email, or to provide directory replication across an 'air gap' gateway.
More information on synchronization by email and scenarios that require it are given in the white paper Directory Replication by Email and over 'Air Gap'. Information on using this capability with M-Switch is given in the whitepaper File Transfer by Email.
Advanced Synchronization
For many deployments, the simple synchronization setup of Sodium Sync will do everything needed. Sodium Sync has a range of advanced capabilities to deal with more complex synchronization. The advanced screen, with more complex data flow (that is drawn according to the options selected) is shown below:
The rest of this section summarizes the advanced features of Sodium Sync.
Entry Selection
Entries can be selected from the Source directory, to constrain what is synchronized. There are three basic controls:
- Tree depth, so that entries below a specified level in the directory information tree (DIT) are not synchronized.
- "Chop", which can exclude a specified part of the DIT, either with or without the specified entry as illustrated above.
- Use of an LDAP or DAP filter, using the LDAP string filter representation
as defined in RFC 4515. This is a flexible selection mechanism, illustrated
below, that can be used for a number of purposes, including:
- Constraining the selection to a specific set of object classes.
- Excluding certain object classes.
- Selection of entries based on the presence or value of a specific attribute, which might be "EmployeeType=Staff" or "Publish.To=External".
- Selection based on membership of a group.
Attribute Filtering
Attributes can be filtered by use of one or more attribute filtering rules. Rules may apply to specific object classes or to all entries, and are applied in a priority order. So a filter can be specified for objects of class inetOrgPerson which will take priority of a generic filter for objects of class Person (a super-class of inetOrgPerson). Filters can be inclusive (synchronize the attributes specified) or exclusive (synchronize all attributes except those specified). Sodium knows about a very large number of attributes, and so a number of mechanisms are provided to facilitate editing filters. The screenshot below shows editing a filter for object class Person, and attributes selected are those which belong to object class Person and all subclasses.
Attribute Mapping
Sodium Sync provides a number of standard mechanisms to map attributes that may be selected and shown above. These are:
- Relocate DN. Many attributes have values that are directory names. Sodium Sync can map a subtree from one DIT location to another. This option maps the Directory Name valued attributes in the same way, so they are valid on both sides of the synchronization.
- Active Directory. Active Directory uses some attributes in a way that is not conformant to standard LDAP and X.500 usage. This mapping changes these attributes from Active Directory to standard usage.
- Schema stripping. Sodium Sync is configured with schema knowledge that may be extended. This option removes attributes and object class values that are not known to Sodium. This is often convenient when synchronizing to M-Vault, as Sodium Sync will generally have the same schema configuration as the associated M-Vault. This stripping will remove schema that M-Vault does not know about, and so enable the data to be written to M-Vault.
- Schema inserting. Some LDAP sources such as Active Directory may omit attributes that are mandatory in the schema used. This mapping inserts dummy values so that the data sent to the target directory is schema conformant.
- Change RDN. Sodium can be used to change the RDN of an entry to that of an attribute contained within the entry being synchronized.
- Tree flattening. Sodium Sync can be configured to remove intermediate naming levels.
These mappings are built using a general purpose underlying mechanism. Isode’s goal with Sodium Sync is to provide a useful set of mappings that may be simply selected. It is likely that new mappings will be added in future releases.
The underlying mapping mechanism is documented and available to Sodium Sync users. The screenshot below shows Sodium Sync with two custom mappings added.
The custom mapping are defined in XML, and appear in the GUI when they are defined. The specification of one of the custom mappings is illustrated below.
| <!-- Mapping rule-sets used by Sodium Sync --> | ||||||||||||||||||||||
| <mapping> | ||||||||||||||||||||||
|
||||||||||||||||||||||
This XML language provides a flexible mechanism for mapping information, that includes selection and transformation of attribute values using regular expressions.
