|
| Sun ONE Directory Server 5.2 Getting Started Guide |
Chapter 2 Introduction to Sun ONE Directory Server
Sun ONE Directory Server provides a central repository for storing and managing information. Almost any kind of information can be stored, from identity profiles and access privileges to information about application and network resources, printers, network devices and manufactured parts. Information stored in Sun ONE Directory Server can be used for the authentication and authorization of users to enable secure access to enterprise and Internet services and applications. Sun ONE Directory Server is extensible, can be integrated with existing systems, and enables the consolidation of employee, customer, supplier, and partner information.
This chapter describes the basic concepts you must understand before undertaking design and deployment strategies. It includes the following sections:
- What is a Directory Service?
- What is Sun ONE Directory Server?
- What's New in Sun ONE Directory Server 5.2
Note that this chapter does not attempt to explain in detail all the features of Sun ONE Directory Server. However, it provides you with enough information to start using Sun ONE Directory Server for evaluation purposes.
Once you have completed this chapter, you will be able to do the practical examples in the following two chapters, A Quick Look at Directory Server Console and A Quick Look at Directory Server Command-Line Utilities.
What is a Directory Service?
A directory service is the collection of software and processes that store information about your enterprise, subscribers, or both. In the context of this documentation, a directory service consists of at least one Directory Server and one or more directory client programs. Client programs can access names, phone numbers, addresses, and other data stored in the directory, depending on the permissions that have been set.
An example of a directory service is a Domain Name System (DNS) server. A DNS server maps a computer host name to an IP address. Thus, all of the computing resources (hosts) become clients of the DNS server. The mapping of host names enables users of the computing resources to locate computers on a network, using host names rather than complex numerical IP addresses.
The DNS server stores only two types of information: names and IP addresses. A directory service stores virtually unlimited types of information.
Sun ONE Directory Server stores all of these types of information in a single, network-accessible repository. The following are a few examples of the kinds of information you might store in a directory:
- Physical device information, such as data about the printers in your organization (where they reside, whether they are color or black and white, their manufacturer, date of purchase, serial number, IP address, and so forth).
- Public employee information, such as name, email address, and department.
- Contract or account information, such as the name of a client, final delivery date, bidding information, contract numbers, and project dates.
- Information on manufactured products, enabling manufacturing companies to locate and track their products more easily.
- Authentication information.
Sun ONE Directory Server serves the needs of a wide variety of applications. It also provides standard protocols and application programming interfaces (APIs) to access the information it contains.
The following sections describe global directory services, the Lightweight Directory Access Protocol (LDAP) and the Directory Services Markup Language (DSML).
About Global Directory Services
Sun ONE Directory Server provides global directory services, meaning it provides information to a wide variety of applications. Until recently, many applications came bundled with their own proprietary user databases, with information about the users specific to that application. While a proprietary database can be convenient if you use only one application, multiple databases become an administrative burden if the databases manage the same information.
For example, suppose your network supports three different proprietary email systems, each system with its own proprietary directory service. If users change their passwords in one directory, the changes are not automatically replicated in the others. Managing multiple instances of the same information results in increased hardware and personnel costs, a problem referred to as the n + 1 directory problem.
A global directory service solves the n+1 directory problem by providing a single, centralized repository of directory information that any application can access. However, giving a wide variety of applications access to the directory requires a network-based means of communicating between the applications and the directory. Sun ONE Directory Server provides two ways in which applications can access its global directory:
- Lightweight Directory Access Protocol (LDAP)
- Directory Services Markup Language (DSML)
About LDAP
LDAP provides a common language that client applications and servers use to communicate with one another. LDAP applications can easily search, add, delete and modify directory entries. LDAP is a "lightweight" version of the Directory Access Protocol (DAP) used by the ISO X.500 standard. DAP gives any application access to the directory via an extensible and robust information framework, but at an expensive administrative cost. DAP does not use the Internet standard TCP/IP protocol, has complicated directory-naming conventions, and generally has a high return on investment.
LDAP preserves the best features of DAP while reducing administrative costs. LDAP uses an open directory access protocol running over TCP/IP and uses simplified encoding methods. It retains the X.500 standard data model and can support millions of entries for a comparatively modest investment in hardware and network infrastructure.
About DSML
DSML is a markup language that enables you to represent directory entries and commands in XML. This means that XML-based applications using HTTP can take advantage of directory services while making full use of the existing web infrastructure. Sun ONE Directory Server 5.2 implements version 2 of the DSML standard (DSMLv2).
The Sun ONE Directory Server implementation of DSMLv2 differs slightly from the standard. For information on the restrictions in and extensions to the DSML standard, please refer to the Sun ONE Directory Server Reference Manual.
Directory Services and Databases
What is the difference between a directory service and a database? A database can be defined as an organized collection of data whose contents can easily be accessed, managed, and updated. Although a directory service can be considered an extension of a database, directory services generally have the following characteristics:
- Hierarchical naming model
This naming model uniquely identifies a set of names so that there is no ambiguity when entries that have different origins but the same names are mixed together. Directory services operate in hierarchical namespaces, logically arranged in an inverse tree. A namespace is also referred to as a suffix.
- Extended search capability
Directory services provide robust search capabilities, allowing searches on individual attributes of entries.
- Distributed information model
A directory service enables directory data to be distributed across multiple servers within a network.
- Shared network access
While databases are defined in terms of APIs, directories are defined in terms of protocols. Directory access implies network access by definition. Directories are designed specifically for shared access among applications. This is achieved through the object-oriented schema model. By contrast, most databases are designed for use only by particular applications and do not encourage data sharing.
- Replicated data
Directories support replication (copies of directory data on more than one server) which make information systems more accessible and more resistant to failure.
- Datastore optimized for reads
The storage mechanism in a directory service is generally designed to support a high ratio of reads to writes.
- Extensible schema
The schema describes the type of data stored in the directory. Directory services generally support the extension of schema, meaning that new data types can be added to the directory.What is Sun ONE Directory Server?
Sun ONE Directory Server includes the directory itself, the server-side software that implements the LDAP protocol, and a graphical user interface that allows users to search and change entries in the directory. Other LDAP clients are also available, including the directory managers in the Sun ONE Console. In addition, you can purchase other LDAP client programs or write your own using the LDAP client SDK included with the Sun ONE Directory Server product.
Without adding other client programs, Sun ONE Directory Server can provide the foundation for an intranet or extranet. Every Sun ONE server uses the directory as a central repository for shared server information, such as employee, customer, supplier, and partner data.
You can use Sun ONE Directory Server to manage extranet user-authentication, create access control, set up user preferences, and centralize user management. In hosted environments, partners, customers, and suppliers can manage their own areas of the directory, reducing administrative costs.
When you install Sun ONE Directory Server, the following components are installed on your machine:
- An LDAP server with a plug-in interface.
- Sun ONE Administration Server.
- Sun ONE Server Console to manage the servers.
- Command-line tools for starting and stopping the server, importing and exporting data in the database, database reindexing, account inactivation and deactivation, LDIF merges, kernel tuning, and replication management.
For more information about the command-line tools, refer to "A Quick Look at Directory Server Command-Line Utilities" and to the tools information in the Sun ONE Directory Server Reference Manual.
- An SNMP agent
For more information about SNMP monitoring, refer to the Sun ONE Directory Server Administration Guide.
- The Directory Services Markup Language (DSML).
Overview of Sun ONE Directory Server Architecture
At installation, Sun ONE Directory Server contains the following:
- Server front-ends responsible for network communications.
- Plug-ins for server functions, such as access control and replication.
- A basic directory tree containing server-related data.
The following sections describe each component of the directory in more detail.
Overview of the Server Front-Ends
The server front-ends of Sun ONE Directory Server manage communications with directory client programs. The Directory Server functions as a daemon. Multiple client programs can communicate with the server using LDAP over TCP/IP or DSML over HTTP. The connection can be protected using Secure Socket Layer over Transport Layer Security (SSL/TLS), depending on whether the client negotiates the use of TLS for the connection.
Communication that takes place with TLS, is usually encrypted. In the future, if DNS security is present, TLS used in conjunction with secured DNS will provide confirmation to client applications that they are binding to the correct server. If clients have been issued certificates, TLS can be used by Sun ONE Directory Server to confirm that the client has the right to access the server. TLS and its predecessor, SSL, are used throughout Sun ONE Directory Server products to perform other security activities such as message integrity checks, digital signatures, and mutual authentication between servers.
Multiple clients can bind to the server at the same time over the same network because the Sun ONE Directory Server is a multi-threaded application. As directory services grow to include larger numbers of entries or larger numbers of clients spread out geographically, they also include multiple Sun ONE Directory Servers placed in strategic places around the network.
Sun ONE Directory Server implements LDAP natively, thereby avoiding the performance and management overheads associated with having a gateway on top of an X.500 directory, and with relational databases.
Server Plug-ins Overview
Sun ONE Directory Server relies on plug-ins. A plug-in is a way to add functionality to the core server. For example, the Uid Uniqueness plug-in can be used to ensure that values given to the user id (uid) attribute are unique in the suffix configured when installing the directory.
A plug-in can be disabled. When disabled, the plug-in's configuration information remains in the directory but its function is not used by the server. Depending upon what you want your directory to do, you can choose to enable any of the plug-ins provided with Sun ONE Directory Server.
Sun ONE Professional Services can write custom plug-ins for any Sun ONE Directory Server deployment. Contact Sun ONE Professional Services for more information.
Overview of the Directory Tree
The directory tree, also known as a directory information tree or DIT, mirrors the tree model used by most file systems, with the tree's root, or first entry, appearing at the top of the hierarchy. At installation, Sun ONE Directory Server creates a default directory tree.
Figure 2-1 represents the structure of the default directory tree:
Figure 2-1 Default Directory Tree
The root of the tree is called the root suffix.
At installation, the directory contains three subtrees under the root suffix:
- cn=config
where cn stands for Common Name. This subtree contains information about the server's internal configuration.
- o=NetscapeRoot
where o stands for Organization. This subtree contains the configuration information of other Sun ONE servers, such as Sun ONE Administration Server. The Administration Server takes care of authentication and all actions that cannot be performed through LDAP (such as starting or stopping Directory Server). This subtree name originates from a legacy version of the product.
- o=userRoot
During installation, a user database is created by default. The default name of the user database is o=userRoot. You can choose to populate this database at installation, or to populate it later.
Note When you install another instance of Directory Server, you can specify that it does not contain the o=NetscapeRoot information, but that it uses the configuration directory (or the o=NetscapeRoot subtree) present on another server. See the Sun ONE Server Console Server Management Guide for more information about deciding upon the location of your configuration directory.
You can build on the default directory tree to add any data relevant to your directory installation. In Figure 2-2, the o=userRoot suffix has been renamed to dc=example,dc=com, and additional subtrees have been added to reflect the organizational hierarchy.
Figure 2-2 Sample Directory TreeIn the preceding figure:
- dc refers to the domain component
- ou refers to the organizational unit
- uid refers to the user id
Directory Server Data Storage
Directory data is stored in an internal database that is implemented as a plug-in. The database plug-in is automatically installed with the directory and is enabled by default.
By default, Sun ONE Directory Server uses a single database to store the directory tree. This database can manage millions of entries. The default database supports advanced methods of backing up and restoring data, so that the data is not at risk.
You can use multiple databases to support Directory Server. You can also distribute data across the databases, enabling the server to store more data than can be held in a single database.
The following sections describe how a directory database stores data.
About Directory Entries
LDAP Data Interchange Format (LDIF) is a standard text-based format for describing directory entries. An entry is a group of lines in an LDIF file that contains information about an object, such as a person in your organization or a printer on your network. Information about the entry is represented in the LDIF file by a set of attributes and their values. Each entry has an object class attribute that specifies the kind of object the entry describes and defines the set of additional attributes it contains. Each attribute describes a particular trait of an entry.
For example, an entry might have the object class organizationalPerson, indicating that the entry represents a person within a particular organization. This object class allows the givenname and telephoneNumber attributes. The values assigned to these attributes give the name and phone number of the person represented by the entry.
Sun ONE Directory Server also uses read-only attributes that are calculated by the server. These attributes are called operational attributes. There are also some operational attributes that can be set by the administrator, for access control and other server functions.
Entries are stored in a hierarchical structure in the directory tree. In LDAP, you can query an entry and request all entries below it in the directory tree. This subtree is called the base distinguished name, or base DN. For example, if you make an LDAP search request specifying a base DN of ou=people,dc=example,dc=com, the search operation examines only the ou=people subtree in the dc=example,dc=com directory tree.
Note that not all entries are automatically returned in response to an LDAP search. Entries of the ldapsubentry object class are not returned in response to normal search requests. An ldapsubentry entry represents an administrative object, for example the entries that are used internally by Directory Server to define a role or a class of service. To receive these entries, clients must search specifically for entries of the ldapsubentry object class.
The LDIF format is described in detail in the Sun ONE Directory Server Reference Manual.
Distributing Directory Data
When you store various parts of a tree in separate databases, your directory can process client requests in parallel, improving performance. You can also store databases on different machines, to improve performance further.
To connect distributed data, you can create a special entry in a subtree of your directory. All LDAP operations attempted below this entry are sent to a remote machine where the entry is actually stored. This method is called chaining.
Chaining is implemented in the server as a plug-in, which is enabled by default. Using this plug-in, you create database links (special entries that point to data stored remotely). When a client application requests data from a database link, the database link retrieves the data from the remote database and returns it to the client.
Managing Data in Directory Server
The database is the basic unit of storage, performance, replication, and indexing. A variety of operations can be performed on a database, including importing, exporting, backing up, restoring, and indexing.
Importing Data
Sun ONE Directory Server provides three methods for importing data:
- Importing from the Directory Server Console.
You can use the Directory Server Console to append data to all of your databases, including database links.
- Initializing databases.
You can use the Directory Server Console to import data to one database. This method overwrites any data contained by the database.
- Importing data from the command line.
You can import data using the command-line utilities ldif2db, ldif2db.pl, and ldif2ldap. These utilities are described in more detail in Chapter 4 "A Quick Look at Directory Server Command-Line Utilities."
Exporting Data
You can use LDIF to export database entries from your databases. LDIF is a standard format described in RFC 2849, "The LDAP Data Interchange Format (LDIF) - Technical Specification."
Exporting data can be useful for the following:
- Backing up the data in your database
- Copying your data to another Directory Server
- Exporting your data to another application
- Repopulating databases after a change to your directory topology
You can use the Directory Server console or the command-line utilities db2ldif and db2ldif.pl to export data.
Backing Up and Restoring Data
You can use Directory Server Console or the db2bak command line utility to back up directory data. Both methods allow you to perform a backup while the server is running, which prevents you having a period during which the directory is not accessible.
You can restore data from a previously generated backup using Directory Server Console or the command-line utilities bak2db and bak2db.pl. Restoring databases overwrites any existing database files. While restoring databases, the server must be running. However, the databases are unavailable for processing operations during the restore.
Indexing Data
Depending on the size of your databases, searches performed by client applications can take a lot of time and resources. You can use indexes to improve search performance.
Indexes are files stored in the directory databases. Separate index files are maintained for each database in the directory. Each file is named according to the attribute it indexes. The index file for a particular attribute can contain multiple types of indexes, allowing you to maintain several types of index for each attribute. For example, a file called givenName.db3 contains all the indexes for the givenName attribute.
Depending on the types of applications using your directory, you will use different types of index. Different applications may frequently search for a particular attribute, or may search your directory in a different language, or may require data in a particular format.
Sun ONE Directory Server supports the following types of index:
- Presence index
The presence index lists entries that possess a particular attribute, such as uid.
- Equality index
The equality index lists entries that contain a specific attribute value, such as cn=Charlene Daniels.
- Approximate index
The approximate index allows approximate (or "sounds-like") searches. For example, an entry contains the attribute value of cn=Charlene L. Daniels. An approximate search would return this value for searches against cn~=Charlene Daniels, cn~=Charlene, and cn~=Daniels.
Note that approximate indexes work only for English language entries, in ASCII characters.
- Substring index
The substring index allows searches against substrings within entries. For example, a search for cn=*derson would match common names containing this string (such as Bill Anderson, Norma Henderson, and Steve Sanderson).
- International index
Associates the object identifier (OID) of a locale with the attributes to be indexed to speed up searches in international directories.
- Browsing index
The browsing, or virtual list view (VLV), index speeds up the display of entries in Directory Server Console. You can create a browsing index on any branch in your directory tree to improve the display performance.
Directory Server Schema
Directory schema maintains the integrity of the data stored in your directory by imposing constraints on the size, range, and format of data values. You decide what types of entries your directory contains (people, devices, organizations, and so forth) and the attributes available to each entry.
The predefined schema included with Directory Server contains both the standard LDAP schema as well as additional application-specific schema to support the features of the server. While this schema meets most directory needs, you may need to extend it with new object classes and attributes to accommodate the unique needs of your directory. Refer to the Sun ONE Directory Server Deployment Guide for information on extending the schema.
The following sections describe the format, standard attributes, and object classes included in the Sun ONE standard schema.
Schema Format
Directory Server bases its schema format on version 3 of the LDAP protocol (LDAPv3). This protocol requires directory servers to publish their schemas through LDAP itself, allowing directory client applications to retrieve the schema and adapt their behavior based on it. The global set of schema for Directory Server can be found in the entry named cn=schema.
Directory Server schema differs slightly from the LDAPv3 schema, as it uses its own proprietary object classes and attributes. In addition, it uses a private field in the schema entries called X-ORIGIN, which describes where the schema entry was defined originally. For example, if a schema entry is defined in the standard LDAPv3 schema, the X-ORIGIN field refers to RFC 2252. If the entry is defined by Sun Microsystems, Inc. for Directory Server's use, the X-ORIGIN field contains the value Sun ONE Directory Server.
For example, the standard person object class appears in the schema as follows:
objectClasses: ( 2.5.6.6 NAME 'person' DESC 'Standard LDAP objectclass' SUP top MUST ( sn $ cn ) MAY ( description $ seeAlso
$ telephoneNumber $ userPassword ) X-ORIGIN 'RFC 2256' )This schema entry states the object identifier, or OID, for the class (2.5.6.6), the name of the object class (person), a description of the class (Standard Person Object Class), then lists the required attributes (objectclass, sn, and cn) and the allowed attributes (description, seealso, telephoneNumber, and userPassword).
Standard Attributes
Attributes hold specific data elements such as a name or a fax number. Directory Server represents data as attribute-data pairs, a descriptive attribute associated with a specific piece of information. For example, the directory can store a piece of data such as a person's name in a pair with the standard attribute, in this case commonName (cn). So, an entry for a person named Charlene Daniels has the following attribute-data pair:
cn: Charlene Daniels
In fact, the entire entry is represented as a series of attribute-data pairs. The entire entry for Charlene Daniels might appear as follows:
dn: uid=cdaniels, ou=people, dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Charlene Daniels
sn: Daniels
givenName: Charlene
givenName: Charlie
mail: cdaniels@example.comNotice that the entry for Charlene contains multiple values for some of the attributes. The attribute givenName appears twice, each time with a unique value. The object classes that appear in this example are explained in the next section, "Standard Object Classes."
In the schema, each attribute definition contains the following information:
- A unique name
- An object identifier (OID) for the attribute
- A text description of the attribute
- The OID of the attribute syntax
- Indications of whether the attribute is single-valued or multi-valued, whether the attribute is for the directory's own use, the origin of the attribute, and any additional matching rules associated with the attribute.
For example, the cn attribute definition appears in the schema as follows:
attributetypes: ( 2.5.4.3 NAME 'cn' DESC 'commonName Standard Attribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The SYNTAX is the OID of the syntax for values of the attribute. For a complete description of the attribute syntax definitions, see "About Schema" in the Sun ONE Directory Server Reference Manual. For more information about the LDAPv3 schema format, refer to the LDAPv3 Attribute Syntax Definitions document (RFC 2252).
Standard Object Classes
Object classes are used to group related information. Typically, an object class represents a real object, such as a person or a fax machine. Before you can use an object class and its attributes in your directory, it must be identified in the schema. The directory recognizes a standard list of object classes by default. For more information, refer to Chapter 10, "Object Class Reference" in the Sun ONE Directory Server Reference Manual.
Each directory entry belongs to one or more object classes. Once you place an object class identified in your schema on an entry, you are telling Directory Server that the entry can have a certain set of attribute values and must have another, usually smaller, set of attribute values.
Object class definitions contain the following information:
- A unique name
- An object identifier (OID) that names the object
- A set of mandatory attributes
- A set of allowed attributes
For an example of a standard object class as it appears in the schema, refer to "Schema Format," on page 36.
Groups, Roles and Classes of Service
Information in the directory is organized hierarchically. This hierarchy is a grouping mechanism, although it is not well suited for associations between dispersed entries, for frequently changing organizations, or for data that is repeated in many entries.
As a solution to, groups and roles provide more flexible associations between entries, and class of service simplifies the management of data that is shared within branches of your directory.
Static and Dynamic Groups
A group is an entry that specifies the other entries that are its members. When you know the name of a group, it is easy to retrieve all of its member entries.
- Static groups explicitly name their member entries. Static groups are suitable for groups with few members, such as the group of directory administrators.
- Dynamic groups specify a filter, and all entries that match are members of the group. These groups are dynamic because membership is defined every time the filter is evaluated.
The advantage of groups is that they make it easy to find all of their members. Static groups may simply be enumerated, and the filters in dynamic groups may simply be evaluated. The disadvantage of groups is that given an arbitrary entry, it is difficult to name all the groups of which it is a member.
Managed, Filtered and Nested Roles
Roles are an alternative entry grouping mechanism that automatically identifies all roles of which any entry is a member. When you retrieve an entry in the directory, you immediately know the roles to which it belongs. This overcomes the main disadvantage of the group mechanism.
- Managed roles are the equivalent of static groups, except that membership is defined in each member entry and not in the role definition entry.
- Filtered roles are similar to dynamic groups. They define a filter that determines the members of the role.
- Nested roles name other role definitions, including other nested roles. The set of members of a nested role is the union of all members of the roles it contains. Nested roles may also define extended scope to include the members of roles in other subtrees.
Class of Service
The class of service (CoS) mechanism allows attributes to be shared between entries in a way that is invisible to applications. CoS does not define membership but rather allows related entries to share data for coherence and space considerations.
For example, a directory may contain thousands of entries that all have the same value for the facsimileTelephoneNumber attribute. Traditionally, to change the fax number, you would need to update each entry individually, a large job for administrators that runs the risk of not updating all entries. Using CoS, the fax number is stored in a single place, and the directory server automatically generates the facsimileTelephoneNumber attribute on every concerned entry as it is returned.
To client applications, a generated CoS attribute is retrieved just as any other attribute. However, directory administrators now have only a single fax value to manage. In addition, because there are less values actually stored in the directory, the database uses less disk space. In general, a stored attribute value will take precedence over a CoS generated value for the same attribute. However, the CoS mechanism can also override stored values, or generate multiple values for the same attribute.
Security in Directory Server
Sun ONE Directory Server provides the following security methods:
- Authentication
A means whereby one party verifies another's identity. For example, a client gives a password to Directory Server during a bind operation (the first request the server receives from a client.)
- Password policy
Defines the criteria that a password must satisfy to be considered valid, for example, age, length, and syntax.
- Encryption
Protects the privacy of information. When data is encrypted, it is converted into a form that only the intended recipient can understand.
- Access control
Controls the access rights granted to different directory users, and provides a means of specifying required credentials or bind attributes.
- Account inactivation
Disables a user account, group of accounts or an entire domain so that all authentication attempts are automatically rejected.
- Signing with SSL
Maintains the integrity of information. If information is signed, the recipient can determine that it was not tampered with during transit.
- Auditing
Allows you to determine if the security of your directory has been compromised. For example, you can audit the log files maintained by your directory.
These tools for maintaining security can be used in combination in your security design. You can also use other features of the directory such as replication and data distribution to support your security design.
Replication in Directory Server
Replication is the mechanism that automatically copies directory data from one Directory Server to another. Using replication, you can copy any directory tree or subtree (stored in its own database), or specific attributes of entries between servers. The Directory Server that holds the master copy of the information, automatically copies updates to the other servers.
Replication enables you to provide a highly available directory service, and to geographically distribute your data. In practical terms, replication brings the following benefits:
- Fault tolerance/Failover
By replicating directory trees to multiple servers, you can ensure your directory is available even if some hardware, software, or network problem prevents your directory client applications from accessing a particular Directory Server. Your clients are referred to another directory server for read and write operations. Note that to support write failover you must have a multi-master replication environment (see the definition of Masters on page 41 for more information).
- Load balancing
By replicating your directory tree across servers, you can reduce the access load on any given machine, thereby improving server response time.
- Higher performance and reduced response times
By replicating directory entries to a location close to your users, you can vastly improve directory response times.
- Local data management
Replication allows you to own and manage data locally while sharing it with other Directory Servers across your organization.
Replication Concepts
Replica
A replica refers to a database that participates in replication. A replica can take on one of the following roles:
- Master
A master is a read-write database that contains a master copy of the directory data and accepts update requests from directory clients. A master replica can be one of a set of multiple masters, or a single master. Multi-masters accept replication from other masters. Single masters do not accept replication from other replicas.
- Dedicated Consumer
A dedicated consumer is a read-only database that contains a copy of the information held in the master replica. Thus, a consumer replica accepts replication from one or more masters. A consumer replica can process search requests from directory clients but refers update requests to the master replica. This is known as referral.
- Hub
A hub is also a read-only database, like a consumer replica. A hub accepts replication from one or more masters but is also able to replicate to consumers. A hub does not accept client updates.The following figure shows a basic multi-master replication scenario, indicating the three different roles that a replica can have and the processes that occur between replicas.
Figure 2-3 Basic Multi-Master Replication Scenario
Supplier Servers and Consumer Servers
In any replication scenario, the replica sending updates is called a supplier and the server that receives updates is called a consumer. Therefore, a server that manages a master replica that it replicates to other servers is called a supplier server or master server. A server that manages a consumer replica that is updated by a different server is called a consumer server.
Note that a server can be both a supplier and a consumer. This is true in the following cases:
- When Directory Server manages a combination of master replicas and consumer replicas.
- When Directory Server acts as a hub supplier, that is, it receives updates from a master server and replicates the changes to consumer servers. This is known as cascading replication.
- When a master replica is mastered on two different Directory Servers, each Directory Server acts as a supplier and a consumer of the other Directory Server. This is known as multi-master replication.
In Sun ONE Directory Server 5.2, replication is always initiated by the supplier server, never by the consumer server. In other words, replication is supplier-initiated. In setting up replication, you configure one or more supplier servers to push data to one or more consumer servers.
For any particular replica, the supplier server must:
- Respond to read, add and modify requests from directory clients.
- Maintain state information and a change log for the replica.
- Initiate replication to consumer servers.
The supplier server is always responsible for recording the changes made to the supplier replicas that it manages. It makes sure that any changes are replicated to consumer servers.
A consumer server must:
- Respond to read requests.
- Refer add and modify requests to the supplier server for the replica.
Any time a request to add, delete, or change an entry is received by a consumer server, the request is referred to the supplier for the replica. The supplier server performs the request, then replicates the change.
In the special case of cascading replication, the hub supplier must:
- Respond to read requests.
- Refer add and modify requests to the supplier server for the replica.
- Initiate replication to consumer servers.
Change Log
Each supplier server maintains a change log. A change log is a record that describes the modifications that have occurred on a supplier replica. The supplier server replays these modifications to the replicas stored on consumer servers, or to other masters in the case of multi-master replication.
When an entry is modified, added or deleted, a change record describing the LDAP operation that was performed is recorded in the change log.
Unit of Replication
In Sun ONE Directory Server 5.2, the smallest unit of replication is a database. The replication mechanism also requires that one database correspond to one suffix. You cannot replicate a suffix that is distributed over two or more databases.
Fractional Replication
Fractional replication is a new feature in Sun ONE Directory Server 5.2 and refers to the ability to replicate only certain attributes of an entry. In fractional replication, all entries in a database are replicated, but certain attributes of these entries may be filtered out. For example, a bank may wish to replicate all the details of its customers' accounts, other than their credit card numbers. Using fractional replication, the bank can exclude only the attribute that relates to the credit card number from the data that is replicated.
Replication Agreement
Directory Server uses replication agreements to define replication. A replication agreement describes replication between one supplier and one consumer. The agreement is configured on the supplier server and identifies the following:
- The database to replicate.
- The consumer server to which the data is pushed.
- The times during which replication can occur.
- The DN and credentials the supplier server must use to bind to the consumer, called the Replication Manager entry or supplier bind DN.
- How the connection is secured (SSL, client authentication).
Replication Identity
When replication occurs between two servers, the consumer server authenticates the supplier when it binds to send replication updates. This authentication process requires that the entry used by the supplier to bind to the consumer is stored on the consumer server. This entry is called the Replication Manager entry, or supplier bind DN.
The Replication Manager entry, or any entry you create to fulfill that role, must meet the following criteria:
- There must be at least one on every server that manages consumer replicas (or hub replicas).
- This entry must not be part of the replicated data for security reasons.
Note This entry has a special user profile that bypasses all access control rules defined on the consumer server.
When you configure replication between two servers, you must identify the Replication Manager (supplier bind DN) on both servers:
- On the consumer server or hub supplier, when you configure the consumer replica or hub replica, you must specify this entry as the one authorized to perform replication updates.
- On the supplier server, when you configure the replication agreement, you must specify the DN of this entry in the replication agreement.
What's New in Sun ONE Directory Server 5.2
Sun ONE Directory Server 5.2 contains the following new features and enhancements:
- Updated and improved server management console
Directory Server Console now offers a simplified interface for configuring replication and provides support for IPv6. For details on the new console, refer to "Using the Directory Server Console" in the Sun ONE Directory Server Administration Guide.
- Enhanced replication functionality
New replication features include:
- Support for 4-way multi-master replication
- Support for multi-master replication over WAN
- Online promotion and demotion of servers
- Fractional replication (the ability to replicate a subset of attributes)
- The following replication monitoring tools:
insync - indicates the synchronization state between a master replica and one or more consumer replicas.
entrycmp - compares the attributes and values of the same entry on two different servers.
repldisc - enables you to discover a replication topology, constructing a graph of all known servers and displaying a matrix describing the topology.
Note that these tools are also compatible with Directory Server 5.1 Service Packs 1 and 2.
- Improved replication failover
- Improved concurrent replication updates
Concurrent changes can be received on a single consumer from multiple suppliers.
Within a replication session, multiple updates can be replayed concurrently.
Directory access through DSMLv2
Support for IPv6
Large cache support (64-bit)
Ability for LDAP clients to obtain their effective access rights
A simplified migration process from version 4.x and 5.x to version 5.2
Multiple password policies
An interactive GUI installer
Support for startTLS on Windows
Improved error logging
Flexible role scope
Ability to use virtual attributes in search filters
The ability to encrypt attributes other than passwords
Support for Sun Crypto Accelerator 1000 Board
Performance improvements
Advanced binary copy
Enables the cloning of master or consumer replicas using the binary backup files from one server to restore the identical directory contents on another server.
These new features are documented in the Sun ONE Directory Server Administration Guide and the Sun ONE Directory Server Deployment Guide.
