Page 1 Deployment Guide Netscape Directory Server Version 6.1 August 2002...
Page 2 Netscape Communications Corporation ("Netscape") and its licensors retain all ownership rights to the software programs offered by Netscape (referred to herein as "Software") and related documentation. Use of the Software and related documentation is governed by the license agreement for the Software and applicable copyright law. Your right to copy this documentation is limited by copyright law.
Page 3: Table Of Contents
Contents About This Guide ............. . . 9 Purpose of This Guide .
Page 4 What Your Directory Might Include ........... . 26 What Your Directory Should Not Include .
Page 5 Designing Your Directory Tree ............58 Choosing a Suffix .
Page 6 Deciding Between Referrals and Chaining ..........99 Usage Differences .
Page 7 Analyzing Your Security Needs ............131 Determining Access Rights .
Page 8 Data Design ............... 158 Schema Design .
Page 9: About This Guide
About This Guide Welcome to the Netscape Directory Server (Directory Server). This preface includes the following sections: • Purpose of This Guide (page 9) • Directory Server Overview (page 10) • Conventions Used in This Guide (page 11) • Related Information (page 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 About Directory Entries LDIF is a standard text-based format for describing directory entries. An entry is a group of lines in the LDIF file that contains information about an object, such as a person in your organization or a printer on your network. Information about the entry is represented in the LDIF file by a set of attributes and their values.
Page 21: Directory Design Overview
Directory Design Overview To connect your distributed data, you can create a special entry in a subtree of your directory. All LDAP operations attempted below this entry are sent to a remote machine where the entry is actually stored. This method is called chaining. Chaining is implemented in the server as a plug-in.
Page 22 Directory Design Overview • How to Design the Schema. Your directory is designed to support one or more directory-enabled applications. These applications have requirements of the data you store in your directory, such as format. Your directory schema determines the characteristics of the data stored in your directory.
Page 23: Deploying Your Directory
Other General Directory Resources Deploying Your Directory After you have designed your directory service, you start the deployment phase. The deployment phase consists of the following steps: • Piloting Your Directory • Putting Your Directory Into Production Piloting Your Directory The first step of the deployment phase is installing a server instance as a pilot and testing whether your service can handle your user load.
Page 24 Other General Directory Resources • RFC 2251: Lightweight Directory Access Protocol (v3) http://www.ietf.org/rfc/rfc2251.txt • Understanding and Deploying LDAP Directory Services. T. Howes, M. Smith, G. Good, Macmillan Technical Publishing, 1999. Netscape Directory Server Deployment Guide • August 2002...
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: Table 2-3 Directory Data Characteristics Data Format Size Owner Related to Employee Name Text string 128 characters Human User’s entry resources Fax number Phone number 14 digits Facilities...
Page 33: Data Mastering For Replication
Performing a Site Survey Data Mastering for Replication Directory Server allows you to contain master sources of information on more than one server. If you use replication, decide which server is the master source of a piece of data. Directory Server 6.x supports multi-master configurations, in which more than one server are masters sources for the same pice of data.
Page 34: Determining Data Ownership
Performing a Site Survey Mastering data in non-directory applications makes the most sense if you can identify one or two applications that you already use to master your data, and you want to use your directory only for lookups (for example, for online corporate telephone books).
Page 35: Determining Data Access
Performing a Site Survey • Allow an organization’s administrator to create and manage entries for that organization. This approach makes your organization’s administrators your directory content managers. • Create roles that give groups of people read or write access privileges. For example, you might create roles for human resources, finance, or accounting.
Page 36 Performing a Site Survey • Can the data be read anonymously? The LDAP protocol supports anonymous access, and allows easy lookups for common information such as office sites, email addresses, and business telephone numbers. However, anonymous access gives anyone with access to the directory access to the common information.
Page 37: Documenting Your Site Survey
Performing a Site Survey Documenting Your Site Survey Because of the complexity of data design, document the results of your site surveys. During each step of the site survey we have suggested simple tables for keeping track of your data. Consider building a master table that outlines your decisions and outstanding concerns.
Page 38: Repeating The Site Survey
Performing a Site Survey Employee names can be read anonymously by everyone with access to the directory. • HR Writable Members of the human resources group can change, add, and delete employee names in the directory. • IS Writable Members of the information services group can change, add, and delete employee names in the directory.
Page 39: Chapter 3 How To Design The Schema
Chapter 3 How to Design the Schema The site survey you conducted in Chapter 2 generated information abut the data you plan to store in your directory. Next, you must decide how to represent the data you store. Your directory schema describes the types of data you can store in your directory.
Page 40: Netscape Standard Schema
Netscape Standard Schema • Extending the standard Directory Server schema to define new elements to meet your remaining needs. • Planning for schema maintenance. It is best to use existing schema elements defined in the standard schema provided with Directory Server. Choosing standard schema elements helps ensure compatibility with directory-enabled applications.
Page 41 Netscape Standard Schema The Directory Server schema differs slightly from the LDAPv3 schema, as it uses its own proprietary object classes and attributes. In addition, it uses a private field in the schema entries called , which describes where the schema entry was X-ORIGIN defined originally.
Page 42: Standard Attributes
Netscape Standard Schema Syntax Description Boolean Boolean values have a value of either "TRUE" or "FALSE." GeneralizedTime Values in this syntax are encoded as printable strings. It is strongly recommended that GMT time be used. The time zone must be specified. CountryString A value in this syntax is encoded the same as a value of DirectoryString syntax.
Page 43: Standard Object Classes
Netscape Standard Schema sn: Jensen givenName: Babs givenName: Barbara mail: bjensen@example.com Notice that the entry for Babs contains multiple values for some of the attributes. The attribute appears twice, each time with a unique value. The object givenName classes that appear in this example are explained in the next section, “Standard Object Classes."...
Page 44: Mapping Your Data To The Default Schema
Mapping Your Data to the Default Schema • A set of mandatory attributes • A set of allowed attributes For an example of a standard object class as it appears in the schema, refer to “Schema Format,” on page 40. As is the case for all of the Directory Server’s schema, object classes are defined and stored directly in Directory Server.
Page 45: Matching Data To Schema Elements
Mapping Your Data to the Default Schema Matching Data to Schema Elements The data you identified in your site survey now needs to be mapped to the existing directory schema. This process involves the following steps: • Identify the type of object the data describes. Select an object that best matches the data described in your site survey.
Page 46: Customizing The Schema
Customizing the Schema In the table, the employee name describes a person. In the default directory schema, we found the object class, which inherits from the object class. person This object class allows several attributes, one of which is the commonName attribute, which describes the full name of the person.
Page 47: When To Extend Your Schema
Customizing the Schema 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 addition to what you have already specified for the . The result is that X-ORIGIN attributes that are not will appear in the read-only section of 'user defined' the Directory Server Console, and you will not be able to use the console to edit object classes that contain an other than X-ORIGIN...
Page 54: Schema Checking
Maintaining Consistent Schema The following sections describe in detail how to maintain consistency within your schema. Schema Checking Schema checking ensures that all new or modified directory entries conform to the schema rules. When the rules are violated, the directory rejects the requested change.
Page 55: Maintaining Consistency In Replicated Schema
Maintaining Consistent Schema With the LDAP protocol and Directory Server, you must represent data in the data formats specified in RFC 2252. In addition, the correct LDAP format for telephone numbers is defined in the following ITU-T Recommendations documents: • ITU-T Recommendation E.123.
Page 56: Other Schema Resources
Other Schema Resources Other Schema Resources Refer to the following links for more information about standard LDAPv3 schema: • Internet Engineering Task Force (IETF) http://www.ietf.org/ • Understanding and Deploying LDAP Directory Services T. Howes, M. Smith, G. Good, Macmillan Technical Publishing, 1999. •...
Page 57: Chapter 4 Designing The Directory Tree
Chapter 4 Designing the Directory Tree Your directory tree provides a way to refer to the data stored by your directory. The types of information you store in your directory, the physical nature of your enterprise, the applications you use with your directory, and the types of replication you use shape the design of your directory tree.
Page 58: Designing Your Directory Tree
Designing Your Directory Tree • 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 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 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 A DIT With a Virtual DIT View Hierarchy Figure 4-3 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 not ou=Location Views, dc=example,dc=com 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 • August 2002...
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. The o=NetscapeRoot dc=example,dc=com other suffix, the ou=testing,dc=example,dc=com suffix and the ou=development,dc=example,dc=com suffix are all sub suffixes of ou=partners,ou=development,dc=example,dc=com root suffix. The root suffix contains dc=example,dc=com dc=example,dc=com...
Page 92: About Knowledge References
About Knowledge References About Knowledge References Once you have distributed your data over several databases, you need to define the relationship between the distributed data. You do this using knowledge references, pointers to directory information held in different databases. The Directory Server provides the following types of knowledge references to help you link your distributed data into a single directory tree: •...
Page 93: The Structure Of An Ldap Referral
About Knowledge References • Smart referrals Smart referrals are stored on entries within the directory itself. Smart referrals point to Directory Servers that have knowledge of the subtree whose DN matches the DN of the entry containing the smart referral. All referrals are returned in the format of an LDAP uniform resource locator (URL).
Page 94: About Default Referrals
About Knowledge References About Default Referrals Default referrals are returned to clients when the server or database contacted does not contain the data requested. Directory Server determines whether a default referral should be returned by comparing the DN of the requested directory object against the directory suffixes supported by the local server.
Page 95 About Knowledge References You redirect all requests on this branch to the branch of the European ou=people office of Corporation by specifying a smart referral on the example.com ou=people entry itself. This smart referral appears as follows: ldap://europe.example.com:389/ou=people,dc=example,dc=com Any requests made to people branch of the American directory are redirected to the European directory.
Page 96 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 97: Tips For Designing Smart Referrals
About Knowledge References Tips for Designing Smart Referrals While simple to implement, consider the following points before using smart referrals: • Keep the design simple. Deploying your directory using a complex web of referrals makes administration difficult. Also, overusing smart referrals can lead to circular referral patterns.
Page 98: Using Chaining
About Knowledge References • Consider the security implications. Access control does not cross referral boundaries. Even if the server where the request originated allows access to an entry, when a smart referral sends a client request to another server, the client application may not be allowed access.
Page 99: Deciding Between Referrals And Chaining
About Knowledge References • Dynamic management. You can add or remove a part of the directory from the system while the entire system remains available to client applications. The database link can temporarily return referrals to the application until entries have been redistributed across the directory.
Page 100: Usage Differences
About Knowledge References Usage Differences Some client applications do not support referrals. Chaining allows client applications to communicate with a single server and still access the data stored on many servers. Sometimes referrals do not work when a company’s network uses proxies.
Page 101 About Knowledge References However, Server A does not contain the information requested. Instead, Server A returns a referral to the client application telling them to contact Server B. The client application then sends a bind request to Server B. To bind successfully, Server B must also contain an entry for the client application.
Page 102 About Knowledge References In a chained system, the entry corresponding to the client application does not need to be located on the same server as the data the client requests. For example, a system could be set up as follows: In this illustration, the following steps are performed: The client application binds with Server A and Server A tries to confirm that the user name and password are correct.
Page 103: 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 104: Evaluating The Costs Of Indexing
Using Indexes to Improve Database Performance • International index—The international index speeds searches for information in international directories. You configure the index to apply a matching rule by associating a locale (OID) with the attribute being indexed. • Browsing Index—The browsing, or virtual list view, index speeds up the display of entries in the Directory Server Console.
Page 105: 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 106: 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 107: 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 108: 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 109: 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 110: 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 111: Multi-Master Replication
Common Replication Scenarios Single-Master Replication Figure 6-1 The supplier server can replicate a read-write replica to several consumer servers. The total number of consumer servers that a single supplier server can manage depends on the speed of your networks and the total number of entries that are modified on a daily basis.
Page 112 Common Replication Scenarios Although two separate servers can have master copies of the same data, within the scope of a single replication agreement, there is only one supplier server and one consumer. So, to create a multi-master environment between two supplier servers that share responsibility for the same data, you need to create more than one replication agreement.
Page 113: Cascading Replication
Common Replication Scenarios Replication Traffic in a Multi-Master Environment Figure 6-3 Cascading Replication In a cascading replication scenario, a hub supplier receives updates from a supplier server, and replays those updates on consumer servers. The hub supplier is a hybrid: it holds a read-only replica, like a typical consumer server and it maintains a change log like a typical supplier server.
Page 114 Common Replication Scenarios connection between Minneapolis and Duluth is of poor quality. Then, if your network between Saint Cloud and Duluth is of acceptable quality, you can use cascaded replication to move directory data from Minneapolis to Saint Cloud to Duluth.
Page 115: Mixed Environments
Common Replication Scenarios Replication Traffic and Change logs in Cascading Replication Figure 6-5 Mixed Environments You can combine any of the scenarios outlined in the previous sections to best fit your needs. For example, you could combine a multi-master configuration with a cascading configuration to produce something similar to the scenario illustrated in Figure 6-6 on page 116.
Page 116 Common Replication Scenarios Combined Multi-Master and Cascading Replication Figure 6-6 Netscape Directory Server Deployment Guide • August 2002...
Page 117: 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 118: 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 119: 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 120: 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 121: 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 122 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 123: 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 124: 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 125: 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 126: Replication And Database Links
Using Replication with other Directory Features You cannot use multi-master replication with the attribute uniqueness plug-in at all, because this plug-in can validate only attribute values on the same server not on both servers in the multi-master set. You can use the referential integrity plug-in with multi-master replication providing that this plug-in is enabled on just one master in the multi-master set.
Page 127: 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 128 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 129: 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 130: 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 131: 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 132: 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 133: Conducting Regular Audits
Analyzing Your Security Needs For information about encryption methods provided in the Directory Server, refer to “Password Storage Scheme,” on page 144. For information about signing data, refer to “Securing Connections With SSL,” on page 154. Conducting Regular Audits As an extra security measure, you should conduct regular audits to verify the efficiency of your overall security policy.
Page 134: 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 135: 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 136: Simple Password
Selecting Appropriate Authentication Methods • Deny access if the user provides any non-null string for the password For example, consider the following ldapsearch command: % ldapsearch -D “cn=joe” -w secretpwd -b “example.com” cn=joe Although the directory allows anonymous access for read, Joe cannot access his own entry because it does not contain a password that matches the one he provided in the command.
Page 137: 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 138: Proxy Authentication
Preventing Authentication by Account Inactivation Proxy Authentication Proxy authentication is a special form of authentication because the user requesting access to the directory does not bind with its own DN but with a proxy DN. The proxy DN is an entity that has appropriate rights to perform the operation requested by the user.
Page 139: Designing A Password Policy
Designing a Password Policy Account inactivation is implemented through the operational attribute . When an entry contains the attribute with a value nsAccountLock nsAccountLock , the server rejects the bind. true You use the same procedures for inactivating users and roles. However, inactivating a role means that you inactivate all of the members of that role and not the role entry itself.
Page 140 Designing a Password Policy Flow Diagram Depicting How Password Policy Checking Works During a Figure 7-1 BIND Request Netscape Directory Server Deployment Guide • August 2002...
Page 141: 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. and if the password minimum age policy is •...
Page 142: Password Change After Reset
Designing a Password Policy 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 143: 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 144: Password Length
Designing a Password Policy 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. A good length for passwords is 8 characters. This is long enough to be difficult to crack, but short enough that users can remember the password without writing it down.
Page 145: Designing A Password Policy In A Replicated Environment
Designing a Password Policy • 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 146: 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 147: 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 148: Targets
Designing Access Control For example, you can set a permission that allows anyone binding as Babs Jensen to write to Babs Jensen’s telephone number. The bind rule in this permission is the part that states “if you bind as Babs Jensen.” The target is Babs Jensen’s phone number, and the permission is write access.
Page 149: 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. This is used to match attribute values during directory authentication.
Page 150: 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, for example, allow a directory branch point to manage its immediate child entries. •...
Page 151: 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 152: 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 153: 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 154: Securing Connections With Ssl
Securing Connections With SSL 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 using the same filter to make sure you know what the ldapsearch results of the changes mean to your directory.
Page 155: Other Security Resources
Other Security Resources SSL can be used in conjunction with the RC2 and RC4 encryption algorithms from RSA. The encryption method selected for a particular connection is the result of a negotiation between the client application and Directory Server. SSL can also be used in conjuction with CRAM-MD5, which is a hashing mechanism that guarantees that information has not been modified during transmission.
Page 156 Other Security Resources Netscape Directory Server Deployment Guide • August 2002...
Page 157: 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 158: 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 159: 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 160: 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 161: 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 162 An Enterprise Server Topology for example.com Corporation Figure 8-3 Modify requests from the Netscape servers (such as the Netscape Calendar Server or the Netscape Delegated Administrator) are routed to the appropriate consumer server. The consumer server uses smart referrals to route the request to the supplier server responsible for the master copy of the piece of data being modified.
Page 163: 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 111. The following sections provide more details about the supplier server architecture and the supplier-consumer server topology.
Page 164: Supplier Consumer Architecture
An Enterprise Supplier Consumer Architecture The following diagram describes how the supplier servers replicate to each consumer in the deployment of the directory: example.com Figure 8-5 Supplier/Consumer Architecture for example.com Corporation Each of the three consumer servers is updated by the two supplier servers as shown in Figure 8-5.
Page 165: 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 166: 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 167: 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 168: 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 169 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 160 for more information about this directory tree design.
Page 170: 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 171 A Multinational Enterprise and its Extranet Database Topology for example.com Europe Figure 8-9 The database links point to databases stored locally in each country. For example, operation requests received by the Europe server for the data under example.com branch are chained by a database link to a database on a server in Austin, l=US Texas.
Page 172: Server Topology
A Multinational Enterprise and its Extranet Database Topology for example.com International’s Extranet Figure 8-10 As illustrated in Figure 8-10, the master copy of the data for is stored o=suppliers in database one, the master copy of the data for is stored in database o=partners two, and the master copy of the data for is stored in database three.
Page 173 A Multinational Enterprise and its Extranet Server Topology for example.com Europe Figure 8-11 ’s extranet data is mastered in Europe. This data is replicated to two example.com consumer servers in the US data center and two consumer servers in the Asia data center.
Page 174: Replication Design
A Multinational Enterprise and its Extranet Server Topology for example.com International’s Extranet Figure 8-12 The hub servers replicate the data to two consumer servers in the example.com Europe data center, two consumer servers in the US data center, and example.com two consumer servers in the Asia data center.
Page 175: Supplier Architecture
A Multinational Enterprise and its Extranet The hub servers are located near important directory-enable applications such as a mail server or a web server. Hub servers remove the burden of replication from the supplier servers, so the suppliers can concentrate on doing write operations. In the future, as expands and needs to add more consumer servers, the example.com additional consumers do not affect the performance of the suppliers.
Page 176 A Multinational Enterprise and its Extranet Each locality contains two suppliers, which share master copies of the data for that site. Each locality is therefore responsible for the master copy of its own data. Using a multi-master architecture ensures the availability of the data and helps balance the load of work managed by each supplier server.
Page 177: Security Design
A Multinational Enterprise and its Extranet The same relationship as illustrated in Figure 8-14 exists between example.com Asia, and between Europe and Asia. example.com example.com example.com Security Design International builds upon its previous security design, adding the example.com following access controls to support its new multinational intranet: •...
Page 178 A Multinational Enterprise and its Extranet Netscape Directory Server Deployment Guide • August 2002...
Page 179: 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 180 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 181 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 182 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 183 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 184 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 185 HTML Hypertext Markup Language. The formatting language used for documents on the World Wide Web. HTML files are plain text files with formatting codes that tell browsers such as the Netscape Navigator how to display text, position graphics and form items, and display links to other pages. HTTP Hypertext Transfer Protocol.
Page 186 LDAPv3 Version 3 of the LDAP protocol, upon which Directory Server bases its schema format. LDAP client Software used to request and view LDAP entries from an LDAP Directory Server. See also browser. LDAP Data Interchange Format See LDAP Data Interchange Format. LDAP URL Provides the means of locating directory servers using DNS and then completing the query via LDAP.
Page 187 matching rule Provides guidelines for how the server compares strings during a search operation. In an international search, the matching rule tells the server what collation order and operator to use. MD5 A message digest algorithm by RSA Data Security, Inc., which can be used to produce a short digest of data, that is unique with high probability, and is mathematically extremely hard to produce a piece of data that will produce the same message digest.
Page 188 network management station See NMS. NIS Network Information Service. A system of programs and data files that Unix machines use to collect, collate, and share specific information about machines, users, file systems, and network parameters throughout a network of computers. NMS Network Management Station.
Page 189 permission In the context of access control, the permission states whether access to the directory information is granted or denied, and the level of access that is granted or denied. See access rights. PDU Protocol Data Unit. Encoded messages which form the basis of data exchanges between SNMP devices.
Page 190 RDN Relative distinguished name. The name of the actual entry itself, before the entry’s ancestors have been appended to the string to form the full distinguished name. referential integrity Mechanism that ensures that relationships between related entries are maintained within the directory. referral (1) When a server receives a search or update request from an LDAP client that it cannot process, it usually sends back to the client a pointer to the LDAP sever that can process the request.
Page 191 root The most privileged user available on Unix machines. The root user has complete access privileges to all files on the machine. root suffix The parent of one or more sub suffixes. A directory tree can contain more than one root suffix. schema Definitions describing what types of information can be stored as entries in the directory.
Page 192 single-master replication The most basic replication scenario in which two servers each hold a copy of the same read-write replicas to consumer servers. In a single-master replication scenario, the supplier server maintains a change log. SIR See supplier-initiated replication. slapd LDAP Directory Server daemon or service that is responsible for most functions of a directory except replication.
Page 193 supplier server In the context of replication, a server that holds a replica that is copied to a different server is called a supplier for that replica. supplier-initiated replication Replication configuration where supplier servers replicate directory data to consumer servers. symmetric encryption Encryption that uses the same key for both encrypting and decrypting.
Page 194 virtual list view index Otherwise known as a browsing index, speeds up the display of entries in the Directory Server Console. Virtual list view indexes can be created on any branchpoint in the directory tree to improve display performance. X.500 standard The set of ISO/ITU-T documents outlining the recommended information model, object classes and attributes used by directory server implementation.
Page 195: Index
Index required and allowed 54 values 54 access attribute-data pair 25, 42 anonymous 134, 135 audits, for security 133 determining general types of 134 authentication methods 134 precedence rule 150 anonymous access 135 access control certificate-based 137 password protection and 145 proxy authentication 138 access control information (ACI) 146 simple password 136...
Page 196 database links 98 deleting schema elements 50 change log 108 deny permissions 150 checking password syntax 143 directory applications 29 browsers 29 class of service (CoS) 73 email 29 classic 74 definition entry 73 directory data indirect 74 access 35 pointer 74 examples of 26 target entry 73...
Page 197 email applications 29 global directory services 15 encryption group attribute 152 password 144 Salted SHA 145 SHA 144 enterprise deployment example 157 entries 20 naming 67 high availability 119, 120 group entries 69 hub supplier 113 non-person 70 organization 70 person 68 entry distribution 88 multiple databases 89...
Page 198 Lightweight Directory Access Protocol (LDAP) 15 organizationalUnit attribute 152 directory services 15 load balancing the network 121 password simple over TLS 137 mail attribute 68 password policies attributes 141 managed roles 72 change after reset 142 minimum length of passwords 144 design 139 multi-master replication 111–112 expiration warning 143...
Page 199 precedence rule 150 compared to groups 72 filtered 72 presence index 103 managed 72 proxy authentication 138 nested 72 root suffix 90 referrals 92–98 branching to support 65 Salted SHA encryption 145 compared to chaining 99 default 94 schema 39–55 LDAP 93 adding new attributes 50 smart referrals 94...
Page 200 characterizing data 31 identifying applications 29 virtual directory information tree views 58, 76 identifying data sources 30 virtual list view index 104 network capabilities 118 smart referral 94 sn attribute 54 standard object classes 44 standard schema 40–44 Start TLS 137 warning, password expiration 143 streetAddress attribute 54 styles, in this book 11...

Netscape DIRECTORY SERVER 6.1 - DEPLOYMENT Deployment Manual

About this Guide

Chapter 1 Introduction to Directory Server

Chapter 2 How to Plan Your Directory Data

Chapter 3 How to Design the Schema

Chapter 4 Designing the Directory Tree

Chapter 5 Designing the Directory Topology

Chapter 6 Designing the Replication Process

Chapter 7 Designing a Secure Directory

Chapter 8 Directory Design Examples

Glossary

Index

Quick Links

Need help?

Questions and answers

Subscribe to Our Youtube Channel

Related Manuals for Netscape NETSCAPE DIRECTORY SERVER 6.1 - DEPLOYMENT

Summary of Contents for Netscape NETSCAPE DIRECTORY SERVER 6.1 - DEPLOYMENT