M-Vault

M-Vault provides a unique set of security features, including Strong Authentication based on X.509 PKI, Signed Operations, OAuth 2.0, Flexible Prescriptive and Role Based Access Control, Security Policy, Rule Based Access Control based on Security Labels, Audit Logging and Password Policy. More information on M-Vault Security.

M-Vault’s architecture allows for very high performance for read, search and modification functions, combined with a high level of scalability to directories containing tens of millions of entries. M-Vault’s high performance multi-protocol, multi-threaded architecture is scalable to multi-processor platforms and can be easily extended to support additional protocols. SMP (Symmetric Multiprocessing) is supported to exploit the power of multiprocessing systems. More on M-Vault Scalability and Performance.

Data can be distributed across servers using X.500 DSP (Directory System Protocol). Enterprise LDAP servers can also be connected into a distributed directory using M-Vault’s support for LDAP chaining. Data can be replicated between servers using X.500 DISP (Directory Information Shadowing Protocol) and/or Isode’s multi-master replication. Server to server communication (DSP Chaining and DISP Replication) are secured using X.509 based strong authentication. More on M-Vault Replication & Data Distribution.

M-Vault uses an underlying high-end database transaction subsystem, which provides assurance that hardware, operating system or application failures will not corrupt a directory server database. This transaction support also enables on-line backup procedures for disaster recovery. M-Vault provides fail-over clustering and off site disaster recovery using either a SAN approach or one or more independent failover servers as well as multi-master replication. More on M-Vault Reliability & Fault Tolerance.

ACP 133 (Allied Communication Protocol 133: Common Directory Services and Procedures) is the NATO Standard for Military Directory. ACP 133 is based on the ISO/ITU X.500 Directory Standard, and makes use of X.500 protocols for replication and directory management. LDAP, the Internet Standard Lightweight Directory Access Protocol is also based on X.500, and is generally the preferred protocol for military clients and military applications to read data from an ACP 133 directory.

M-Vault is fully compliant with ACP 133 and can therefore be used in support of ACP127 and STANAG 4406 messaging (including use with M-Switch MIXER as an ACP145 Gateway). For more information on M-Vault in this environment, see the Military Directory market page.

All M-Vault configuration information, including database and replication configuration is held as directory information in a distinct and specific naming context. This makes configuration changes and configuration viewing straightforward with standard LDAP tools as well as Isode management GUIs.

An M-Vault server is named in this configuration, and so changing the name of a server is straightforward.

Master and shadow data do not have special storage, so conversion from shadow to master is easy (just remove the supplier agreement).

Default access control is stored, which makes it straightforward to add new naming contexts with consistent access control.

M-Vault provides a range of authentication mechanisms for different types of deployment:

• Strong Authentication using digitals signatures provides highest security.
• Password based authentication, which can use SASL and a variety of underlying mechanisms.
• Kerberos and Single Sign On (SSO).Strong Authentication

Strong authentication based on X.509 PKI using Isode’s strong authentication infrastructure is provided for all X.500 protocols (DAP, DSP, and DISP). and for LDAP using SASL-EXTERNAL.

Strong authentication is desirable for secure directory deployments, and should be used in preference to password based authentication.

M-Vault incorporates an OAuth service, enabling applications to authenticate and authorize using OAuth 2.0, particularly to support Isode applcations using OAuth. M-Vault provides two means of authentication

1. Password based authentication, using M-Vault password checking mechanisms.
2. Windows Single Sign On (SSO) using Kerberos based authentication with Active Directory.

Authorisation is managed in M-Vault using Cobalt

Further information provided in the [Isode OAuth] whitepaper

M-Vault provides Kerberos authentication using an external Kerberos KDC, such as the one provided by Microsoft Active Directory. This enables Single Sign On (SSO). Information is given in the whitepaper [Isode Support for Kerberos, Active Directory & Single Sign On].

M-Vault supports the SASL (Simple Authentication and Security Layer) Internet standards for LDAP client authentication, enabling a wide range of password based authentication mechanisms. The Isode SASL implementation supports a number of authentication mechanisms, given authentication flexibility. SASL also enables authentication using simple string names (as opposed to directory names), which is convenient for applications using directory based authentication. A full description of SASL and its use in M-Vault can be found here.

Salted Challenge Response Authentication Mechanism (SCRAM) is a new SASL based password mechanism that Isode recommends, as it provides both good protocol security and avoids the need to store plain passwords in the directory. SCRAM is described in [SCRAM: A New Protocol for Password Authentication].

M-Vault supports an LDAP passthrough mechanism where it holds data for an entry but performs authentication against another LDAP directory. This is particularly useful for authenticating against Microsoft Active Directory and using M-Vault to hold additional information relating to the entry.

Cobalt provides flexible management of LDAP passthrough entries.

When passwords based authentication is used, management is important. M-Vault provides comprehensive capabilities for managing password based authentication. This includes:

• Control of hashing choice, and auto-migration on authentication
• Ability to lock accounts
• Password quality control
• Password ageing
• Password history (controlled by age)
• Force password reset
• Grace login
• Require old password
• DSA generated password
• Prevention of password guessing attacks
• Ability to exclude
• Protocol support for password policy aware clients
• GUI management of password policy using Sodium (see here for screenshots)
• Password policy support in Isode Directory Client APIs
• Password policy aware changing in Isode Web Applications – PIA (Personal Information Administration)
• Password idling (disable if not used after a period)
• Password start/end time

Further details are given in the Isode whitepaper [Password Policy for Directories].

M-Vault provides flexible access control of data held in the directory, based on the identity of the user accessing the directory, following the X.500 standards.

Support is provided for the full range of X.500 Access Control, covering both Basic Access Control (BAC) and Simplified Access Control (SAC). Features include access control applied to a specific directory entry, all entries within an administrative area, and a group of entries. In addition, access control can be defined per attribute (e.g., deny access to the password attribute for all entries). This identity based access control support includes support for roles, sometimes referred to as Role Based Access Control.

M-Vault supports access control based on Security Labels and Security Clearances, using mechanisms of the type specified in X.500 as Rule Based Access Control. M-Vault allows Security Labels to be associated with directory entries, which then controls access based on the Security Clearance of the user. Detailed capabilities:

• All functionality is Security Policy controlled. Isode provides capabilities for Security Policy Management.
• Replication controlled by Security Policy can be achieved by use of Sodium Sync, and a login account with appropriate Security Clearance.
• M-Vault can restrict access based on user’s Security Clearance, using a Security Label associated with the M-Vault server.
• M-Vault can constrain the Security Labels on data held, by use of a Security Clearance associated with the M-Vault server.

Further information is provided in the product page covering Isode’s Security Policy Infrastructure as well as the following whitepaper-

• Security Labels: [Access Control using Security Labels & Security Clearance]

M-Vault provides audit logging of directory activity, in a structured parse-able format. Details can be found on the Isode product page covering Audit Logging & Event Handling.

LDAP confidentiality is supported in M-Vault using TLS/SSL protocols. The server supports the Start TLS extended operation of LDAP and LDAPS. The set of cipher suites available is configurable, as is the effective authentication level for a user depending upon whether a suitably confidential cipher suite was negotiated. TLS support is described here.

M-Vault also provides TLS support for the X.500 DAP, DSP and DISP protocols, enabling data confidentiality between servers.

M-Vault uses digital signatures based on X.509 PKI to support signed operations in the DAP and DSP protocols. This provides additional integrity and audit security for individual operations and allows chained updates to be authenticated using a digital signature from the originating directory client.

M-Vault can be configured to require signed operations for all updates, which is recommended for directory deployments with stringent security requirements.

Signed operations are also used for the X.500 DISP replication protocol, providing the same per operation security as for DAP and DSP.

Directory replication is important to achieve performance and resilience of read and search operations. A key benefit of M-Vault is the ability to replicate data. X.500 DISP (Directory Information Shadowing Protocol) provides flexible replication with the following features:

• Total and incremental replication.
• Initiation by consumer or supplier.
• Attribute filtering.
• On demand replication, or timed scheduling options.
• Operator requested connections.
• Automatic recovery from inconsistencies.
• Control of data to be shadowed.
• Secondary shadowing, so that data may be replicated over multiple hops.

M-Vault provides easy to set up replication using DISP, with flexible control of the replication options.

M-Vault provides high performance chaining to multiple shadow servers. M-Vault will maintain open connections to peer servers and will replicate to multiple servers at the same time. This means that replication will generally happen in a few hundred milliseconds, giving quasi-real time update of shadow servers.

M-Vault supports a reliable multi-master approach described in detail in the [ACID Multi-Master Replication in M-Vault Directory] whitepaper. Each server configured for multi-master is connected to every other server and changes made are applied to all servers. This enables updates to be made at multiple locations and continued updates in the event of a server failing. M-Vault Console provides a view to enable monitoring of multi-master configuration, as well as configuration of multi-master setups. More information on multi-master can be found on the M-Vault Reliability page.

Secondary shadowing is a mechanism to enable directory data to be replicated to large numbers of servers using X.500 DISP. Secondary shadowing is traditionally done from a shadow directory, to give multi-stage replication; the name refers to shadowing being done from a shadow (replica) directory rather than from the master. Secondary shadowing can be done from a multi-master configuration to enable shadow directory servers that do not participate in the multi-master configuration. Here secondary shadowing may be done from either a mutlti-master server or from a shadow server.

In order to support replication of data with directory servers that do not support X.500 DISP, Isode’s Sodium Sync product should be used.

The real power of an X.500 directory is the ability of the servers (Directory System Agents, or DSAs) to perform distributed operations on behalf of client applications. Distributed operations are handled by the Directory System Protocol (DSP), as defined in X.518 and X.519. DSP enables a set of DSAs to appear as a single, coherent directory service, but leverage the benefits of distribution of information with a single client/server connection.

The configuration of the directory is controlled by knowledge information, which is the mechanism that enables the location of data in the various DSAs to be represented in the directory. The X.500 specifications define a range of knowledge features that enable a distributed directory. The M-Vault directory server provides support for subordinate references and cross-references. In addition, the server is capable of dynamically learning about other servers and automatically constructing knowledge references to those servers. This functionality is core to the operation of an X.500 based directory.

M-Vault also has the unique ability to include LDAP only servers in the distributed directory using LDAP chaining.

Using DSP one server can access information held in another via the network. A real world example of this could be where different departments manage and administer their own data in a local M-Vault server. When a user in one department queries their server for data in another department, M-Vault will use its knowledge to access the appropriate remote server to satisfy the query.

Where departments implement an LDAP only server M-Vault can be used to connect these to a X.500 distributed directory. It does this by converting X.500 requests to LDAP requests (and vice versa) as necessary. Clients of the LDAP only server access the wider directory by following a referral to an M-Vault server from the LDAP directory. Similarly, clients of servers in the wider directory can access data in LDAP only servers as M-Vault can convert any incoming X.500 to an LDAP request and then pass that request along.

Data can be replicated using X.500 DISP (Directory Information Shadowing Protocol) and/or multi-master replication. This enables the various servers in a distributed directory to hold local copies of data held elsewhere. This ensures that data is available if one server in the network goes down, and is key to achieving very high availability for read and search operations.

Key features include:

• Total and incremental updates.
• Primary and secondary shadowing.
• Supplier and consumer initiated shadowing.
• Authentication of supplier and consumer.
• Scheduled and on-change updates.
• Flexible replication configuration.

When a set of M-Vault servers are deployed in a multi-master configuration they are fully (mesh) interconnected. Directory writes may be applied to any server in the multi-master configuration, as there is no single master. A key benefit of multi-master is that write operations can continue in the event of single server failure without operator intervention.

M-Vault multi-master capabilities are described further in the [ACID Multi-Master Replication in M-Vault Directory] whitepaper.

M-Vault can be deployed in a single master architecture, which is a good approach for many directory deployments and can make exclusive use of X.500 DISP replication. High availability for search and read can be provided by directory replication.

M-Vault supports fail-over clustering which provides high reliability for the master server by enabling use of two servers with a shared RAID disk. This gives resilience for both disk and server failure. Isode recommends the use of dual-ported disks for best master performance.

Clustering can be deployed over a SAN to give Off Site Hot Standby (Disaster Recovery). This requires a fast network link, so is usually constrained to relatively short distances.

In order to provide for flexible disaster recovery, M-Vault enables the configuration of one or more mirror servers, which are exact clones of the master server. In normal operation, these servers operates as standard shadow servers, providing high read availability.

In the event of master failure, one of the mirror servers will be promoted to act as the master. This gives a flexible disaster recovery approach, which can work over long distance. Further information is given in the white paper [M-Vault Failover and Disaster Recovery].

Some directory applications need to make multiple changes to the directory as a single transaction, to ensure consistency of information held in multiple directory entries. M-Vault enables this using RFC 5805 “Lightweight Directory Access Protocol (LDAP) Transactions”. This allows a series of (related) LDAP operations to be applied as a single transaction. This is of particular benefit to management applications that modify related directory properties.

Sodium (Secure Open Data, Identiy and User Manager) is used to securely manage the data and secure identities held in M-Vault. It provides information managers and system administrators with an easy to use Graphical User Interface. Although it is part of the M-Vault product set, Sodium can also be used with any directory server which supports X.500 DAP (Directory Access Protocol) or LDAP Lightweight Directory Access Protocol). Some key Sodium capabilities are outlined below:

Support for Kerberos, Strong Authentication and Signed Operations

Sodium’s Bind Manager contains configuration details for stored directory server connections. Each configuration contains details of the protocol (LDAP or DAP), address details and the type of authentication being used (Anonymous, Simple, Kerberos or Strong). Sodium also supports Directory signed operations: providing additional security by applying an X.509 digital signature to individual directory operations and to the results returned.

For LDAP, TLS can be configured with either LDAP (using START-TLS) or LDAPS. For both cases, if the server returns a certificate that is not trusted, trust configuration can be set up for the connection or permanently (bind profile). TLS can also be configured for DAP connections.

Certificate checking in the bind profile for DAP and LDAP is RFC 5280 (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) compliant. A trust anchor can be configured for the bind profile, and CRL checking may be used. Kerberos is also provided as an authentication option, which is particularly important for authentication to Active Directory.

X.509 Certificate and Secure Identity Management

Sodium simplifies the process of creating and managing certificate signing requests (CSRs) for an entry in order to create a secure identity as a PKCS#12 file containing a private key. Sodium does this by issuing that CSR to a Certificate Authority (CA) and creating identities from X.509 certificates returned from the CA. Sodium will work with any CA, but is designed to work cleanly with Isode’s Sodium CA, which is designed to handle certificates for Isode products.

Sodium’s ‘Create Identity’ wizard will automatically create a Certificate Signing Request (CSR) for passing on to the CA and, when the certificate has been issued, create a PKCS#12 file representing the identity. Operations can be deferred for later action in situations where the time delay between CSR and the issuing of the certificate makes it impractical to wait.

Sodium provides help generate certificates with the correct SubjectAltName values. The starting point for generating a certificate is to use Sodium’s capability to build a PKCS#10 CSR (Certificate Signing Request) that is sent to the Certificate Authority (CA) that generates the Certificate Sodium’s starting point for the CSR is a directory entry that holds information on the entity to be certified. The SubjectAltName information will usually be held as attributes in the directory entry, so Sodium makes it straightforward to include SubjectAltName values derived from appropriate attributes in the directory entry. SubjectAltName values can also be manually entered into the CSR.

PKI Display and Checking

There is a close relationship between X.509 PKI (Public Key Infrastructure) and X.500/LDAP directory. It is common practice to store certificates, CRLs (Certificate Revocation Lists) and other PKI information in a directory. For a complex PKI with multiple Certification Authorities (CAs) there will be many entities publishing related information into the directory. This can be complex. Sodium helps to manage PKI information in the directory with two types of target user:

1. Those deploying Isode products, which make use of PKI to support digital signatures for a number of peer authentication and other security features. This is part of the management tool set in support of an Isode deployment.
2. Those operating a PKI for other purposes, and simply using Isode servers to hold the data.

Sodium provides detailed display of PKI objects and in particular Certificates, Cross Certificate Pairs and CRLs in order to make more useful information available to the manager. It also provides a specialized PKI view, that displays only PKI relevant information (shown above).

As a part of Certificate display, Sodium provides an option to verify the certificate.  This will be done using trust anchors and other verification settings from the bind profile, so multiple profiles can be defined to give different checking environments.  The checks use the same verification libraries as the Isode client and server products, so this is helpful to diagnose authentication configuration problems with Isode servers, as well as general purpose checking of PKI correctness.

Security Policy, Security Label and Security Clearance Capabilities

Sodium provides support for Security Labels, Security Policy, and Security Clearances. The above screenshot shows how Sodium displays an entry that has a Security Label. The strings displayed on the screen, tooltip, and colour are controlled by the Security Policy of the Security Label. Sodium loads the Security Policy from the M-Vault server it is managing, and can also be used to set or update that Security Policy by use an attribute in the DSA entry. Alternatively, Security Policy can be configured in the bind profile, by reference to a Security Policy entry in the directory. Sodium provides GUI management of:

• Security Labels associated with entries in the directory.
• Security Clearances associated with Directory Users.
• Security controls for the DSA, on Security Labels associated with data that can be stored and Security Clearance of users that can bind to the directory.

Security Labels and Security Clearances can be selected from a Security Catalog, which may be configured along with the Security Policy.

Sodium is Security Policy aware, but not Security Policy enforcing. Security Policy is enforced by M-Vault.

The Directory Services Interface (DSI) consists of four web-based applications, all shipped with Isode’s M-Vault Directory Server:

• Personal Information Manager: Enabling personal information management (including password changes and white pages information) together with a contacts and Groups browser
• Directory: An interface to contact details held in the directory
• Phonebook: A simple phonebook listing of contacts in the directory
• Password manager interface for system operators

Support for Password Policy

DSI provides users with flexible access to the Isode directory services, without requiring a directory client to be installed on the desktop. DSI supports password policies set in the directory, including account locking, password aging and the exclusion of special accounts from the password policy.

Resetting Password

DSI provides a password manager Web operator interface to enable appropriately privileged operators to reset user passwords.

DSI also provides a Web interface as part of the personal information manager to enable users to reset their own passwords, making use of an email containing a “one time” URL.

The Directory Setup Wizard, which enables easy configuration of multiple DSAs on a single machine, provides a setup which can be used ‘as is’ for many deployments. The Wizard creates an initial user, useful groups, and default ACI (Access Control Information). This enables ACI to be handled by role based groups for directory and application management functions.

The Shadow directory setup wizard takes defaults from an existing server and replicates in groups, access control and selected data.

M-Vault Console provides a clean mechanism for setting up a directory when a GUI can conveniently be run on the server. M-Vault can also be set up headless, which is helpful for some server setups. This is done by running Cobalt web interface to create an M-Vault server. M-Vault Console is then used client/server once the initial setup is created.

MVC’s directory management features includes

• The configuration of SASL and TLS
• PKI and Strong Authentication setup, including identity creation and interaction with a CA.
• Password policy management, including hashing and SCRAM setup.
• Creation and management of shadowing agreements.
• Creation and management of failover clusters (see the next section).

MVC can be used to create and manage a failover group of M-Vault servers from multiple locations. M-Vault Console will connect to each of the servers in the failover group, and monitor the status of each server. This will give the operator a view of the status of all of the servers and ability to control failover. Two options to control failover are provided:

1. Managed. If the master is available M-Vault Console can tell the master to switch to a server. The current master will complete outstanding operations, and then switch all the servers. This will give a clean switch of master to a new server.
2. Forced. If the master is not available, M-Vault Console can tell all of the remaining servers in the group which of them is the new master, and each server will switch immediately. This model is used in a disaster recovery situation, when the master has failed.

In the screenshot below MVC is shown managing a failover group with the failover group master clearly indicated.

The M-Vault directory server provides full support for LDAP, including the current standard version (LDAPv3) [RFC 4510-4519] and its predecessor (LDAPv2) [RFC 1777-1779,1781]. This support is a key part of the module, as LDAP is the leading standard for client/server directory integration. Desktop applications requiring use of a directory, such as mail clients with directory-based address book capabilities, use LDAP as the primary access protocol. The following documents comprise the LDAP (v3) technical specification.

As well as supporting the base LDAP protocol, M-Vault also implements a number of extensions that expose clients and users to a wider range of functionality. M-Vault supports the following features, extensions and related specifications (partial list). SASL conformance and TLS conformance is set out on seperate pages. Application schema support is listed separately:

M-Vault implements the three main application protocols of X.500, these being:

• Directory Access Protocol (DAP) – for client access.
• Directory System Protocol (DSP) – for the communication of directory operations in a distributed directory system.
• Directory Information Shadowing Protocol (DISP) – for the replication of stored data from one server to another.

The server and client libraries and client products using DAP support the X.500 (2008) version of the standard.

X.500 interoperability testing has been demonstrated in live commercial and government operational environments and at EuroSInet test-bed workshops. Isode directories have also undergone strenuous internal stress testing, scalability and performance testing, and conformance testing. Interoperability of the Isode directory server has been demonstrated with other X.500 vendors.

The set of X.500 (and related) specifications that M-Vault directory server conforms to include:

Conformance for X.500 products is defined in X.519, which gives a list of conformance questions that should be addressed for an X.500 product.

The X.519 statement summarizes key capabilities and options. More detailed protocol support is also provided in three PICS (Protocol Implementations Conformance statements. The PICS proformas are aligned to X.500 (1993), and so do not cover features introduced subsequent to this version of X.500. They do cover the core capabilities:

• Directory Access Protocol (DAP) – X.500(1993)
• Directory System Protocol (DSP) – X.500(1993)
• Directory Information Shadowing Protocol (DSIP)- X.500(1993)

As well as conformance to the base standards, the Isode products are conformant to industry profiles for military and intelligence markets, for the aviation industry (AMHS).

M-Vault fully supports IPv6 for LDAP and X.500 protocols. Server addresses are stored according to X.519(2008) that enables representation of IPv4 and IPv6 addresses. These addresses will usually use Internet Domains that will be resolved to IPv4 or IPv6 addresses at run time.

n addition to LDAP and X.500 base specification, M-Vault implements a wide range of specifications detailing additional general-use and/or application-specific schema elements and/or describing an application’s directory service requirements. M-Vault implements the following additional specifications (partial list):

• COSINE LDAP/X.500 Schema [RFC 4524]
• LDAP Schema Definitions for X.509 Certificates [RFC 4523]
• H.350 Directory Services [RFC 3944]
• LDAP Schema for Printer Services [RFC 3712]
• Definition of the inetOrgPerson LDAP Object Class [RFC 2798]
• Naming Plan for Internet Directory-Enabled Applications [RFC 2377]
• An Approach for Using LDAP as a Network Information Service [RFC 2307]
• Representing the O/R Address hierarchy in the X.500 Directory Information Tree [RFC 2294]
• Representing Tables and Subtrees in the X.500 Directory [RFC 2293]
• Using Domains in LDAP/X.500 Distinguished Names [RFC 2247]
• Use of an X.500/LDAP directory to support MIXER address mapping [RFC 2164]
• Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs) [RFC 2079]
• Message Handling Systems (MHS): Overall Structure [X.402]

Directory support for Aeronational Telecommunications Network (ATN) is specified by ICAO (International Civil Aviation Authority)

• ICAO SARPS Doc 9880. Manual of Detailed Technical Specifications for the Aeronautical Telecommunications Network (ATN) using ISO/OSI Standards and Protocols. Part IV – Directory Services, Security and Systems Management. Second Edition 2016.

Military directory conformance is specified in ACP 133, described in more detail in the Isode white paper [ACP 133: The Military Directory Standard].

• ACP 133 Edition D: Common Directory Services and Procedures, July 2009.
• ACP 133 Supp-1(C): Common Directory Services and Procedures, May 2020  (update to Edition D).