Isode Products

Directory Products

M-Vault in Depth

Directory Management

Directory Evaluations

Isode Directory ProductsM-Vault Server Management tools can be split into four categories:

  • Directory Configuration Management
  • Directory Operational Management
  • Directory Data Access & Management
  • Directory Synchronization

This page looks at Sodium-Sync, a capability provided as part of Sodium, one of Isode's Data Access and Management tools.

You can find information on Configuration Management (Enterprise Directory Management), Operational Management (DConsole, SNMP monitoring, Audit, Event and Fault Logging) and Data Access & Management (Sodium and the web-based Directory Services Interface).

 

Sodium-Sync

Sodium Sync is a capability provided as a part of Sodium to synchronize data from one directory server to another using LDAP or X.500 DAP.

Key features of Sodium Sync:

  • Synchronization is very easy to set up.
  • A single GUI can be used to access both directory servers and managing synchronization.
  • 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.

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. 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.

Sodum 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 current version 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 will any LDAP or DAP directory. Incremental updates will be added in a future release.

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.

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 supports use of LDIF (LDAP 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.

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:

  1. Tree depth, so that entries below a specified level in the directory information tree (DIT) are not synchronized.
  2. "Chop", which can exclude a specified part of the DIT, either with or without the specified entry as illustrated above.
  3. 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>    
  <ruleset name="ad-mappings" label="Laser Active Directory to M-Vault standard mappings">
 
  <rule keyclass="person">
 
  <move from="wWWHomePage" attr="labeledURI" match="^http://"/>
<move from="wWWHomePage" attr="labeledURI" match="^https://"/>
<move from="wWWHomePage" attr="labeledURI" subst="s|^(.+)|http://$1|"/>
<move from="othertelephone" attr="telephonenumber"/>
<move from="otherhomephone" attr="homephone"/>
<move from="othermobile" attr="mobile"/>
<move from="otherpager" attr="pager"/>
<move from="otherfacsimiletelephonenumber" attr="facsimiletelephonenumber"/>
<copy from="mail" attr="mailLocalAddress"/>
<build_postal_address from="street postOfficeBox l st postalcode c" attr="postalAddress"/>
<map attr="street" subst="s/ *\r?\n */, /gs"/>
<set_missing attr="mailHost" value="exchange.isode.net"/>
<add attr="objectClass" value="inetorgPerson"/>
<add attr="objectClass" value="mboxUser"/>
<conform strip="true" insert="true"/>
</rule>
<rule>
  <conform strip="true" insert="true"/>
</rule>
</ruleset>

This XML language provides a flexible mechanism for mapping information, that includes selection and transformation of attribute values using regular expressions.

Evaluations

Sodium & Sodium-Sync are bundled as part of our M-Vault Directory Server and can be evaluated as part of our M-Vault Evaluation package.

 
Copyright © 2008 Isode privacy   feedback Subscribe to our rss newsfeed