389 Directory Server

The 389 Directory Server (previously Fedora Directory Server) is an LDAP (Lightweight Directory Access Protocol) server developed by Red Hat, as part of Red Hat's community-supported Fedora Project. The name "389" derives from the port number used by LDAP. Red Hat offers a version of 389 called Red Hat Directory Server via an extra subscription on top of RHEL. Red Hat Directory Server differs from 389 in that the former is rebranded with the Red Hat branding, and includes certified stable builds, customer service, and technical support. Red Hat will rebase the Red Hat version with a stable upstream 389 branch from time to time, and backport new features and critical bug fixes as necessary. The goal of the 389 Project is to get new features out quickly, whereas the goal of Red Hat Directory Server is to ensure stability and reliability. The 389 source code is generally available under the GPLv2 license. Some components have an exception for plugin code, while other components use LGPLv2 or APL. The same applies to Red Hat Directory Server.

Though built on top of Fedora, 389 Directory Server supports many operating systems, including Red Hat Enterprise Linux 3 and later, Debian, Solaris 8 and later, and HP-UX 11i.

History

389 Directory Server is the newest incarnation of what was once the original University of Michigan slapd project. In 1996, the project's developers were hired by Netscape Communications Corporation and the project became known as the Netscape Directory Server (NDS). After acquiring Netscape, AOL sold ownership of the NDS intellectual property to Sun Microsystems, but retained rights akin to ownership. Sun sold and developed the Netscape Directory Server under the name JES/SunOne Directory Server, now Oracle Directory Server since the takeover of Sun by Oracle. AOL/Netscape's rights were acquired by Red Hat, and on June 1, 2005, much of the source code was released as free software under the terms of the GNU General Public License (GPL).

As of 389 Directory Server version 1.0 (December 1, 2005), Red Hat released as free software all of the remaining source code for all components included in the release package (admin server, console, etc.) and continues to maintain them under their respective licenses.^[1][2]

In May 2009 the Fedora Directory Server project changed its name to 389 to give the project a distribution and vendor neutral name and encourage porting or running the software on other operating systems.^[3]

Features

389 Directory server is a drop-in replacement for OpenLDAP, and is extremely easy to install and configure. A few really important features of 389 directory server is multi-master replication, a unified admin console, password policies, and the capability of sync with Active Directory. This makes 389 directory server a premium choice for Linux Administrators, and makes the job of managing your LDAP data a task just about anyone can do.

Database

389 Directory Server uses the Berkeley Database as its data store. This data store is very high performance and is transacted to ensure ACID(Automatic,Consistency,Isolation,Durability) data updates. 389 DS automatically detects if the data was not written cleanly and does a database restore at startup if necessary.

Multiple databases

Provides a simple way of breaking down your directory data to simplify the implementation of replication and chaining in your directory service. Import into one suffix without affecting the other suffixes.

Multi-master replication

For our Directory Server, multi-master means the ability to write to two or more masters at the same time, with automatic conflict resolution, as opposed to just having one master at a time with hot failover. This feature provides a highly available directory service for both read and write operations. Multi-master replication can be combined with simple and cascading replication scenarios to provide a highly flexible and scalable replication environment. You can also use fractional replication to restrict the attributes that are replicated (e.g. if you don’t want certain data to be present on a replica).

Microsoft Windows Synchronization

User, group, and password information can be synchronized with an Active Directory (2003 and 2008 32-bit and 64-bit) domain controller and with an NT4 domain controller.

Powerful access control mechanism

The access control information is contained with the data (in operational attributes), which means that it is always available when the data is imported or restored from backup. Provides support for macros that dramatically reduce the number of access control statements used in the directory, and increase the scalability of access control evaluation. Supports the Get Effective Rights operation allowing admins and data designers to perform “What If?” queries when designing the access control structure.

TLS

Provides TLSv1 secure communications over the network including ciphers with up to 256-bit encryption. Clients can use certificates for authentication with flexible cert subject to LDAP identity mapping. Supports the LDAP startTLS operation allowing the use of crypto on a non-secure port. FDS uses Mozilla NSS as the crypto engine.

SASL - Simple Authentication and Security Layer

A method for adding authentication support to connection-based protocols. Especially useful in conjunction with Kerberos, allow the use of Kerberos credentials to authenticate to the directory.

Attribute encryption

Allows individual sensitive attributes to be encrypted on disk for more security.

On line configuration and management

Almost all server configuration and management can be done on line, over LDAP, including import/export/backup/restore - no downtime.

Task invocation via LDAP

389 DS provides a special entry called cn=tasks,cn=config with several sub-entries for each type of task supported: cn=import; cn=export; cn=backup; cn=restore; cn=index. The creation of an entry under one of these sub-entries causes the directory server to invoke that operation. Parameters are passed to the operation as attributes in the entry (e.g. the name of the LDIF file to export to). Status information is reported as attributes in that entry allowing clients to query for task status and completion.

Chaining and referrals

Increases the power of your directory by storing a complete logical view of your directory on a single server while maintaining data on a large number of directory servers, transparently for clients. Chaining can be used in conjunction with entry distribution to distribute the entries in one suffix among many servers, so that one suffix can have the appearance of holding hundreds of millions of entries. For example, by using a hash of the userid, or an alphabetical range, or any number of schemes.

Plug-in Interface

Allows developers to extend the functionality of the server using a well defined C/C++ interface. Many of the core features of the server (such as replication, access control, roles, et al.) are implemented as plug-ins.

Data Interoperability Plugins

Allow the use of an RDBMS for the data source, or any other data source.

High performance logging

Full access logging in production environments, with flexible log rotation policies, plus access log analysis tools. The error log level can be adjusted in a running server to provide very detailed information to debug problems in production systems with no downtime.

Language handling

Out of the box, Directory Server correctly sorts 38 languages; you can use plug-in handlers for foreign languages that Directory Server does not already sort.

Resource-limits by bind DN

Gives you the power to control the amount of server resources allocated to search operations based on the bind DN of the client.

Roles and Class of Service

Class of Service provides a very flexible virtual attribute mechanism which allows attribute values to be shared among many entries, including the indexing of those attributes for fast searching. Roles leverages this facility to provide a high performance grouping capability.

Server Side Sorting

Allows search results to be sorted in any number of ways. By using this in conjunction with Virtual List View, this allows powerful GUI components to be built allowing users to scroll or page through search results.

Virtual Views

The data can be stored in a flat DIT, and hierarchical views, based on properties of the entries, can be displayed. For example, a tree based on location, or employee status, or anything else.

Directory Server Gateway/Phonebook

A web application that provides a search/query interface for directory server data. It allows administrators to add and modify data in the directory server via a simple HTML based interface, and allows users to “self service” their own data (e.g. so they can modify their password, or mobile number, or etc.).

Directory Server Org Chart

A web application that shows the organizational chart of the user data in a tree like format. This tree is based on the manager attribute in each user’s entry.

DSML Gateway

DSMLv2 is a SOAP/HTTP based protocol for communicating with directory services. 389 DS provides a gateway that runs apart from the server on a web or application server (such as Tomcat).

See also

• List of LDAP software
• FreeIPA
• OpenLDAP

References

External links

• 389 Project home page