1. Manuals
  2. Brands
  3. Netscape Manuals
  4. Server
  5. NETSCAPE DIRECTORY SERVER 6.0 - DEPLOYMENT
  6. Deployment manual

Netscape DIRECTORY SERVER 6.0 - DEPLOYMENT Deployment Manual

Hide thumbs
Table of Contents

Advertisement

Quick Links

Download this manual
Deployment Guide
Netscape Directory Server
Version 6.0
December 2001

Advertisement

Table of Contents
loading

Related Manuals for Netscape NETSCAPE DIRECTORY SERVER 6.0 - DEPLOYMENT

Summary of Contents for Netscape NETSCAPE DIRECTORY SERVER 6.0 - DEPLOYMENT

  • Page 1 Deployment Guide Netscape Directory Server Version 6.0 December 2001...
  • Page 2 Netscape Communications Corporation ("Netscape") and its licensors retain all ownership rights to the software programs offered by Netscape (referred to herein as "Software") and related documentation. Use of the Software and related documentation is governed by the license agreement for the Software and applicable copyright law. Your right to copy this documentation is limited by copyright law.

  • Page 3: Table Of Contents

    Contents About This Guide ............. . . 9 Purpose of This Guide .
  • Page 4 What Your Directory Might Include ........... . 26 What Your Directory Should Not Include .
  • Page 5 Designing Your Directory Tree ............58 Choosing a Suffix .
  • Page 6 Chapter 6 Designing the Replication Process ........95 Introduction to Replication .
  • Page 7 Simple Password ..............126 Certificate-Based Authentication .
  • Page 8 Supplier Consumer Architecture ........... 152 Security Design .

  • Page 9: About This Guide

    About This Guide Welcome to the Netscape Directory Server (Directory Server). This preface includes the following sections: • Purpose of This Guide (page 9) • Directory Server Overview (page 10) • Conventions Used in This Guide (page 11) • Related Information (page 11) Purpose of This Guide This guide provides you with a foundation for planning your directory.

  • Page 10: Directory Server Overview

    Directory Server Overview Directory Server Overview Directory Server provides the following key features: • Multi-master replication—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.

  • Page 11: Conventions Used In This Guide

    Conventions Used in This Guide • Online backup and restore—Allows you to create backups and restore from backups while the server is running. Conventions Used in This Guide This guide uses the following conventions: —This typeface is used for any text that appears on the computer Monospaced font screen or text that you should type.
  • Page 12 Related Information • Netscape Directory Server Configuration, Command, and File Reference. Provides information about using the command-line scripts shipped with Directory Server. • Netscape Directory Server Schema Reference. Provides reference information about the Netscape Directory Server schema. For a list of documentation installed with Directory Server, open the file, where is the <server_root>/manual/en/slapd/index.htm...

  • Page 13: Chapter 1 Introduction To Directory Server

    Chapter 1 Introduction to Directory Server Netscape Directory Server (Directory Server) provides a centralized directory service for your intranet, network, and extranet information. Directory Server integrates with existing systems and acts as a centralized repository for the consolidation of employee, customer, supplier, and partner information. You can extend Directory Server to manage user profiles and preferences, as well as extranet user authentication.

  • Page 14: About Global Directory Services

    What is a Directory Service? However, the DNS server stores only two types of information: names and IP addresses. A true directory service stores virtually unlimited types of information. Directory Server stores all of your information in a single, network-accessible repository.

  • Page 15: About Ldap

    Introduction to Directory Server 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.
  • Page 16 Introduction to Directory Server You can use 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 portions of the directory, reducing administrative costs. When you install Directory Server, the following components are installed on your machine: •...

  • Page 17: Overview Of Directory Server Architecture

    Introduction to Directory Server Overview of Directory Server Architecture At installation, Directory Server contains the following: • A server front-end 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.

  • Page 18: Overview Of The Basic Directory Tree

    Introduction to Directory Server Netscape Professional Services can write custom plug-ins for your Directory Server deployment. Contact Netscape Professional Services for more information. Overview of the Basic 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.

  • Page 19: Directory Server Data Storage

    Introduction to Directory Server NOTE When you install another instance of Directory Server, you can specify that it does not contain the information, o=NetscapeRoot that it uses the configuration directory (or the o=NetscapeRoot subtree) present on another server. See the Netscape Directory Server Installation Guide for more information about deciding upon the location of your configuration directory.

  • Page 20: About Directory Entries

    Introduction to Directory Server By default, Directory Server uses a single database to contain the directory tree. This database can manage millions of entries. The default database supports advanced methods of backing up and restoring your data, so that your data is not at risk.

  • Page 21: Distributing Directory Data

    Directory Design Overview For more information about roles, see “About Roles,” on page 71. For more information about class of service, see “About Class of Service,” on page 72. Distributing Directory Data When you store various parts of your tree in separate databases, your directory can process client requests in parallel, improving performance.

  • Page 22: Design Process Outline

    Directory Design Overview Design Process Outline The remainder of this guide divides the design process into six steps: • How to Plan Your Directory Data. Your directory will contain data, such as user names, telephone numbers, and group details. Chapter 2, “How to Plan Your Directory Data,” helps you analyze the various sources of data in your organization and understand their relationship with one another.

  • Page 23: Deploying Your Directory

    Directory Design Overview • Designing the Replication Process. With replication, multiple Directory Servers maintain the same directory data to increase performance and provide fault tolerance. Chapter 6, “Designing the Replication Process,” describes how replication works, what kinds of data you can replicate, common replication scenarios, and tips for building a highly available directory service.

  • Page 24: Other General Directory Resources

    Other General Directory Resources • A schedule of what needs to be accomplished and when • A set of criteria for measuring the success of your deployment For information on installing your directory service, refer to Netscape Directory Server Installation Guide. For information on administering and maintaining your directory, refer to Netscape Directory Server Administrator’s Guide.

  • Page 25: Chapter 2 How To Plan Your Directory Data

    Chapter 2 How to Plan Your Directory Data The data stored in your directory may include user names, email addresses, telephone numbers, and information about groups users are in, or it may contain other types of information. The type of data in your directory determines how you structure the directory, to whom you allow access to the data, and how this access is requested and granted.

  • Page 26: What Your Directory Might Include

    Introduction to Directory Data For example, an employee’s preference settings for a software application may not seem to be appropriate for the directory because only a single instance of the application needs access to the information. However, if the application is capable of reading preferences from the directory and users might want to interact with the application according to their preferences from different sites, then it is very useful to include the preference information in the directory.

  • Page 27: What Your Directory Should Not Include

    Defining Your Directory Needs What Your Directory Should Not Include Directory Server is excellent for managing large quantities of data that client applications read and occasionally write, but it is not designed to handle large, unstructured objects, such as images or other media. These objects should be maintained in a file system.

  • Page 28: Performing A Site Survey

    Performing a Site Survey Performing a Site Survey A site survey is a formal method for discovering and characterizing the contents of your directory. Budget plenty of time for performing a site survey, as data is the key to your directory architecture.The site survey consists of the following tasks, which are described briefly here and in more detail next: •...

  • Page 29: Identifying The Applications That Use Your Directory

    Performing a Site Survey If you import data from other sources, develop a strategy for both bulk imports and incremental updates. As a part of this strategy, try to master data in a single place, and limit the number of applications that can change the data. Also, limit the number of people who write to any given piece of data.

  • Page 30: Identifying Data Sources

    Performing a Site Survey Table 2-1 Application Data Needs Application Class of Data Data Phone book People Name, email address, phone number, user ID, password, department number, manager, mail stop Web server People, groups User ID, password, group name, groups members, group owner Calendar server People, meeting...

  • Page 31: Characterizing Your Directory Data

    Performing a Site Survey Some common sources for information are networking operating systems (Windows NT, Novell Netware, UNIX NIS), email systems, security systems, PBX (telephone switching) systems, and human resources applications. • Determine how centralizing each piece of data affects the management of data. You may find that centralized data management requires new tools and new processes.

  • Page 32: Determining Level Of Service

    Performing a Site Survey For example, you can create a table that characterizes your directory data as follows: Table 2-3 Directory Data Characteristics Data Format Size Owner Related to Employee Name Text string 128 characters Human User’s entry resources Fax number Phone number 14 digits Facilities...

  • Page 33: Data Mastering For Replication

    Performing a Site Survey Data Mastering for Replication Directory Server allows you to contain master sources of information on more than one server. If you use replication, decide which server is the master source of a piece of data. Directory Server 5.0 supports multi-master configurations, in which more than one server are masters sources for the same pice of data.

  • Page 34: Determining Data Ownership

    Performing a Site Survey Mastering data in non-directory applications makes the most sense if you can identify one or two applications that you already use to master your data, and you want to use your directory only for lookups (for example, for online corporate telephone books).

  • Page 35: Determining Data Access

    Performing a Site Survey • Allow an organization’s administrator to create and manage entries for that organization. This approach makes your organization’s administrators your directory content managers. • Create roles that give groups of people read or write access privileges. For example, you might create roles for human resources, finance, or accounting.
  • Page 36 Performing a Site Survey • Can the data be read anonymously? The LDAP protocol supports anonymous access, and allows easy lookups for common information such as office sites, email addresses, and business telephone numbers. However, anonymous access gives anyone with access to the directory access to the common information.

  • Page 37: Documenting Your Site Survey

    Performing a Site Survey Documenting Your Site Survey Because of the complexity of data design, document the results of your site surveys. During each step of the site survey we have suggested simple tables for keeping track of your data. Consider building a master table that outlines your decisions and outstanding concerns.

  • Page 38: Repeating The Site Survey

    Performing a Site Survey Employee names can be read anonymously by everyone with access to the directory. • HR Writable Members of the human resources group can change, add, and delete employee names in the directory. • IS Writable Members of the information services group can change, add, and delete employee names in the directory.

  • Page 39: Chapter 3 How To Design The Schema

    Chapter 3 How to Design the Schema The site survey you conducted in Chapter 2 generated information abut the data you plan to store in your directory. Next, you must decide how to represent the data you store. Your directory schema describes the types of data you can store in your directory.

  • Page 40: Netscape Standard Schema

    Netscape Standard Schema • Extending the standard Directory Server schema to define new elements to meet your remaining needs. • Planning for schema maintenance. It is best to use existing schema elements defined in the standard schema provided with Directory Server. Choosing standard schema elements helps ensure compatibility with directory-enabled applications.
  • Page 41 Netscape Standard Schema The 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 , which describes where the schema entry was X-ORIGIN defined originally.

  • Page 42: Standard Attributes

    Netscape Standard Schema Syntax Description Boolean Boolean values have a value of either "TRUE" or "FALSE." GeneralizedTime Values in this syntax are encoded as printable strings. It is strongly recommended that GMT time be used. The time zone must be specified. CountryString A value in this syntax is encoded the same as a value of DirectoryString syntax.

  • Page 43: Standard Object Classes

    Netscape Standard Schema sn: Jensen givenName: Babs givenName: Barbara mail: bjensen@example.com Notice that the entry for Babs contains multiple values for some of the attributes. The attribute appears twice, each time with a unique value. The object givenName classes that appear in this example are explained in the next section, “Standard Object Classes."...

  • Page 44: Mapping Your Data To The Default Schema

    Mapping Your Data to the Default Schema • 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 40. As is the case for all of the Directory Server’s schema, object classes are defined and stored directly in Directory Server.

  • Page 45: Matching Data To Schema Elements

    Mapping Your Data to the Default Schema Matching Data to Schema Elements The data you identified in your site survey now needs to be mapped to the existing directory schema. This process involves the following steps: • Identify the type of object the data describes. Select an object that best matches the data described in your site survey.

  • Page 46: Customizing The Schema

    Customizing the Schema In the table, the employee name describes a person. In the default directory schema, we found the object class, which inherits from the object class. person This object class allows several attributes, one of which is the commonName attribute, which describes the full name of the person.

  • Page 47: When To Extend Your Schema

    Customizing the Schema serverID /usr/netscape/servers/slapd- /config/schema/99user.ldif The following sections describe customizing the directory schema in more detail: • When to Extend Your Schema • Getting and Assigning Object Identifiers • Naming Attribute and Object Classes • Strategies for Defining New Object Classes •...

  • Page 48: Naming Attribute And Object Classes

    Customizing the Schema • Create an OID registry so you can track OID assignments. An OID registry is a list you maintain that gives the OIDs and descriptions of the OIDs used in your directory schema. This ensures that no OID is ever use for more than one purpose.
  • Page 49 Customizing the Schema would be . You might then create an object class examplePerson inetOrgPerson called and have it allow exampleOrganization exampleBuildingFloor . The parent of would be the exampleVicePresident exampleOrganization object class. organization Your new object classes would appear in LDAPv3 schema format as follows: objectclasses: ( 2.16.840.1.17370.999.1.2.3 NAME 'examplePerson' DESC 'Example Person Object Class' SUP inetorgPerson MAY (exampleDateOfBirth...

  • Page 50: Strategies For Defining New Attributes

    Customizing the Schema • Single object classes simplify data design when you have data that you want to put on more than one type of object class structure. For example, suppose you want on both a person and a group preferredOS entry.

  • Page 51: Creating Custom Schema Files

    Customizing the Schema However, if you extend the schema and find you do not use the new elements, feel free to delete the elements you don’t use. Before removing the object class definitions from the schema, you need to modify each entry using the object class. Otherwise, if you remove the definition first, you might not be able to modify the entries that use the object class afterwards.

  • Page 52: Custom Schema Best Practices

    Customizing the Schema • Allow the replication process to replicate this information to each of the consumers for you. If you do not copy these custom schema files to all of your servers, the schema information will only be replicated to the consumer when changes are made to the schema on the supplier using LDAP or the Directory Server Console.

  • Page 53: Maintaining Consistent Schema

    Maintaining Consistent Schema addition to what you have already specified for the . The result is that X-ORIGIN attributes that are not will appear in the read-only section of 'user defined' the Directory Server Console, and you will not be able to use the console to edit object classes that contain an other than X-ORIGIN...

  • Page 54: Schema Checking

    Maintaining Consistent Schema The following sections describe in detail how to maintain consistency within your schema. Schema Checking Schema checking ensures that all new or modified directory entries conform to the schema rules. When the rules are violated, the directory rejects the requested change.

  • Page 55: Maintaining Consistency In Replicated Schema

    Maintaining Consistent Schema With the LDAP protocol and Directory Server, you must represent data in the data formats specified in RFC 2252. In addition, the correct LDAP format for telephone numbers is defined in the following ITU-T Recommendations documents: • ITU-T Recommendation E.123.

  • Page 56: Other Schema Resources

    Other Schema Resources Other Schema Resources Refer to the following links for more information about standard LDAPv3 schema: • Internet Engineering Task Force (IETF) http://www.ietf.org/ • Understanding and Deploying LDAP Directory Services T. Howes, M. Smith, G. Good, Macmillan Technical Publishing, 1999. •...

  • Page 57: Chapter 4 Designing The Directory Tree

    Chapter 4 Designing the Directory Tree Your directory tree provides a way to refer to the data stored by your directory. The types of information you store in your directory, the physical nature of your enterprise, the applications you use with your directory, and the types of replication you use shape the design of your directory tree.

  • Page 58: Designing Your Directory Tree

    Designing Your Directory Tree • Simplified directory navigation for directory users The structure of your directory tree follows the hierarchical LDAP model. Your directory tree provides a way to organize your data, for example, by group, by people, or by place. It also determines how you partition data across multiple servers.

  • Page 59: Suffix Naming Conventions

    Designing Your Directory Tree Suffix Naming Conventions All entries in your directory should be located below a common base entry, the root suffix. Consider the following recommendations for naming the root directory suffix: • Globally unique • Static, so it rarely changes, if ever •...

  • Page 60: Naming Multiple Suffixes

    Designing Your Directory Tree Naming Multiple Suffixes Each suffix that you use with your directory is a unique directory tree. There are several ways that you can include multiple trees in your directory. The first is to create multiple directory trees stored in separate databases served by Directory Server.
  • Page 61 Designing Your Directory Tree Following are some guidelines for designing your directory tree hierarchy: • Branch your tree to represent only the largest organizational subdivisions in your enterprise. Any such branch points should be limited to divisions (Corporate Information Services, Customer Support, Sales and Professional Services, and so forth). Make sure that divisions you use to branch your directory tree are stable;...

  • Page 62: Identifying Branch Points

    Designing Your Directory Tree Branching in a Hosting Environment For a hosting environment, create a tree that contains two entries of the object class and one entry of the object class organization(o) organizationalUnit(ou) beneath the root suffix. For example, the ISP branches their directory as example shown below.
  • Page 63 Designing Your Directory Tree The directory tree for , an internet host, appears as follows: example Beneath the root suffix entry, , the tree is split into three branches. o=example,c=US The ISP branch contains customer data and internal information for .

  • Page 64: Replication Considerations

    Designing Your Directory Tree Traditional DN Branch Point Attributes (Continued) Table 4-1 Attribute Name Definition An organizational unit. This attribute is typically used to represent a smaller divisional branching of your enterprise than an organization. Organizational units are generally subordinate to the preceding organization.
  • Page 65 Designing Your Directory Tree After creating the initial structure of the tree, they create additional branches as follows: As another example, the ISP branches their directory as follows: example.com After creating the initial structure of their directory tree, they create additional branches as follows: Chapter 4 Designing the Directory Tree...

  • Page 66: Access Control Considerations

    Designing Your Directory Tree Both the enterprise and the hosting organization design their data hierarchies based on information that is not likely to change often. Access Control Considerations Introducing hierarchy into your directory tree can be used to enable certain types of access control.

  • Page 67: Naming Entries

    Designing Your Directory Tree Naming Entries After designing the hierarchy of your directory tree, you need to decide which attributes to use when naming the entries within the structure. Generally, names are created by choosing one or more of the attribute values to form a relative distinguished name (RDN).
  • Page 68 Designing Your Directory Tree You can avoid common name collisions by adding a unique identifier to the common name. For example: cn=Babs Jensen+employeeNumber=23,dc=example,dc=com However, this can lead to awkward common names for large directories and can be difficult to maintain. A better method is to identify your person entries with some attribute other than .

  • Page 69: Naming Group Entries

    Designing Your Directory Tree Placing Person Entries in the DIT Here are some guidelines for placing people entries in your directory tree: • People in an enterprise should be located in the directory tree below the organization’s entry. • Subscribers to a hosting organization need to be below the branch ou=people for the hosted organization.

  • Page 70: Naming Other Kinds Of Entries

    Grouping Directory Entries o=example_a+st=Washington,o=ISP,c=US You can also use trademarks, however they are not guaranteed to be unique. In a hosting environment, you need to include the following attributes in the organization’s entry: • o (organizationName) • with values of , and objectClass organization nsManagedDomain...

  • Page 71: About Roles

    Grouping Directory Entries About Roles Roles are a new entry grouping mechanism. Your directory tree organizes information hierarchically. This hierarchy is a grouping mechanism, though it is not suited for short-lived, changing organizations. Roles provide another grouping mechanism for more temporary organizational structures. Roles unify static and dynamic groups.

  • Page 72: Deciding Between Roles And Groups

    Grouping Directory Entries • Filtered roles—A filtered role allows you to assign entries to the role depending upon the attribute contained by each entry. You do this by specifying an LDAP filter. Entries that match the filter are said to possess the role.
  • Page 73 Grouping Directory Entries generate the attribute dynamically. The attribute is facsimileTelephoneNumber stored in one place, and each entry points to that place to give a value to their fax number attribute. For the application, these attributes appear just like all other attributes, despite that they are not actually stored on the entries themselves.

  • Page 74: Directory Tree Design Examples

    Directory Tree Design Examples • Classic CoS—A classic CoS identifies the template entry by both its DN and the value of one of the target entry’s attributes. Classic Cos can have multiple template entries, including a default CoS template to be applied to those entries that do not belong to any other CoS template.

  • Page 75: Directory Tree For An Isp

    Directory Tree Design Examples Directory Tree for an ISP Internet service providers (ISPs) may support multiple enterprises with their directories. If you are an ISP, consider each of your customers as a unique enterprise and design their directory trees accordingly. For security reasons, each account should be provided a unique directory tree with a unique suffix and an independent security policy.

  • Page 76: Other Directory Tree Resources

    Other Directory Tree Resources Other Directory Tree Resources Take a look at the following links for more information about designing your directory tree: • RFC 2247: Using Domains in LDAP/X.500 Distinguished Names http://www.ietf.org/rfc/rfc2247.txt • RFC 2253: LDAPv3, UTF-8 String Representation of Distinguished Names http://www.ietf.org/rfc/rfc2253.txt Netscape Directory Server Deployment Guide •...

  • Page 77: Chapter 5 Designing The Directory Topology

    Chapter 5 Designing the Directory Topology In Chapter 4, “Designing the Directory Tree”, you designed how your directory stores entries. Because Netscape Directory Server (Directory Server) can store a large quantity of entries, you may need to distribute your entries across more than one server.

  • Page 78: Distributing Your Data

    Distributing Your Data The database is the basic unit you use for jobs such as replication, performing backups, and restoring data. You can carve a single directory into manageable chunks and assign them to separate databases. These databases can then be distributed among a number of servers, reducing the work load for each server.

  • Page 79: About Using Multiple Databases

    Distributing Your Data About Using Multiple Databases Directory Server stores data in LDBM databases.The LDBM database is a high-performance disk-based database. Each database consists of a set of large files that contains all of the data assigned to it. You can store different portions of your directory tree in different databases. For example, your directory tree appears as follows: You can store the data of the three suffixes in three separate databases as follows: When you divide your directory tree among a number of databases, these...

  • Page 80: About Suffixes

    Distributing Your Data Distributing databases across multiple servers reduces the amount of work each server needs to do. Thus, the directory can be made to scale to a much larger number of entries than would be possible with a single server. In addition, Directory Server supports adding databases dynamically, meaning you can add new databases when your directory needs them without taking your entire directory off-line.
  • Page 81 Distributing Your Data The suffixes that result contain entries for the following: suffixes are both root suffixes. The o=NetscapeRoot dc=example,dc=com other suffix, the ou=testing,dc=example,dc=com suffix and the ou=development,dc=example,dc=com suffix are all sub suffixes of ou=partners,ou=development,dc=example,dc=com root suffix. The root suffix contains dc=example,dc=com dc=example,dc=com...

  • Page 82: About Knowledge References

    About Knowledge References About Knowledge References Once you have distributed your data over several databases, you need to define the relationship between the distributed data. You do this using knowledge references, pointers to directory information held in different databases. The Directory Server provides the following types of knowledge references to help you link your distributed data into a single directory tree: •...

  • Page 83: The Structure Of An Ldap Referral

    About Knowledge References • Smart referrals Smart referrals are stored on entries within the directory itself. Smart referrals point to Directory Servers that have knowledge of the subtree whose DN matches the DN of the entry containing the smart referral. All referrals are returned in the format of an LDAP uniform resource locator (URL).

  • Page 84: About Default Referrals

    About Knowledge References About Default Referrals Default referrals are returned to clients when the server or database contacted does not contain the data requested. Directory Server determines whether a default referral should be returned by comparing the DN of the requested directory object against the directory suffixes supported by the local server.
  • Page 85 About Knowledge References You redirect all requests on this branch to the branch of the European ou=people office of Corporation by specifying a smart referral on the example.com ou=people entry itself. This smart referral appears as follows: ldap://europe.example.com:389/ou=people,dc=example,dc=com Any requests made to people branch of the American directory are redirected to the European directory.
  • Page 86 About Knowledge References Finally, if you serve multiple suffixes on the same server, you can redirect queries from one namespace to another namespace served on the same machine. If you want to redirect all queries on the local machine for o=example,c=us , then you would put the following smart referral on the dc=example,dc=com...

  • Page 87: Tips For Designing Smart Referrals

    About Knowledge References Tips for Designing Smart Referrals While simple to implement, consider the following points before using smart referrals: • Keep the design simple. Deploying your directory using a complex web of referrals makes administration difficult. Also, overusing smart referrals can lead to circular referral patterns.

  • Page 88: Using Chaining

    About Knowledge References • Consider the security implications. Access control does not cross referral boundaries. Even if the server where the request originated allows access to an entry, when a smart referral sends a client request to another server, the client application may not be allowed access.

  • Page 89: Deciding Between Referrals And Chaining

    About Knowledge References • Dynamic management. You can add or remove a part of the directory from the system while the entire system remains available to client applications. The database link can temporarily return referrals to the application until entries have been redistributed across the directory.

  • Page 90: Usage Differences

    About Knowledge References Usage Differences Some client applications do not support referrals. Chaining allows client applications to communicate with a single server and still access the data stored on many servers. Sometimes referrals do not work when a company’s network uses proxies.
  • Page 91 About Knowledge References However, Server A does not contain the information requested. Instead, Server A returns a referral to the client application telling them to contact Server B. The client application then sends a bind request to Server B. To bind successfully, Server B must also contain an entry for the client application.
  • Page 92 About Knowledge References In a chained system, the entry corresponding to the client application does not need to be located on the same server as the data the client requests. For example, a system could be set up as follows: In this illustration, the following steps are performed: The client application binds with Server A and Server A tries to confirm that the user name and password are correct.

  • Page 93: Using Indexes To Improve Database Performance

    Using Indexes to Improve Database Performance Using Indexes to Improve Database Performance Depending upon the size of your databases, searches performed by client applications can take a lot of time and resources. In order to improve search performance, you can use indexes. Indexes are files stored in your directory databases.

  • Page 94: Evaluating The Costs Of Indexing

    Using Indexes to Improve Database Performance • International index—The international index speeds searches for information in international directories. You configure the index to apply a matching rule by associating a locale (OID) with the attribute being indexed. • Browsing Index—The browsing, or virtual list view, index speeds up the display of entries in the Directory Server Console.

  • Page 95: Chapter 6 Designing The Replication Process

    Chapter 6 Designing the Replication Process Replicating your directory contents increases the availability and performance of your directory. In Chapter 4 and Chapter 5, you made decisions about the design of your directory tree and your directory topology. This chapter addresses the physical and geographical location of your data, and specifically, how to use replication to ensure your data is available when and where you need it.

  • Page 96: Replication Concepts

    Introduction to Replication 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.

  • Page 97: Unit Of Replication

    Introduction to Replication These decisions cannot be made effectively without an understanding of how the Directory Server handles these concepts. For example, when you decide what information you want to replicate, you need to know what is the smallest replication unit that the Directory Server can handle. The following sections contain definitions of concepts used by the Directory Server.

  • Page 98: Change Log

    Introduction to Replication For any particular replica, the supplier server must: • Respond to read requests and update 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 read-write replicas that it manages.

  • Page 99: Replication Agreement

    Introduction to Replication Replication Agreement Directory Servers use replication agreements to define replication. A replication agreement describes replication between one supplier and one consumer. The agreement is configured on the supplier server. It identifies: • The database to replicate • The consumer server to which the data is pushed •...

  • Page 100: Common Replication Scenarios

    Common Replication Scenarios In the case of multi-master replication, the replicas on each master are said to be loosely consistent because at any given time, there can be differences in the data stored on each master. This is true even when you have selected to always keep replicas in sync, because: •...

  • Page 101: Multi-Master Replication

    Common Replication Scenarios Single-Master Replication Figure 6-1 The supplier server can replicate a read-write replica to several consumer servers. The total number of consumer servers that a single supplier server can manage depends on the speed of your networks and the total number of entries that are modified on a daily basis.
  • Page 102 Common Replication Scenarios Although two separate servers can have master copies of the same data, within the scope of a single replication agreement, there is only one supplier server and one consumer. So, to create a multi-master environment between two supplier servers that share responsibility for the same data, you need to create more than one replication agreement.

  • Page 103: Cascading Replication

    Common Replication Scenarios Replication Traffic in a Multi-Master Environment Figure 6-3 Cascading Replication In a cascading replication scenario, a hub supplier receives updates from a supplier server, and replays those updates on consumer servers. The hub supplier is a hybrid: it holds a read-only replica, like a typical consumer server and it maintains a change log like a typical supplier server.
  • Page 104 Common Replication Scenarios connection between Minneapolis and Duluth is of poor quality. Then, if your network between Saint Cloud and Duluth is of acceptable quality, you can use cascaded replication to move directory data from Minneapolis to Saint Cloud to Duluth.

  • Page 105: Mixed Environments

    Common Replication Scenarios Replication Traffic and Change logs in Cascading Replication Figure 6-5 Mixed Environments You can combine any of the scenarios outlined in the previous sections to best fit your needs. For example, you could combine a multi-master configuration with a cascading configuration to produce something similar to the scenario illustrated in Figure 6-6 on page 106.
  • Page 106 Common Replication Scenarios Combined Multi-Master and Cascading Replication Figure 6-6 Netscape Directory Server Deployment Guide • December 2001...

  • Page 107: Defining A Replication Strategy

    Defining a Replication Strategy Defining a Replication Strategy The replication strategy that you define is determined by the service you want to provide: • If high availability is your primary concern, you should create a data center with multiple directory servers on a single site. You can use single-master replication to provide read-failover, and multi-master replication to provide write-failover.

  • Page 108: Replication Survey

    Defining a Replication Strategy • Using Replication for Load Balancing • Example Replication Strategy for a Small Site • Example Replication Strategy for a Large Site Replication Survey The type of information you need to gather from your survey to help you define your replication strategy includes: •...

  • Page 109: Using Replication For High Availability

    Defining a Replication Strategy In addition, as there is a single change log on every supplier server, if a supplier contains multiple replicated databases the change log will be used more frequently, and the disk usage will be even higher. •...

  • Page 110: Using Replication For Local Availability

    Defining a Replication Strategy Using Replication for Local Availability Your need to replicate for local availability is determined by the quality of your network as well as the activities of your site. In addition, you should carefully consider the nature of the data contained in your directory and the consequences to your enterprise in the event that the data becomes temporarily unavailable.

  • Page 111: Example Of Network Load Balancing

    Defining a Replication Strategy One of the more important reasons to replicate directory data is to balance the work load of your network. When possible, you should move data to servers that can be accessed using a reasonably fast and reliable network connection. The most important considerations are the speed and reliability of the network connection between your server and your directory users.
  • Page 112 Defining a Replication Strategy Each office contains a high-speed network, but you are using a dial-up connection to network between the two cities. To balance your network load: • Select one server in each office to be the master server for the locally managed data.

  • Page 113: Example Of Load Balancing For Improved Performance

    Defining a Replication Strategy Example of Load Balancing for Improved Performance Suppose that your directory must include 1,500,000 entries in support of 1,000,000 users, and each user performs ten directory lookups a day. Also assume that you are using a messaging server that handles 25,000,000 mail messages a day, and that performs five directory lookups for every mail message that it handles.

  • Page 114: Example Replication Strategy For A Small Site

    Defining a Replication Strategy • Use the hub supplier to replicate to local sites throughout the enterprise. Replicating to local sites helps balance the work load of your servers and your WANs, as well as to ensure high availability of directory data. Assume that you want to replicate to four sites around the country.

  • Page 115: Using Replication With Other Directory Features

    Using Replication with other Directory Features • Choose a single server in one of the two buildings to contain a master copy of your directory data. This server should be placed in the building that contains the largest number of people responsible for the master copy of the directory data.

  • Page 116: Replication And Database Links

    Using Replication with other Directory Features You cannot use multi-master replication with the attribute uniqueness plug-in at all, because this plug-in can validate only attribute values on the same server not on both servers in the multi-master set. You can use the referential integrity plug-in with multi-master replication providing that this plug-in is enabled on just one master in the multi-master set.

  • Page 117: Schema Replication

    Using Replication with other Directory Features Schema Replication In all replication scenarios, before pushing data to consumer servers, the supplier server checks whether its own version of the schema is in sync with the version of the schema held on consumer servers. If the schema entries on both supplier and consumers are the same, the replication operation proceeds.
  • Page 118 Using Replication with other Directory Features Changes made to custom schema files are only replicated if the schema is updated using LDAP or the Directory Server Console. These custom schema files should be copied to each server in order to maintain the information in the same schema file on all servers.

  • Page 119: Chapter 7 Designing A Secure Directory

    Chapter 7 Designing a Secure Directory How you secure the data in Netscape Directory Server (Directory Server) affects all of the previous design areas. Your security design needs to protect the data contained by your directory and meet the security and privacy needs of your users and applications.

  • Page 120: Unauthorized Access

    About Security Threats • Unauthorized Tampering • Denial of Service The remainder of this section provides a brief overview of the most common security threats to assist you with designing your directory’s security policies. Unauthorized Access While it may seem simple to protect your directory from unauthorized access, the problem can in fact be more complicated.

  • Page 121: Denial Of Service

    Analyzing Your Security Needs Denial of Service With a denial of service attack, the attacker’s goal is to prevent the directory from providing service to its clients. For example, an attacker might simply use the system’s resources to prevent them from being used by someone else. Directory Server offers a way of preventing denial of service attacks by setting limits on the resources allocated to a particular bind DN.

  • Page 122: Determining Access Rights

    Analyzing Your Security Needs • Conducting Regular Audits • Example Security Needs Analysis Determining Access Rights When you perform your data analysis, you decide what information your users, groups, partners, customers, and applications need to access. You can take grant access rights in two ways: •...

  • Page 123: Conducting Regular Audits

    Analyzing Your Security Needs For information about encryption methods provided in the Directory Server, refer to “Password Storage Scheme,” on page 132. For information about signing data, refer to “Securing Connections With SSL,” on page 142. Conducting Regular Audits As an extra security measure, you should conduct regular audits to verify the efficiency of your overall security policy.

  • Page 124: Overview Of Security Methods

    Overview of Security Methods Overview of Security Methods Directory Server offers a number of methods that you can use to design an overall security policy that is adapted to your needs. Your security policy should be strong enough to prevent sensitive information from being modified or retrieved by unauthorized users while simple enough to administer easily.

  • Page 125: Anonymous Access

    Selecting Appropriate Authentication Methods Directory Server provides the following methods for authentication: • Anonymous Access • Simple Password • Certificate-Based Authentication • Simple Password Over TLS • Proxy Authentication The directory uses the same authentication mechanism for all users, whether they are people or LDAP-aware applications.

  • Page 126: Simple Password

    Selecting Appropriate Authentication Methods • Deny access if the user provides any non-null string for the password For example, consider the following ldapsearch command: % ldapsearch -D “cn=joe” -w secretpwd -b “example.com” cn=joe Although the directory allows anonymous access for read, Joe cannot access his own entry because it does not contain a password that matches the one he provided in the command.

  • Page 127: Certificate-Based Authentication

    Selecting Appropriate Authentication Methods NOTE The drawback of simple password authentication is that the password is sent in clear text over the wire. If a rogue user is listening, this can compromise the security of your directory because that person can impersonate an authorized user. Simple password authentication offers an easy way of authenticating users, but it is best to restrict its use to your organization’s intranet.

  • Page 128: Proxy Authentication

    Preventing Authentication by Account Inactivation Proxy Authentication Proxy authentication is a special form of authentication because the user requesting access to the directory does not bind with its own DN but with a proxy DN. The proxy DN is an entity that has appropriate rights to perform the operation requested by the user.

  • Page 129: Designing A Password Policy

    Designing a Password Policy Designing a Password Policy A password policy is a set of rules that govern how passwords are used in a given system. The password policy mechanism provided by Directory Server allows you to dictate such things as how short a password must be and whether users can reuse passwords.

  • Page 130: User-Defined Passwords

    Designing a Password Policy Often the initial passwords set by the administrator follow some sort of convention, such as the user’s initials, user ID, or the company name. Once the convention is discovered, it is usually the first value tried by a hacker trying to break in.

  • Page 131: Expiration Warning

    Designing a Password Policy The server remembers the password expiration even if you turn the password expiration feature off. This means that if you turn the password expiration option back on, passwords are valid only for the duration you set before you last disabled the feature.

  • Page 132: Password Minimum Age

    Designing a Password Policy Password Minimum Age You can configure the Directory Server to not allow users to change their passwords for time you specify. You can use this feature in conjunction with the attribute to discourage users from reusing old passwords. passwordHistory Setting the password minimum age ( ) attribute to 2 days, for...

  • Page 133: Designing A Password Policy In A Replicated Environment

    Designing a Password Policy Designing a Password Policy in a Replicated Environment Password and account lockout policies are enforced in a replicated environment as follows: • Password policies are enforced on the data master. • Account lockout is enforced on the replicas. The password policy information in your directory, such as password age, the account lockout counter, and the expiration warning counter, are all replicated.

  • Page 134: Designing Access Control

    Designing Access Control Designing Access Control Once you decide on one or more authentication schemes to establish the identity of directory clients, you need to decide how to use the schemes to protect information contained in your directory. Access control allows you to specify that certain clients have access to particular information, while other clients do not.

  • Page 135: Targets

    Designing Access Control The ACI variables are defined below: • target Specifies the entry (usually a subtree) the ACI targets, the attribute it targets, or both. The target identifies the directory element that the ACI applies to. An ACI can target only one entry, but it can target multiple attributes. In addition, the target can contain an LDAP search filter.

  • Page 136: Permissions

    Designing Access Control For every ACI, you can target only one entry or only those entries that match a single LDAP search filter. In addition to targeting entries, you can also target attributes on the entry. This allows you to set a permission that applies to only a subset of attribute values. You can target sets of attributes by explicitly naming those attributes that are targeted, or by explicitly naming the attributes that are not targeted by the ACI.

  • Page 137: Bind Rules

    Designing Access Control Bind Rules The bind rule usually indicates the bind DN subject to the permission. It can also specify bind attributes such as time of day or IP address. Bind rules allow you to easily express that the ACI applies only to a user’s own entry.

  • Page 138: Setting Permissions

    Designing Access Control Setting Permissions By default all users are denied access rights of any kind. The exception to this is the directory manager. For this reason, you must set some ACIs for your directory if you want your users to be able to access your directory. The following sections describe the access control mechanism provided by your Directory Server.

  • Page 139: When To Deny Access

    Designing Access Control By providing only allow privileges you avoid the need to set an explicit deny privilege. When to Deny Access You rarely need to set an explicit deny. However, you may find an explicit deny useful in the following circumstances: •...

  • Page 140: Using Filtered Access Control Rules

    Designing Access Control Using Filtered Access Control Rules One of the more powerful features of the Directory Server ACI model is the ability to use LDAP search filters to set access control. LDAP search filters allows you to set access to any directory entry that matches a defined set of criteria. For example, you could allow read access for any entry that contains an attribute that is set to Marketing.
  • Page 141 Designing Access Control Directory Server 6.0 provides a new feature that minimizes the number of ACIs in the directory by using macros. Macros are placeholders that are used to represent a DN, or a portion of a DN, in an ACI. You can use the macro to represent a DN in the target portion of the ACI, or in the bind rule portion, or both.

  • Page 142: Securing Connections With Ssl

    Securing Connections With SSL As your directory grows more complicated, it becomes increasingly easy to accidentally overlap ACIs in this manner. By avoiding ACI overlap, you make your security management easier while potentially reducing the total number of ACIs contained in your directory. •...

  • Page 143: Other Security Resources

    Other Security Resources Other Security Resources For more information about designing a secure directory, take a look at the following: • Netscape Security Notes http://home.netscape.com/security/notes/ • Understanding and Deploying LDAP Directory Services. T. Howes, M. Smith, G. Good, Macmillan Technical Publishing, 1999. •...
  • Page 144 Other Security Resources Netscape Directory Server Deployment Guide • December 2001...

  • Page 145: Chapter 8 Directory Design Examples

    Chapter 8 Directory Design Examples How you design your directory depends upon the size and nature of your enterprise. This chapter provides examples of how a directory can be applied within a variety of different settings. You can use these examples as a starting point for developing your own directory deployment plan.

  • Page 146: Data Design

    An Enterprise Data Design first decides the type of data it will store in the directory. To do this, example.com creates a deployment team that performs a site survey to determine example.com how the directory will be used. The deployment team determines the following: •...

  • Page 147: Directory Tree Design

    An Enterprise object class allows one attribute, the attribute. This examplePerson exampleID attribute contains the special employee number assigned to each example.com employee. In the future, can add new attributes to the object example.com examplePerson class as needed. Directory Tree Design creates a directory tree as follows: example.com •...

  • Page 148: Topology Design

    An Enterprise • creates a class of service (CoS) that provides values for the example.com attribute depending upon whether or not an entry belongs to the mailquota administrative group. This CoS gives administrators a mail quota of 500 MB while ordinary employees have a mail quota of 100 MB.

  • Page 149: Database Topology

    An Enterprise Database Topology designs a database topology in which the people branch is stored in example.com one database (DB1), the groups branch is stored in another database (DB2), and the resources branch, roles branch, and the root suffix information are stored in a third database (DB3).
  • Page 150 An Enterprise Server Topology for example.com Corporation Figure 8-3 Modify requests from the Netscape servers (such as the Netscape Calendar Server or the Netscape Delegated Administrator) are routed to the appropriate consumer server. The consumer server uses smart referrals to route the request to the supplier server responsible for the master copy of the piece of data being modified.

  • Page 151: Replication Design

    An Enterprise Replication Design decides to use a multi-master replication design to ensure the high example.com availability of its directory data. For more information about multi-master replication, refer to “Multi-Master Replication,” on page 101. The following sections provide more details about the supplier server architecture and the supplier-consumer server topology.

  • Page 152: Supplier Consumer Architecture

    An Enterprise Supplier Consumer Architecture The following diagram describes how the supplier servers replicate to each consumer in the deployment of the directory: example.com Figure 8-5 Supplier/Consumer Architecture for example.com Corporation Each of the three consumer servers is updated by the two supplier servers as shown in Figure 8-5.

  • Page 153: Security Design

    An Enterprise Security Design decides on the following security design to protect its directory data: example.com • creates an ACI that allows employees to modify their own example.com entries. Users can modify all attributes except the manager department attributes. • To protect the privacy of employee data, develops an ACI that example.com...

  • Page 154: Tuning And Optimizations

    A Multinational Enterprise and its Extranet Tuning and Optimizations optimizes its deployment of directory by doing the following: example.com • Running the utility dsktune utility provides an easy and reliable way of checking the patch dsktune levels and kernel parameter settings for your system. For more information about , see the Netscape Directory Server Installation Guide.

  • Page 155: Data Design

    A Multinational Enterprise and its Extranet has grown into an organization dispersed over three main example.com geographic locations: the US, Europe, and Asia. now has more than example.com 20,000 employees, all of which live and work in the countries where the offices are located.

  • Page 156: Schema Design

    A Multinational Enterprise and its Extranet • Many of the data elements need to accommodate data values of several different languages and characters sets. The deployment team also determines the following about the data design of the extranet: • Suppliers will need to log in to ’s directory to manage their example.com contracts with...
  • Page 157 A Multinational Enterprise and its Extranet • Each main branch under mimics the original dc=exampleCorp,dc=com directory tree design of Corporation. Under each locality, example.com creates an , an , an , and an example.com ou=people ou=groups ou=roles branch. See “Directory Tree for example.com Corporation,” on ou=resources page 148 for more information about this directory tree design.
  • Page 158 A Multinational Enterprise and its Extranet Directory Tree for example.com International’s Intranet Figure 8-7 The entry for the entry appears in LDIF as follows: l=Asia dn: l=Asia,dc=exampleCorp,dc=com objectclass: top objectclass: locality l: Asia description: includes all sites in Asia The directory tree for ’s extranet appears as follows: example.com Netscape Directory Server Deployment Guide •...

  • Page 159: Topology Design

    A Multinational Enterprise and its Extranet Directory Tree for example.com International’s Extranet Figure 8-8 Topology Design Next, designs both its database and server topologies. The following example.com sections describe each topology in more detail. Database Topology The following diagram illustrates the database topology of one of ’s example.com main localities, Europe:...
  • Page 160 A Multinational Enterprise and its Extranet Database Topology for example.com Europe Figure 8-9 The database links point to databases stored locally in each country. For example, operation requests received by the Europe server for the data under example.com branch are chained by a database link to a database on a server in Austin, l=US Texas.

  • Page 161: Server Topology

    A Multinational Enterprise and its Extranet Database Topology for example.com International’s Extranet Figure 8-10 As illustrated in Figure 8-10, the master copy of the data for is stored o=suppliers in database one, the master copy of the data for is stored in database o=partners two, and the master copy of the data for is stored in database three.
  • Page 162 A Multinational Enterprise and its Extranet Server Topology for example.com Europe Figure 8-11 ’s extranet data is mastered in Europe. This data is replicated to two example.com consumer servers in the US data center and two consumer servers in the Asia data center.

  • Page 163: Replication Design

    A Multinational Enterprise and its Extranet Server Topology for example.com International’s Extranet Figure 8-12 The hub servers replicate the data to two consumer servers in the example.com Europe data center, two consumer servers in the US data center, and example.com two consumer servers in the Asia data center.

  • Page 164: Supplier Architecture

    A Multinational Enterprise and its Extranet The hub servers are located near important directory-enable applications such as a mail server or a web server. Hub servers remove the burden of replication from the supplier servers, so the suppliers can concentrate on doing write operations. In the future, as expands and needs to add more consumer servers, the example.com additional consumers do not affect the performance of the suppliers.
  • Page 165 A Multinational Enterprise and its Extranet Each locality contains two suppliers, which share master copies of the data for that site. Each locality is therefore responsible for the master copy of its own data. Using a multi-master architecture ensures the availability of the data and helps balance the load of work managed by each supplier server.

  • Page 166: Security Design

    A Multinational Enterprise and its Extranet The same relationship as illustrated in Figure 8-14 exists between example.com Asia, and between Europe and Asia. example.com example.com example.com Security Design International builds upon its previous security design, adding the example.com following access controls to support its new multinational intranet: •...

  • Page 167: Glossary

    Glossary access control instruction See ACI. ACI Access Control Instruction. An instruction that grants or denies permissions to entries in the directory. access control list See ACL. ACL Access control list. The mechanism for controlling access to your directory. access rights In the context of access control, specify the level of access granted or denied.
  • Page 168 attribute Holds descriptive information about an entry. Attributes have a label and a value. Each attribute also follows a standard syntax for the type of information that can be stored as the attribute value. attribute list A list of required and optional attributes for a given entry type or object class.
  • Page 169 browser Software, such as Netscape Navigator, used to request and view World Wide Web material stored as HTML files. The browser uses the HTTP protocol to communicate with the host server. browsing index Otherwise known as the virtual view index, speeds up the display of entries in the Directory Server Console.
  • Page 170 CIR See consumer-initiated replication. class definition Specifies the information needed to create an instance of a particular object and determines how the object works in relation to other objects in the directory. class of service See CoS. classic CoS A classic CoS identifies the template entry by both its DN and the value of one of the target entry’s attributes.
  • Page 171 DAP Directory Access Protocol. The ISO X.500 standard protocol that provides client access to the directory. data master The server that is the master source of a particular piece of data. database link An implementation of chaining. The database link behaves like a database but has no persistent storage.
  • Page 172 DNS alias A DNS alias is a hostname that the DNS server knows points to a different host—specifically a DNS CNAME record. Machines always have one real name, but they can have one or more aliases. For example, an alias such as might point to a real machine called www.[yourdomain].[domain] where the server currently exists.
  • Page 173 HTML Hypertext Markup Language. The formatting language used for documents on the World Wide Web. HTML files are plain text files with formatting codes that tell browsers such as the Netscape Navigator how to display text, position graphics and form items, and display links to other pages. HTTP Hypertext Transfer Protocol.
  • Page 174 LDAPv3 Version 3 of the LDAP protocol, upon which Directory Server bases its schema format LDAP client Software used to request and view LDAP entries from an LDAP Directory Server. See also browser. LDAP Data Interchange Format See LDAP Data Interchange Format. LDAP URL Provides the means of locating directory servers using DNS and then completing the query via LDAP.
  • Page 175 matching rule Provides guidelines for how the server compares strings during a search operation. In an international search, the matching rule tells the server what collation order and operator to use. MD5 A message digest algorithm by RSA Data Security, Inc., which can be used to produce a short digest of data, that is unique with high probability, and is mathematically extremely hard to produce a piece of data that will produce the same message digest.
  • Page 176 network management station See NMS. NIS Network Information Service. A system of programs and data files that Unix machines use to collect, collate, and share specific information about machines, users, file systems, and network parameters throughout a network of computers. NMS Network Management Station.
  • Page 177 permission In the context of access control, the permission states whether access to the directory information is granted or denied, and the level of access that is granted or denied. See access rights. PDU Protocol Data Unit. Encoded messages which form the basis of data exchanges between SNMP devices.
  • Page 178 RDN Relative distinguished name. The name of the actual entry itself, before the entry’s ancestors have been appended to the string to form the full distinguished name. referential integrity Mechanism that ensures that relationships between related entries are maintained within the directory. referral (1) When a server receives a search or update request from an LDAP client that it cannot process, it usually sends back to the client a pointer to the LDAP sever that can process the request.
  • Page 179 root The most privileged user available on Unix machines. The root user has complete access privileges to all files on the machine. root suffix The parent of one or more sub suffixes. A directory tree can contain more than one root suffix. schema Definitions describing what types of information can be stored as entries in the directory.
  • Page 180 single-master replication The most basic replication scenario in which two servers each hold a copy of the same read-write replicas to consumer servers. In a single-master replication scenario, the supplier server maintains a change log. SIR See supplier-initiated replication. slapd LDAP Directory Server daemon or service that is responsible for most functions of a directory except replication.
  • Page 181 supplier server In the context of replication, a server that holds a replica that is copied to a different server is called a supplier for that replica. supplier-initiated replication Replication configuration where supplier servers replicate directory data to consumer servers. symmetric encryption Encryption that uses the same key for both encrypting and decrypting.
  • Page 182 virtual list view index Otherwise known as a browsing index, speeds up the display of entries in the Directory Server Console. Virtual list view indexes can be created on any branchpoint in the directory tree to improve display performance. X.500 standard The set of ISO/ITU-T documents outlining the recommended information model, object classes and attributes used by directory server implementation.

  • Page 183: Index

    Index required and allowed 54 values 54 access attribute-data pair 25, 42 anonymous 124, 125 audits, for security 123 determining general types of 124 authentication methods 124 precedence rule 138 anonymous access 125 access control certificate-based 127 password protection and 132 proxy authentication 128 access control information (ACI) 134 simple password 126...
  • Page 184 database links 88 deny permissions 138 change log 98 directory applications 29 browsers 29 checking password syntax 131 email 29 class of service (CoS) 72 directory data classic 74 access 35 definition entry 73 examples of 26 indirect 73 mastering 32 pointer 73 ownership 34 target entry 73...
  • Page 185 email applications 29 global directory services 15 encryption group attribute 139 password 132 Salted SHA 132 SHA 132 enterprise deployment example 145 entries 20 naming 67 high availability 109, 110 group entries 69 hub supplier 103 non-person 70 organization 69 person 67 entry distribution 78 multiple databases 79...
  • Page 186 Lightweight Directory Access Protocol (LDAP) 15 directory services 15 password load balancing simple the network 111 over TLS 127 password policies attributes 129 change after reset 129 design 129 expiration warning 131 mail attribute 68 overview 129 managed roles 71 password expiration 130 minimum length of passwords 131 password history 132...
  • Page 187 referrals 82–88 Salted SHA encryption 132 branching to support 64 schema 39–55 compared to chaining 89 adding new attributes 50 default 84 assigning OIDs 47 LDAP 83 best practices 52 smart referrals 84 checking 54 Replication 104 consistency 53–55 custom files 51 replication 95–117 deleting elements 50 access control 115...
  • Page 188 styles, in this book 11 sub suffix 80 warning, password expiration 131 substring index 93 suffix naming conventions 59 root suffix 80 sub suffix 80 supplier server 98 supplier servers 97 surname attribute 54 syntax password 131 target entry 73 telephoneNumber attribute 54 template entry 73 terms, in this book 11...

This manual is also suitable for:

Netscape directory server 6.0

Table of Contents