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

Netscape DIRECTORY SERVER 7.0 - DEPLOYMENT Deployment Manual

Hide thumbs
Table of Contents

Advertisement

Quick Links

Download this manual
Deployment Guide
Netscape Directory Server
Version 7.0
October 2004

Advertisement

Table of Contents
loading

Related Manuals for Netscape NETSCAPE DIRECTORY SERVER 7.0 - DEPLOYMENT

Summary of Contents for Netscape NETSCAPE DIRECTORY SERVER 7.0 - DEPLOYMENT

  • Page 1 Deployment Guide Netscape Directory Server Version 7.0 October 2004...
  • 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.

  • 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 Using Chaining ..............98 Deciding Between Referrals and Chaining .
  • Page 7 Denial of Service ..............135 Analyzing Your Security Needs .
  • Page 8 SASL Authentication and Encryption ........... . 163 Other Security Resources .

  • 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 9) • 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 • 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. • Chaining and referrals —...

  • Page 11: Conventions Used In This Guide

    Conventions Used in This Guide Conventions Used in This Guide This guide uses the following conventions: • — This typeface is used for any text that appears on the Monospaced font computer screen or text that you should type. It is also used for filenames, functions, and examples.
  • Page 12 Related Information • Netscape Directory Server Administrator’s Guide. Contains procedures for the day-to-day maintenance of your directory service. Includes information on configuring server-side plug-ins. • Netscape Directory Server Configuration, Command, and File Reference. Provides information about using the command-line scripts shipped with Directory Server.

  • 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: Overview Of Directory Server Architecture

    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 The Server Front-End

    Introduction to Directory Server • 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-End The server front-end of Directory Server manages communications with directory client programs. Directory Server functions as a daemon on UNIX systems and as a service on Windows.

  • Page 18: Overview Of The Basic Directory Tree

    Introduction to Directory Server 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. At installation, Directory Server creates a default directory tree.

  • Page 19: Directory Server Data Storage

    Introduction to Directory Server You can build on the default directory tree to add any data relevant to your directory installation. An example of a directory tree for example.com Corporation follows: For more information about directory trees, refer to chapter 4, “Designing the Directory Tree.”...

  • Page 20: About Directory Entries

    Introduction to Directory Server NOTE For database files that are larger than 2Gbytes, the machine must be configured to support large files. You can do this by choosing on Solaris and largefile vxfs filesystem with option on HP UX. Linux handles largefiles large files without having to configure the filesystem.

  • Page 21: Distributing Directory Data

    Directory Design Overview However, all entries are not automatically returned in response to an LDAP search. This is because Directory Server supports a new kind of entry, entries of the object class . An entry represents an administrative object; ldapsubentry ldapsubentry for example, entries used to define a role or a class of service are of the type.

  • 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 • Office contact information for the various sites within your enterprise 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.

  • 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 When you examine the applications that will use your directory, look at the types of information each application uses. The following table gives an example of applications and the information used by each: Table 2-1 Application Data Needs Application Class of Data Data...

  • Page 31: Characterizing Your Directory Data

    Performing a Site Survey • Identify the tools and processes that are information sources. 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. •...

  • Page 32: Determining Level Of Service

    Performing a Site Survey For example, you can create a table that characterizes your directory data as follows: Directory Data Characteristics Table 2-3 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 supports multi-master configurations, in which more than one server is the master source for the same piece of data.

  • Page 34: Determining Data Ownership

    Performing a Site Survey How you maintain master copies of your data depends on your specific needs. However, regardless of how you maintain data masters, keep it simple and consistent. For example, you should not attempt to master data in multiple sites, then automatically exchange data between competing applications.

  • Page 35: Determining Data Access

    Performing a Site Survey • Create roles that give groups of people read or write access privileges. For example, you might create roles for human resources, finance, or accounting. Allow each of these roles to have read access, write access, or both to the data needed by the group, such as salary information, government identification number (in the US, Social Security Number), and home phone numbers and address.
  • Page 36 Performing a Site Survey You can set up access control so that the client must log in to (or bind to) the directory to read specific information. Unlike anonymous access, this form of access control ensures that only members of your organization can view directory 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,“How to Plan Your Directory Data,” generated information about 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 person class. This object class allows several attributes, one of which is the attribute, which describes the full name of the person.

  • Page 47: When To Extend Your Schema

    Customizing the Schema Your custom object classes and attributes are defined in the following file: serverRoot/slapd-serverID/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 •...

  • 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 that attributes that are not will appear in the read-only 'user defined' section of 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 'user defined'...

  • 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 • Support for the applications using your directory. • 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.

  • Page 59: Suffix Naming Conventions

    Designing Your Directory Tree By default, the standard Directory Server deployment contains multiple suffixes, one for storing data and the others for data needed by internal directory operations (such as configuration information and your directory schema). For more information on these standard directory suffixes, see the Netscape Directory Server Administrator’s Guide.

  • Page 60: Naming Multiple Suffixes

    Designing Your Directory Tree Using an organization name followed by a country designation is typical of the X.500 naming convention for suffixes. 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.

  • Page 61: Branching Your Directory

    Designing Your Directory Tree Branching Your Directory Design your hierarchy to avoid problematic name changes. The flatter a namespace is, the less likely the names are to change. The likelihood of a name changing is roughly proportional to the number of components in the name that can potentially change.

  • Page 62: Identifying Branch Points

    Designing Your Directory Tree • ou=services A directory tree organized using these objects might appear as shown below. 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 organization(o) organizationalUnit(ou)
  • 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 Table 4-1 Traditional DN Branch Point Attributes Attribute Name Definition A country name. An organization name. This attribute is typically used to represent a large divisional branching such as a corporate division, academic discipline (the humanities, the sciences), subsidiary, or other major branching within the enterprise.
  • Page 65 Designing Your Directory Tree For example, in an enterprise environment, you can organize your directory tree so that it corresponds to the network names in your enterprise. Network names tend not to change, so the directory tree structure will be stable. Further, using network names to create the top level branches of your directory tree is useful when you use replication to tie together different Directory Servers.

  • Page 66: Access Control Considerations

    Designing Your Directory Tree After creating the initial structure of their directory tree, they create additional branches as follows: 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 You can set access controls based on the directory content rather than the directory tree. The ACI filtered target mechanism lets you define a single access control rule stating that a directory entry has access to all entries containing a particular attribute value.

  • Page 68: Naming Person Entries

    Designing Your Directory Tree Naming Person Entries The person entry’s name, the DN, must be unique. Traditionally, distinguished names use the , or , attribute to name their person entries. That is, commonName an entry for a person named Babs Jensen might have the distinguished name of: cn=Babs Jensen,dc=example,dc=com While allowing you to recognize instantly the person associated with the entry, it might not be unique enough to exclude people with identical names.

  • Page 69: Naming Group Entries

    Designing Your Directory Tree Whatever you decide to use for an attribute-data pair for person entry RDNs, you should make sure that they are unique, permanent values. Person entry RDNs should also be readable. For example, uid=bjensen, dc=example,dc=com preferable to because recognizable DNs uid=b12r56A, dc=example,dc=com simplify some directory tasks, such as changing directory entries based on their...

  • Page 70: Naming Organization Entries

    Designing Your Directory Tree • A Directory Server role—Roles are a new feature of Directory Server that unify the static and dynamic group concept. Refer to “About Roles,” on page 71, for more information. In a deployment containing hosted organizations, we recommend using the object class to contain the values naming the members of groupOfUniqueNames groups used in directory administration.

  • Page 71: Grouping Directory Entries

    Grouping Directory Entries Grouping Directory Entries Once you have created entries, you can group them for ease of administration. The Directory Server supports several methods for grouping entries and sharing attributes between entries: • Using roles • Using class of service The following sections describe each of these mechanisms in more detail.

  • Page 72: Deciding Between Roles And Groups

    Grouping Directory Entries • Remove a particular role from a given entry. Each role has members, entries that possess the role. You can specify members either explicitly (meaning each entry contains an attribute associating it with a role) or dynamically (by creating a filter that assigns entries to roles depending upon an attribute contained by the entry).

  • Page 73: About Class Of Service

    Grouping Directory Entries About Class of Service A class of service (CoS) allows you to share attributes between entries in a way that is invisible to applications. With CoS, some attribute values may not be stored with the entry itself. Instead, they are generated by class of service logic as the entry is sent to the client application.

  • Page 74: Directory Tree Design Examples

    Directory Tree Design Examples You can use different types of CoS depending upon how you want the value of your dynamic attributes to be generated. There are three types of CoS: • Pointer CoS — A pointer CoS identifies the template entry using the template DN only.

  • Page 75: Directory Tree For An Isp

    Directory Tree Design Examples However, some administrators feel that this is stylistically awkward, so instead you could use the ) attribute to represent different countries: locality Directory Tree for an ISP Internet service providers (ISPs) may support multiple enterprises with their directories.

  • Page 76: Virtual Directory Information Tree Views

    Virtual Directory Information Tree Views Virtual Directory Information Tree Views Directory Server supports a new concept for hierarchical navigation and organization of directory information, the virtual directory information tree views or virtual DIT views. • Overview • Introduction to Virtual DIT Views •...

  • Page 77: Overview

    Virtual Directory Information Tree Views Overview When considering directory namespace, you have the choice of creating either of the following: • A hierarchical directory information tree. • A flat directory information tree. The hierarchical DIT is useful for navigating the directory but is cumbersome and time consuming to change.

  • Page 78: Introduction To Virtual Dit Views

    Virtual Directory Information Tree Views This view of the organization serves well in many cases, but having just this one view can be very limiting for directory navigation and management. For example, an organization hierarchy is fine if you are looking for entries belonging to people in the Accounts department.
  • Page 79 Virtual Directory Information Tree Views For information about adding and modifying entries, refer to chapter 2 , “Creating Directory Entries,” in the Netscape Directory Server Administrator’s Guide Figure 4-2 A Combined DIT With Added Features Using Views The DIT shown in Figure 4-2 illustrates what happens when the two DITs shown in Figure 4-1 are combined using views.
  • Page 80 Virtual Directory Information Tree Views Figure 4-3 A DIT With a Virtual DIT View Hierarchy The DIT illustrated in Figure 4-3 shows a view hierarchy. • The sub-tree contains the real entries. ou=People Entry A Entry B • The subtree is a view hierarchy.

  • Page 81: Advantages Of Using Virtual Dit Views

    Virtual Directory Information Tree Views Advantages of Using Virtual DIT Views Your deployment decisions become easier with virtual DIT views: • Views facilitate use of flat namespace for entries because virtual DIT views provide navigational and managerial support similar to the ones provided by traditional hierarchies.

  • Page 82: Example Of Virtual Dit Views

    Virtual Directory Information Tree Views Example of Virtual DIT Views The LDIF entries below show a virtual DIT view hierarchy that is based on location. Any entry which resides below and fits the view dc=example,dc=com description will appear in this view, organized by location. dn: ou=Location Views,dc=example,dc=com objectclass: top objectclass: organizationalUnit...

  • Page 83: Views And Other Directory Features

    Virtual Directory Information Tree Views view entry itself does not contain ou=Location Views, dc=example,dc=com a filter. This feature facilitates hierarchical organization without the requirement to restrict the entries contained in the view further. Any view may omit the filter. Although the example filters are very simple, the filter used may be of arbitrary complexity.

  • Page 84: Effects Of Virtual Views On Performance

    Virtual Directory Information Tree Views To clarify any doubts that you have about the effects of views on searching, understand that if the base of the search is a view and the scope of the search is not a base, then it is a views-based search. Otherwise, it is a conventional search. For example, if you perform a search with a base of , then no dc=example,dc=com...

  • Page 85: Other Directory Tree Resources

    Other Directory Tree Resources disguise the true location of an entry by changing the DN of the entry to conform to the views hierarchy. This is by design — many applications would not function if the true location of an entry is disguised., such as those applications that rely on the DN to identify a unique entry.
  • Page 86 Other Directory Tree Resources Netscape Directory Server Deployment Guide • October 2004...

  • Page 87: 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 88: 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 89: 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. In that instance, your directory tree appears as follows: You can also store the data of the three suffixes in three separate databases, as shown below:...

  • Page 90: 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 91 Distributing Your Data The suffixes that result contain the following entries: 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 the data in the...

  • Page 92: About Knowledge References

    About Knowledge References entry represents a root suffix. The entry for each hosted dc=example,dc=com ISP is also a root suffix ( ). The and the o=example_a o=example_b ou=people branches are sub suffixes under each root suffix. ou=groups About Knowledge References Once you have distributed your data over several databases, you need to define the relationship between the distributed data.

  • Page 93: Using Referrals

    About Knowledge References Using Referrals A referral is a piece of information returned by a server that tells a client application which server to contact to proceed with an operation request. This redirection mechanism occurs when a client application requests a directory entry that does not exist on the local server.

  • Page 94: About Default Referrals

    About Knowledge References The referral tells the client application to contact the host europe.example.com on port and submit a search rooted at ou=people,l=europe,dc=example,dc=com The LDAP client application you use determines how a referral is handled. Some client applications automatically retry the operation on the server to which they have been referred.

  • Page 95: Smart Referrals

    About Knowledge References Smart Referrals Directory Server also allows you to configure your directory to use smart referrals. Smart referrals allow you to associate a directory entry or directory tree to a specific LDAP URL. Associating directory entries to specific LDAP URLs allows you to refer requests to any of the following: •...
  • Page 96 About Knowledge References You can use the same mechanism to redirect queries to a different server that uses a different namespace. For example, an employee working in the Italian office of Corporation makes a request to the European directory for the example.com phone number of an employee in America.

  • Page 97: Tips For Designing Smart Referrals

    About Knowledge References NOTE Creating a referral from one namespace to another works only for clients whose searches are based at that distinguished name. Other kinds of operations, such as searches below , will not be performed correctly. ou=people,o=example,c=US For more information on LDAP URLS and on how to include smart URLs on Directory Server entries, see Netscape Directory Server Administrator’s Guide.

  • Page 98: Using Chaining

    About Knowledge References Limit your referral usage to handle redirection at the suffix level of your directory tree. Smart referrals allow you to redirect lookup requests for leaf (non-branch) entries to different servers and DNs. As a result, you may be tempted to use smart referrals as an aliasing mechanism, leading to a complex and difficult method to secure directory structure.
  • Page 99 About Knowledge References Each database link is associated to a remote server holding data. You can also configure alternate remote servers containing replicas of the data for the database link to use when there is a failure. For more information on configuring database links, refer to the Netscape Directory Server Administrator’s Guide.

  • Page 100: Deciding Between Referrals And Chaining

    About Knowledge References Deciding Between Referrals and Chaining Both methods of linking your directory partitions have advantages and disadvantages. The method, or combination of methods, you choose depends upon the specific needs of your directory. The major difference between the two knowledge references is the location of the intelligence that knows how to locate the distributed information.
  • Page 101 About Knowledge References In the illustration above, the client application performs the following steps: The client application first binds with server A. Server A contains an entry for the client that provides a user name and password, so it returns a bind acceptance message. In order for the referral to work, the client entry must be present on server A.
  • Page 102 About Knowledge References In the illustration above, 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. Server A does not contain an entry corresponding to the client application. Instead, it contains a database link to server B, which contains the actual entry of the client.
  • Page 103 About Knowledge References 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. Server A does not contain an entry corresponding to the client application. Instead, it contains a database link to server B, which contains the actual entry of the client.

  • Page 104: 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 105: Evaluating The Costs Of Indexing

    Using Indexes to Improve Database Performance • Substring index — The substring index allows searches against substrings within entries. For example, a search for would match common cn=*derson names containing this string (such as Bill Anderson, Norma Henderson, and Steve Sanderson). •...
  • Page 106 Using Indexes to Improve Database Performance Netscape Directory Server Deployment Guide • October 2004...

  • Page 107: 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 108: Replication Concepts

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

  • Page 109: Unit Of Replication

    Introduction to Replication Unit of Replication The smallest unit of replication is a database. This means that you can replicate an entire database but not a subtree within a database. Therefore, when you create your directory tree, you must take your replication plans into consideration. For more information on how to set up your directory tree, refer to chapter 4, “Designing the Directory Tree.”...

  • Page 110: Change Log

    Introduction to Replication • Initiate replication to consumer servers. The supplier server is always responsible for recording the changes made to the read-write replicas that it manages, so the supplier server makes sure that any changes are replicated to consumer servers. A consumer server must: •...

  • Page 111: Data Consistency

    Introduction to Replication • How the connection is secured (SSL, client authentication, or no SSL). Data Consistency Consistency refers to how closely the contents of replicated databases match each other at a given point in time. When you set up replication between two servers, part of the configuration is to schedule updates.

  • Page 112: Common Replication Scenarios

    Common Replication Scenarios Common Replication Scenarios You need to decide how the updates flow from server to server and how the servers interact when propagating updates. There are four basic scenarios: • Single-Master Replication • Multi-Master Replication • Cascading Replication •...

  • Page 113: Multi-Master Replication

    Common Replication Scenarios Figure 6-1 Single-Master Replication 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 114 Common Replication Scenarios Multiple servers can have master copies of the same data, but, within the scope of a single replication agreement, there is only one supplier server and one consumer. That means that 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 115 Common Replication Scenarios Figure 6-3 Multi-Master Replication Configuration (Four Suppliers) Figure 6-4 illustrates a topology where each supplier server feeds data to two other supplier servers (and to the consumer servers). Notice that there are only eight replication agreements among the four supplier servers, as opposed to the twelve agreements shown for the topology in Figure 6-3.
  • Page 116 Common Replication Scenarios Figure 6-4 Multi-Master Replication Configuration (Four Suppliers) The total number of supplier servers you can have in any replication environment is limited to four. However, the number of consumer servers that hold the read-only replicas is not limited. NOTE Directory Server supports four-way multi-master replication;...

  • Page 117: Cascading Replication

    Common Replication Scenarios Figure 6-5 Replication Traffic in a Multi-Master Environment 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 118 Common Replication Scenarios This cascading replication scenario is illustrated in Figure 6-6. Figure 6-6 Cascading Replication Scenario The same scenario is illustrated from a different perspective in Figure 6-7, below. It shows how the replicas are configured on each server (read-write or read-only) and which servers maintain a change log.

  • Page 119: Mixed Environments

    Common Replication Scenarios Figure 6-7 Replication Traffic and Change logs in Cascading Replication 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-8.
  • Page 120 Common Replication Scenarios Figure 6-8 Combined Multi-Master and Cascading Replication Netscape Directory Server Deployment Guide • October 2004...

  • Page 121: 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 122: 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 123: Using Replication For High Availability

    Defining a Replication Strategy • Server threads — Each replication agreement consumes one server thread. So, the number of threads available to client applications is reduced, possibly affecting the server performance for the client applications. • File descriptors — The number of file descriptors available to the server is reduced by the change log (one file descriptor) and each replication agreement (one file descriptor per agreement).

  • Page 124: 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 125: Example Of Network Load Balancing

    Defining a Replication Strategy One of the more important reasons to replicate directory data is to balance the workload 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 126 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 supplier server for the locally managed data.

  • Page 127: 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 128: 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 ensuring high availability of directory data. Assume that you want to replicate to four sites around the country.

  • Page 129: Using Replication With Other Directory Features

    Using Replication with Other Directory Features Your replication strategy follows: • 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 130: 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 multiple servers in the multi-master set. • Referential Integrity Plug-in You can use the referential integrity plug-in with multi-master replication providing that this plug-in is enabled on just one supplier in the multi-master set.

  • Page 131: 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 132 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 133: 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 134: About Security Threats

    About Security Threats About Security Threats There are many potential threats to the security of your directory. Understanding the most common threats helps you plan your overall security design. The most typical threats to directory security fall into the following three categories: •...

  • Page 135: Unauthorized Tampering

    Analyzing Your Security Needs Unauthorized Tampering If intruders gain access to your directory or intercept communications between Directory Server and a client application, they have the potential to modify (or tamper with) your directory data. Your directory is rendered useless if the data can no longer be trusted by clients or if the directory itself cannot trust the modifications and queries it receives from clients.

  • Page 136: Determining Access Rights

    Analyzing Your Security Needs • To protect sensitive data regarding employees or your business from general access. If your directory serves an extranet or supports e-commerce applications over the Internet, in addition to the previous points, your concerns are: • To offer your customers a guarantee of privacy.

  • Page 137: Ensuring Data Privacy And Integrity

    Analyzing Your Security Needs For information about checking the identity of users, refer to “Selecting Appropriate Authentication Methods,” on page 139. For information about restricting access to directory information, refer to “Designing Access Control,” on page 154. Ensuring Data Privacy and Integrity When you are using the directory to support exchanges with business partners over an extranet or to support e-commerce applications with customers on the Internet, you must ensure the privacy and the integrity of the data exchanged.

  • Page 138: Overview Of Security Methods

    Overview of Security Methods • Information belonging to corporate customers. • Information pertaining to individual subscribers. needs the following access controls: example.com • Provide access to the directory administrators of hosted companies ) to their own directory information. example_a example_b •...

  • Page 139: Selecting Appropriate Authentication Methods

    Selecting Appropriate Authentication Methods • 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.

  • Page 140: Simple Password

    Selecting Appropriate Authentication Methods Therefore, if you attempt to block a specific user or group of users from seeing some kinds of directory data, but you have allowed anonymous access to that data, then those users can still access the data simply by binding to the directory anonymously.

  • Page 141: Certificate-Based Authentication

    Selecting Appropriate Authentication Methods The bind DN often corresponds to the entry of a person. However, some directory administrators find it useful to bind as an organizational entry rather than as a person. The directory requires the entry used to bind to be of an object class that allows the attribute.

  • Page 142: Simple Password Over Tls

    Selecting Appropriate Authentication Methods For more information about certificates and SSL, see Managing Servers with Netscape Console. Simple Password over TLS When a secure connection is established between Directory Server and a client application using SSL or the Start TLS operation, the server can demand an extra level of authentication by requesting a password.

  • Page 143: Preventing Authentication By Account Inactivation

    Preventing Authentication by Account Inactivation NOTE The proxy mechanism is very powerful and must be used sparingly. Proxy rights are granted within the scope of the ACL, and there is no way to restrict who can be impersonated by an entry that has the proxy right—that is, when you grant a user proxy rights, that user has the ability to proxy for any user under the target;...

  • Page 144: How Password Policy Works

    Designing a Password Policy How Password Policy Works Directory Server supports fine-grained password policy, which enables you to define password policies at the subtree and user level. This allows the flexibility of defining a password policy for: • The entire directory (similar to the previous releases of Directory Server). Such a policy is known as the global password policy.
  • Page 145 Designing a Password Policy For a subtree (for example, ), the following ou=people, dc=example, dc=com changes are required: • Add a container entry ( ) at the subtree level for holding nsPwPolicyContainer various password policy-related entries for the subtree and all its children. For example: dn: cn=nsPwPolicyContainer, ou=people, dc=example, dc=com objectClass: top...
  • Page 146 Designing a Password Policy For a user (for example, ), the uid=jdoe, ou=people, dc=example, dc=com following changes are required: • Add a container entry ( ) at the parent level for holding nsPwPolicyContainer various password policy related entries for the user and its children. For example: dn: cn=nsPwPolicyContainer, ou=people, dc=example, dc=com objectClass: top...
  • Page 147 Designing a Password Policy • To determine whether a local policy is defined for a subtree or user, the server checks for the attribute in the corresponding user entry. If pwdPolicysubentry the attribute is present, the server enforces the local password policy configured for the user.
  • Page 148 Designing a Password Policy Figure 7-1 Flow Diagram Depicting How Password Policy Checking Works Netscape Directory Server Deployment Guide • October 2004...

  • Page 149: Password Policy Attributes

    Designing a Password Policy Note that in addition to BIND requests, password policy also occurs during ADD and MODIFY operations if the attribute (which is explained in the userPassword section that follows) is present in the request. • If you try to modify , the password minimum age policy is userPassword activated, and it is too soon to allow the change, the server will return a...

  • Page 150: Password Change After Reset

    Designing a Password Policy • Password Storage Scheme Password Change after Reset The Directory Server password policy lets you decide whether users must change their passwords after the first login or after the password is reset by the administrator. 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.

  • Page 151: Password Expiration

    Designing a Password Policy Password Expiration You can set your password policy so that users can use the same passwords indefinitely. Or you can set your policy so that passwords expire after a given time. In general, the longer a password is in use, the more likely it is to be discovered. On the other hand, if passwords expire too often, users may have trouble remembering them and resort to writing their passwords down.

  • Page 152: Password Length

    Designing a Password Policy By default, password syntax checking is turned off. Password Length The Directory Server allows you to specify a minimum length for user passwords. In general, shorter passwords are easier to crack. You can require passwords that are from 2 to 512 characters.

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

    Designing a Password Policy • Cleartext (no encryption). • Secure Hash Algorithm (SHA). • Salted Secure Hash Algorithm (SSHA). This encryption method is the default. • UNIX crypt algorithm. Although passwords stored in the directory can be protected through the use of access control information (ACI) instructions, it is still not a good idea to store cleartext passwords in the directory.

  • Page 154: Designing An Account Lockout Policy

    Designing Access Control Designing an Account Lockout Policy Once you have established a password policy for your directory, you can protect your user passwords from potential threats by configuring an account lockout policy. The lockout policy works in conjunction with the password policy to provide further security.

  • Page 155: About The Aci Format

    Designing Access Control About the ACI Format When designing your security policy, it is helpful to understand how ACIs are represented in your directory. It is also helpful to understand what permissions you can set in your directory. This section gives you a brief overview of the ACI mechanism.

  • Page 156: Targets

    Designing Access Control Targets You must decide what entry is targeted by every ACI you create in your directory. If you target a directory entry that is a directory branch point, then that branch point, as well as all of its child entries, are included in the scope of the permission.

  • Page 157: Bind Rules

    Designing Access Control • Compare — Indicates whether the data may be used in comparison operations. Compare implies the ability to search, but actual directory information is not returned because of the search. Instead, a simple Boolean value is returned that indicates whether the compared values match.

  • Page 158: Setting Permissions

    Designing Access Control • Parent — If the bind DN is the immediate parent entry, then the bind rule is true. This allows you to grant specific permissions that allow a directory branch point to manage its immediate child entries. •...

  • Page 159: When To Deny Access

    Designing Access Control Limit the scope of your allow access rules to include only the smallest possible subset of users or client applications. For example, you can set permissions that allow users to write to any attribute on their directory entry, but then deny all users except members of the Directory Administrators group the privilege of writing to attribute.

  • Page 160: Where To Place Access Control Rules

    Designing Access Control If you are allowing a person or group of people to manage some part of the directory tree, but you want to make sure that they do not modify some aspect of the tree, use an explicit deny. For example, if you want to make sure the Mail Administrators do not allow write access to the common name attribute, then set an ACI that explicitly denies write access to the common name attribute.

  • Page 161: Using Acis: Some Hints And Tricks

    Designing Access Control Using ACIs: Some Hints and Tricks The following are some ideas that you should keep in mind when you implement your security policy. They can help to lower the administrative burden of managing your directory security model and improve your directory’s performance characteristics.

  • Page 162: Database Encryption

    Database Encryption Because search filters do not directly name the object that you are managing access for, their use can result in unexpected surprises, especially as your directory becomes more complex. If you are using search filters in ACIs, run an operation ldapsearch using the same filter to make sure you know what the results of the changes mean to...

  • Page 163: Securing Connections With Ssl

    Securing Connections with SSL Database encryption allows individual attributes to be encrypted as they are stored in the database. When configured, every instance of a particular attribute, even index data, will be encrypted and can only be accessed via a secure channel, such as SSL/TLS.

  • Page 164: Other Security Resources

    Other Security Resources To establish a secure session, Directory Server utilizes the GSS-API mechanism to encrypt data during sessions, allowing UNIX LDAP clients to authenticate with the server using Kerberos version 5 credentials. NOTE SASL data encryption is not supported for client connections that use SSL/TLS.

  • Page 165: 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 166: 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 167: 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 168: 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 169: 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 170 An Enterprise Figure 8-3 Server Topology for example.com Corporation 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 171: 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 113. The following sections provide more details about the supplier server architecture and the supplier-consumer server topology.

  • Page 172: 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 Supplier/Consumer Architecture for example.com Corporation Figure 8-5 Each of the three consumer servers is updated by the two supplier servers as shown in Figure 8-5.

  • Page 173: 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 174: 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 175: 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 176: 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 177 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 168 for more information about this directory tree design.

  • Page 178: Topology Design

    A Multinational Enterprise and Its Extranet 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 Figure 8-8 Directory Tree for example.com International’s Extranet...
  • Page 179 A Multinational Enterprise and Its Extranet Figure 8-9 Database Topology for example.com Europe 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 180: Server Topology

    A Multinational Enterprise and Its Extranet Figure 8-10 Database Topology for example.com International’s Extranet As illustrated in Figure 8-10, the master copy of the data for o=suppliers stored in database one, the master copy of the data for is stored in o=partners database two, and the master copy of the data for is stored in database...
  • Page 181 A Multinational Enterprise and Its Extranet Figure 8-11 Server Topology for example.com Europe ’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 182: Replication Design

    A Multinational Enterprise and Its Extranet Figure 8-12 Server Topology for example.com International’s Extranet 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, example.com and two consumer servers in the Asia data center.

  • Page 183: Supplier Architecture

    A Multinational Enterprise and Its Extranet • Hub servers that contain read-only copies of the data will be used to replicate data to consumer servers. 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.
  • Page 184 A Multinational Enterprise and Its Extranet Figure 8-13 Supplier Architecture for example.com Europe 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 185: Security Design

    A Multinational Enterprise and Its Extranet Figure 8-14 Supplier/Supplier Architecture for example.com Europe and example.com US 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 186 A Multinational Enterprise and Its Extranet • decides to use macro ACIs to minimize the number of ACIs in example.com the directory. uses a macro to represent a DN in the target or bind rule portion example.com of the ACI. When the directory gets an incoming LDAP operation, the ACI macros are matched against the resource targeted by the LDAP operation.

  • Page 187: Glossary

    Glossary access control instruction See ACI. ACI Also Access Control Instruction. An instruction that grants or denies permissions to entries in the directory. access control list See ACL. ACL Also Access Control List. The mechanism for controlling access to your directory.
  • Page 188 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 189 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 Also virtual view index. Speeds up the display of entries in the Directory Server Console.
  • Page 190 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 191 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 192 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 193 hostname A name for a machine in the form machine.domain.dom, which is translated into an IP address. For example, is the machine www.example.com in the subdomain domain. example 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 to display links to other pages.
  • Page 194 knowledge reference Pointers to directory information stored in different databases. LDAP Lightweight Directory Access Protocol. Directory service protocol designed to run over TCP/IP and across multiple platforms. LDAPv3 Version 3 of the LDAP protocol, upon which Directory Server bases its schema format.
  • Page 195 mapping tree A data structure that associates the names of suffixes (subtrees) with databases. master agent See SNMP master agent. 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.
  • Page 196 nested role Allows the creation of roles that contain other roles. network management application Network Management Station component that graphically displays information about SNMP managed devices (which device is up or down, which and how many error messages were received, etc.). network management station See NMS.
  • Page 197 password file A file on Unix machines that stores Unix user login names, passwords, and user ID numbers. It is also known as because of /etc/passwd where it is kept. password policy A set of rules that governs how passwords are used in a given directory.
  • Page 198 RAM Random access memory. The physical semiconductor-based memory in a computer. Information stored in RAM is lost when the computer is shut down. rc.local A file on Unix machines that describes programs that are run when the machine starts. It is also called because of its location.
  • Page 199 role An entry grouping mechanism. Each role has members, which are the entries that possess the role. role-based attributes Attributes that appear on an entry because it possesses a particular role within an associated CoS template. root The most privileged user available on Unix machines. The root user has complete access privileges to all files on the machine.
  • Page 200 service A background process on a Windows machine that is responsible for a particular system task. Service processes do not need human intervention to continue functioning. SIE Server Instance Entry. The ID assigned to an instance of Directory Server during installation. Simple Authentication and Security Layer See SASL.
  • Page 201 suffix The name of the entry at the top of the directory tree, below which data is stored. Multiple suffixes are possible within the same directory. Each database only has one suffix. superuser The most privileged user available on Unix machines. The superuser has complete access privileges to all files on the machine.
  • Page 202 uid A unique number associated with each user on a Unix system. URL Uniform Resource Locator. The addressing system used by the server and the client to request documents. It is often called a location. The format of a URL .

  • Page 203: Index

    Index operational 20 required and allowed 54 access values 54 anonymous 139 attribute-data pair 25, 42 determining general types of 139 audits, for security 137 precedence rule 158 authentication access control SASL 163 password protection and 153 authentication methods 139 access control information (ACI) 154 anonymous access 139 bind rules 155, 156, 157...
  • Page 204 certificate-based authentication 141 default permissions 158 chaining 98–99 default referrals 94 compared to referrals 100 definition entry 73 database links 98 deleting schema 50 change log 110 deleting schema elements 50 checking password syntax 151 deny permissions 158 class of service (CoS) 73 directory applications 29 classic 74 browsers 29...
  • Page 205 DIT. See directory tree DNS 13 filtered access control rules 160 filtered roles 72 fine-grained password policy 144 fonts, in this book 11 four-way multi-master replication 114 email applications 29 employeeNumber 68 encryption attribute 162 database 163 global directory services 15 password 152 Salted SHA 153 global password policy 144...
  • Page 206 network, load balancing 125 ns-newpwpolicy.pl script 146 knowledge references 92 nsRole 71 chaining 98 nsview 78 referrals 93 nsviewfilter 78 large database files 20 object class LDAP, See Lightweight Directory Access Protocol defining in schema 48 LDAP referrals 93 standard 44 LDAPv3 schema 40 object identifier.
  • Page 207 user level 144 change log 110 consumer-initiated 109 password storage scheme data consistency 111 configuring 152 data master 33 passwords database links 130 changing after reset 150 examples encryption of 152 large sites 128 expiration 151 load balancing server traffic 127 expiration warning 151 local data management 125 grace logins after expiration 151...
  • Page 208 deleting elements 50 root suffix 90 extending 47 sub suffix 90 LDAPv3 40 supplier server 109 naming attributes 48 surname attribute 54 naming elements 48 syntax naming object classes 48 password 151 Netscape standard 40–44 object class strategies 48 schema replication 131 secure sockets layer 142 security conducting audits 137...

This manual is also suitable for:

Netscape directory server 7.0

Table of Contents