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

Netscape DIRECTORY SERVER 6.2 - DEPLOYMENT Deployment Manual

Hide thumbs
Table of Contents

Advertisement

Quick Links

Download this manual
Deployment Guide
Netscape Directory Server
Version 6.2
December 2003

Advertisement

Table of Contents
loading
Need help?

Need help?

Do you have a question about the NETSCAPE DIRECTORY SERVER 6.2 - DEPLOYMENT and is the answer not in the manual?

Questions and answers

Related Manuals for Netscape NETSCAPE DIRECTORY SERVER 6.2 - DEPLOYMENT

Summary of Contents for Netscape NETSCAPE DIRECTORY SERVER 6.2 - DEPLOYMENT

  • Page 1 Deployment Guide Netscape Directory Server Version 6.2 December 2003...
  • 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 Deciding Between Referrals and Chaining ..........100 Usage Differences .
  • Page 7 Analyzing Your Security Needs ............135 Determining Access Rights .
  • Page 8 Chapter 8 Directory Design Examples ......... . 165 An Enterprise .

  • 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 12) 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

    Related Information Related Information The document set for Directory Server also contains the following guides: • Netscape Directory Server Installation Guide. Contains procedures for installing your Directory Server as well as procedures for migrating your Directory Server. • Netscape Directory Server Administrator’s Guide. Contains procedures for the day-to-day maintenance of your directory service.

  • 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 2 GB, 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 6.x introduces a new kind of entry, entries of the object class . An entry represents an ldapsubentry ldapsubentry administrative object, 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 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 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 6.x supports multi-master configurations, in which more than one server are master sources 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 the 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 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 X-ORIGIN schema entry was 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 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 . The parent of would be examplePreferredOS examplePerson . You might then create an object class called inetOrgPerson 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 Rigid data design forces you to consider the object class structure on which every piece of data will be placed. Depending on your personal preferences, you will find this to be either helpful or cumbersome. • Single object classes simplify data design when you have data that you want to put on more than one type of object class structure.

  • 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 • Use schema checking to ensure attributes and object classes conform to the schema rules. • Select and apply a consistent data format. 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.

  • Page 55: Selecting Consistent Data Formats

    Maintaining Consistent Schema Selecting Consistent Data Formats LDAP schema allow you to place any data that you want on any attribute value. However, it is important to store data consistently in your directory tree by selecting a format appropriate for your LDAP client applications and directory users.

  • Page 56: Other Schema Resources

    Other Schema Resources • You cannot create two attributes with the same name that use different syntaxes. If you create an attribute in a read-write replica that has the same name as an attribute on the master replica, but has a different syntax from the attribute on the master, replication will fail.

  • 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 class 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 o=example,c=US branches. 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 to not 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, an commonName entry for a person named Babs Jensen might have the distinguished name of: cn=Babs Jensen,dc=example,dc=com While allowing you to instantly recognize the person associated with the entry, it might not be unique in an include 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 This release of the Directory Server introduces a new concept for hierarchical navigation and organization of directory information, the virtual directory information tree views or virtual DIT views. • Overview •...

  • 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 facilitates 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 Note that the view entry itself does ou=Location Views, dc=example,dc=com not contain 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 may 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 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 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. For example, those applications that rely on the DN to identify a unique entry.
  • Page 86 Other Directory Tree Resources Netscape Directory Server Deployment Guide • December 2003...

  • 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. 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 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 entries for the following: suffixes are both root suffixes. o=NetscapeRoot dc=example,dc=com The other suffix, the ou=testing,dc=example,dc=com suffix and the ou=development,dc=example,dc=com suffix are all sub suffixes ou=partners,ou=development,dc=example,dc=com of the root suffix. The root suffix dc=example,dc=com dc=example,dc=com contains the data in the...

  • Page 92: About Knowledge References

    About Knowledge References entry represents a root suffix. The entry for each dc=example,dc=com hosted ISP is also a root suffix ( ). The o=example_a o=example_b and the branches are sub suffixes under each root suffix. ou=people 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 the 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 For example, a client application searches for entries with dc=example,dc=com a surname . A referral returns the following LDAP URL to the client Jensen application: ldap://europe.example.com:389/ou=people,l=europe,dc=example,dc=com 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...

  • Page 95: Smart Referrals

    About Knowledge References You configure the default referral to point to a Directory Server that has more knowledge about the distribution of your directory. Default referrals for the server are set by the attribute. Default referrals for each nsslapd-referral database in your directory installation are set by the nsslapd-referral attribute in the database entry in the configuration.
  • 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 example.com for the phone number of a employee in America.

  • Page 97: Tips For Designing Smart Referrals

    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 98: Using Chaining

    About Knowledge References • Redirect at major branch points. 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 to secure directory structure.
  • Page 99 About Knowledge References During chaining, a server receives a request from a client application for data it does not contain. Using the database link, the server then contacts other servers on behalf of the client application and returns the results to the client application. This operation is illustrated in the following diagram.

  • Page 100: Deciding Between Referrals And Chaining

    About Knowledge References NOTE If chaining is configured between a 6.x multiplexor and a 4.x farm server, add the attribute to the 4.x farm server nsuniqueid schema. If this attribute is not added to the 4.x Directory Server schema, the 6.x multiplexor will not find the entry it expects and chaining will fail.

  • Page 101: Evaluating Access Controls

    About Knowledge References Also, with referrals a client must authenticate, meaning that the servers to which clients are being referred need to contain the client credentials. With chaining, client authentication takes place only once. Clients do not need to authenticate again on the servers to which their requests are chained.
  • Page 102 About Knowledge References This approach requires Server B to have a replicated copy of the client’s entry from Server A. Chaining solves this problem. A search request would occur as follows on a chained system: 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.
  • 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). • International index—The international index speeds searches for information in international directories.
  • Page 106 Using Indexes to Improve Database Performance Netscape Directory Server Deployment Guide • December 2003...

  • 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 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 109: 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 110: 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 111: 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 112: 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 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 Although multiple 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. For example, 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 Masters) 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 Masters) 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 The 6.2 release of Directory Server supports four-way multi-master replication, replication topologies comprising four...

  • 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 in Figure 6-7 below from a different perspective. 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 • December 2003...

  • 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 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 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 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 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 master 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 to ensure 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. 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 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: 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 135: 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 136: 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 137: Conducting Regular Audits

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

  • Page 138: 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 139: 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 140: Simple Password

    Selecting Appropriate Authentication Methods • Deny access if the user provides any non-null string for the password For example, consider the following command: ldapsearch % 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 141: 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 142: Proxy Authentication

    Selecting Appropriate Authentication Methods 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 143: Preventing Authentication By Account Inactivation

    Preventing Authentication by Account Inactivation Preventing Authentication by Account Inactivation You can temporarily inactivate a user account or a set of accounts. Once inactivated, a user cannot bind to the directory, and the authentication operation fails. Account inactivation is implemented through the operational attribute .

  • Page 144: How Password Policy Works

    Designing a Password Policy How Password Policy Works The 6.2 release of Directory Server introduces fine-grained password policy, which enables you to define password policies at the subtree and user level. That is, you now have the flexibility of defining a password policy for: •...
  • 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 nsPwPolicyContainer holding various password policy related entries for the subtree and all its children.
  • Page 146 Designing a Password Policy cosTemplateDn: cn="cn=nsPwTemplateEntry, ou=people, dc=example, dc=com", cn=nsPwPolicyContainer, ou=people, dc=example, dc=com cosAttribute: pwdpolicysubentry default operational-default 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 nsPwPolicyContainer holding various password policy related entries for the user and its children.
  • Page 147 Designing a Password Policy When a user attempts to bind to the directory, Directory Server determines whether a local policy has been defined and enabled for the user’s entry: • To determine whether the fine-grained password policy is enabled, the server checks the value ( ) assigned to the attribute of the...
  • Page 148 Designing a Password Policy Figure 7-1 Flow Diagram Depicting How Password Policy Checking Works Netscape Directory Server Deployment Guide • December 2003...

  • 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 userPassword explained in the section that follows) is present in the request. • If you try to modify and if the password minimum age policy is userPassword activated, and if 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.

  • Page 152: Password Syntax Checking

    Designing a Password Policy Password Syntax Checking The password policy establishes some syntax guidelines for password strings, such as the minimum password length guideline. The password syntax-checking mechanism ensures that the password strings conform to the password syntax guidelines established by the password policy. Also, the password syntax-checking mechanism also ensures that the password is not a “trivial”...

  • Page 153: Password Storage Scheme

    Designing a Password Policy The passwords remain in history even if you turn the history feature off. This means that if you turn the password history option back on, users cannot reuse the passwords that were in the history before you disabled password history. The server does not maintain a password history by default.

  • Page 154: Designing An Account Lockout Policy

    Designing Access Control When configuring a password policy in a replicated environment, consider the following points: • All replicas issue warnings of an impending password expiration. This information is kept locally on each server, so if a user binds to several replicas in turn, the user receives the same warning several times.

  • Page 155: About The Aci Format

    Designing Access Control Using the ACL, you can set permissions for the following: • The entire directory • A particular subtree of the directory • Specific entries in the directory • A specific set of entry attributes • Any entry that matches a given LDAP search filter In addition, you can set permissions for a specific user, for all users belonging to a specific group, or for all users of the directory.

  • Page 156: Targets

    Designing Access Control Identifies the bind DN or network location to which the permission applies. The bind rule may also specify an LDAP filter, and if that filter is evaluated to be true for the binding client application, then the ACI applies to the client application.

  • Page 157: Bind Rules

    Designing Access Control You can allow or deny the following permissions: • Read—Indicates whether directory data may be read. • Write—Indicates whether directory data may be changed or created. This permission also allows directory data to be deleted, but not the entry itself. To delete an entire entry, the user must have delete permissions.

  • Page 158: Setting Permissions

    Designing Access Control • If the person binds anonymously. Setting a permission for anonymous bind also means that the permission applies to anyone who binds to the directory as well. • For anyone who successfully binds to the directory. This allows general access while preventing anonymous access.

  • Page 159: Allowing Or Denying Access

    Designing Access Control For example, if you deny write permission at the directory’s root level, and you make that permission applicable to everyone accessing the directory, then no user can write to the directory regardless of any other permissions that you may allow. To allow a specific user write permissions to the directory, you have to restrict the scope of the original deny-for-write so that it does not include that user.

  • Page 160: Where To Place Access Control Rules

    Designing Access Control • You want to restrict access control based on a day of the week or an hour of the day. For example, you can deny all writing activities from Sunday at 11:00 p.m. (2300) to Monday at 1:00 a.m. (0100). From an administrative point of view, it may be easier to manage an ACI that explicitly restricts time-based access of this kind than to search through the directory for all the allow for write ACIs and restrict their scopes in this time frame.

  • Page 161: Using Acis: Some Hints And Tricks

    Designing Access Control • Set an access control rule that grants read access to the homePhone attributes only for entries whose homePostalAddress attribute is set to TRUE (meaning enabled). Use an publishHomeContactInfo LDAP search filter to express the target for this rule. •...
  • Page 162 Designing Access Control This means that if you are allowing or restricting access to a subset of attributes on an object, determine whether the smallest list is the set of attributes that are allowed or the set of attributes that are denied. Then express your ACI so that you are managing the smallest list.

  • Page 163: Securing Connections With Ssl

    Securing Connections With SSL Although this syntax is perfectly acceptable for the server, it’s confusing for a human administrator. Securing Connections With SSL After designing your authentication scheme for identified users and your access control scheme for protecting information in your directory, you need to design a way to protect the integrity of the information passed among servers and client applications.
  • Page 164 Other Security Resources • CERT Security Improvement Modules http://www.cert.org/security-improvement/ Netscape Directory Server Deployment Guide • December 2003...

  • 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 example.com this, creates a deployment team that performs a site survey to example.com determine how the directory will be used. The deployment team determines the following: •...

  • Page 167: Directory Tree Design

    An Enterprise also wants to customize the default directory schema. example.com example.com creates the object class to represent employees of examplePerson example.com Corporation. It derives this object class from the object class. inetOrgPerson object class allows one attribute, the attribute. This examplePerson exampleID attribute contains the special employee number assigned to each...
  • Page 168 An Enterprise Mail administrators use the second group, , to cn=messaging admin manage mail accounts. This group corresponds to the administrators group used by Netscape Messaging Server. makes sure that the example.com group it configures for Netscape Messaging Server is different from the group it creates for Directory Server.

  • Page 169: Topology Design

    An Enterprise Topology Design Next, designs both its database and server topologies. The example.com following sections describe each topology in detail. Database Topology designs a database topology in which the people branch is stored example.com in 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 example.com data: • 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 example.com...

  • Page 174: Tuning And Optimizations

    An Enterprise • creates an ACI that gives members of the accounting role access example.com to all payroll information. 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.

  • Page 175: A Multinational Enterprise And Its Extranet

    A Multinational Enterprise and its Extranet A Multinational Enterprise and its Extranet This example builds a directory infrastructure for International. example.com Corporation from the previous example has grown into a large, example.com multinational company. This example builds on the directory structure created in the last example for Corporation, expanding the directory design example.com...

  • Page 176: Data Design

    A Multinational Enterprise and its Extranet Data Design International creates a deployment team to perform a site survey. example.com The deployment team determines the following from the site survey: • Netscape Messaging Server is used to provide electronic mail routing, delivery, and reading services for most of ’s sites.

  • Page 177: Directory Tree Design

    A Multinational Enterprise and its Extranet For information about customizing the default directory schema, refer to “Customizing the Schema,” on page 46. Directory Tree Design creates a directory tree as follows: example.com • The directory tree is rooted in the suffix .
  • Page 178 A Multinational Enterprise and its Extranet Figure 8-7 Directory Tree for example.com International’s Intranet 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 179: Topology Design

    A Multinational Enterprise and its Extranet Figure 8-8 Directory Tree for example.com International’s Extranet Topology Design Next, designs both its database and server topologies. The example.com following sections describe each topology in more detail. Database Topology The following diagram illustrates the database topology of one of ’s main localities, Europe: example.com Chapter 8...
  • Page 180 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 example.com under the branch are chained by a database link to a database on a server in l=US Austin, Texas.

  • Page 181: 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 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 182 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 example.com two consumer servers in the US data center and two consumer servers in the Asia data center.

  • Page 183: 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 184: 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 185 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 186 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 US and Asia, and between Europe and example.com example.com Asia. example.com Netscape Directory Server Deployment Guide • December 2003...

  • Page 187: Security Design

    A Multinational Enterprise and its Extranet Security Design International builds upon its previous security design, adding the example.com following access controls to support its new multinational intranet: • adds general ACIs to the root of the intranet, creating more example.com restrictive ACIs in each country and the branches beneath each country.
  • Page 188 A Multinational Enterprise and its Extranet Netscape Directory Server Deployment Guide • December 2003...

  • Page 189: 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 190 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 191 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 192 ciphertext Encrypted information that cannot be read by anyone without the proper key to decrypt the information. 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.
  • Page 193 daemon A background process on a Unix machine that is responsible for a particular system task. Daemon processes do not need human intervention to continue functioning. 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.
  • Page 194 DNS Domain Name System. The system used by machines on a network to associate standard IP addresses (such as 198.93.93.10) with hostnames (such as ). Machines normally get the IP address for a hostname from www.example.com a DNS server, or they look it up in tables maintained on their systems. DNS alias A DNS alias is a hostname that the DNS server knows points to a different host—specifically a DNS CNAME record.
  • Page 195 general access When granted, indicates that all authenticated users can access directory information. 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.
  • Page 196 ISO International Standards Organization. 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 197 management information base See MIB. 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 198 name collisions Multiple entries with the same distinguished name. nested role Allow you to create 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 199 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 govern how passwords are used in a given directory.
  • Page 200 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 201 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 202 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 Network Management Protocol See SNMP.
  • Page 203 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 (also called root).
  • Page 204 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 is .

  • Page 205: Index

    Index required and allowed 54 values 55 access attribute-data pair 25, 42 anonymous 138, 139 audits, for security 137 determining general types of 138 authentication methods 138 precedence rule 158 anonymous access 139 access control certificate-based 141 password protection and 153 proxy authentication 142 access control information (ACI) 154 simple password 140...
  • Page 206 database links 99 deleting schema 50 change log 110 deleting schema elements 50 checking password syntax 152 deny permissions 159 class of service (CoS) 73 directory applications 29 classic 74 browsers 29 definition entry 73 email 29 indirect 74 directory data pointer 74 access 35 target entry 73...
  • Page 207 four-way multi-master replication 114 email applications 29 employeeNumber 68 encryption password 153 Salted SHA 153 global directory services 15 SHA 153 global password policy 144 enterprise deployment example 165 grace logins after password expiration 151 entries 20 group attribute 160 naming 67 group entries 69 non-person 70...
  • Page 208 large database files 20 object class defining in schema 48 LDAP, See Lightweight Directory Access Protocol standard 44 LDAP referrals 93 object identifier. See OID. LDAPv3 schema 40 LDBM database 19 getting and assigning 47 length, password 152 organization attribute 160 Lightweight Directory Access Protocol (LDAP) 15 organizationalPerson object class 54 directory services 15...
  • Page 209 history 152 small sites 128 illegal strings 152 high availability 124 minimum length 152 hub server 117 reusing 152 load balancing simple 140 the network 125 syntax checking 152 local availability 124 user defined 150 overview 107 password policies 153 permissions 158 resource requirements 122 allow 159...
  • Page 210 conducting audits 137 security methods target entry 73 overview 138 telephoneNumber attribute 54 security policy 36 template entry 73 security threats 133 terms, in this book 11 denial of service 135 topology unauthorized access 134 overview 87 unauthorized tampering 134 trivial words 152 server database 19 two-way multi-master replication 114...

This manual is also suitable for:

Directory server 6.2

Table of Contents