Red Hat DIRECTORY SERVER 7.1 - DEPLOYMENT Deployment Manual

page of 230

/ 230
Contents
Table of Contents
Bookmarks

Table of Contents

Quick Links

Download this manual

Deployment Guide

Red Hat Directory Server

Version 7.1

May 2005

Table of Contents

Need help?

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

Questions and answers

Summary of Contents for Red Hat DIRECTORY SERVER 7.1 - DEPLOYMENT

Page 1 Deployment Guide Red Hat Directory Server Version 7.1 May 2005...
Page 2 All other trademarks referenced herein are the property of their respective owners. The GPG fingerprint of the security@redhat.com key is: CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E...
Page 3: Table Of Contents
Contents About This Guide ............... 11 Purpose of This Guide .
Page 4 What Your Directory Might Include ........... . 28 What Your Directory Should Not Include .
Page 5 Chapter 4 Designing the Directory Tree ..........61 Introduction to the Directory Tree .
Page 6 Tips for Designing Smart Referrals ..........101 Using Chaining .
Page 7 Chapter 7 Designing Synchronization ........... 139 Windows Sync Overview .
Page 8 About the ACI Format ............. . 175 Targets .
Page 9 Glossary ................209 Index .
Page 10 Red Hat Directory Server Deployment Guide • May 2005...
Page 11: About This Guide
About This Guide Welcome to the Red Hat Directory Server (Directory Server). This preface includes the following sections: • Purpose of This Guide (page 11) • Directory Server Overview (page 11) • Conventions Used in This Guide (page 13) • Related Information (page 13) Purpose of This Guide This guide provides you with a foundation for planning your directory.
Page 12 Directory Server Overview • Multi-master replication — Provides a highly available directory service for both read and write operations. Multi-master replication can be combined with simple and cascading replication scenarios to provide a highly flexible and scalable replication environment. • Chaining and referrals —...
Page 13: Conventions Used In This Guide
For example, if you gave the server an identifier of , then the actual path would look like this: phonebook /opt/redhat-ds/servers/slapd-phonebook/. . . • In examples/sample code, paths assume that the Directory Server is installed in the default location .
Page 14 For a list of documentation installed with Directory Server, open this file: serverRoot/manual/en/slapd/index.htm For the latest information about Directory Server, including current release notes, complete product documentation, technical notes, and deployment information, check this site: http://www.redhat.com/docs/manuals/dir-server/ 14 Red Hat Directory Server Deployment Guide • May 2005...
Page 15: Chapter 1 Introduction To Directory Server
Chapter 1 Introduction to Directory Server Red Hat 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 16: 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 17: 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 18: Overview Of Directory Server Architecture
Introduction to Directory Server When you install Directory Server, the following components are installed on your machine: • An LDAP server (Directory Server) with a plug-in interface. • The name of this process is ns-slapd • Red Hat Administration Server. For more information about the Administration Server, see Managing Servers with Red Hat Console.
Page 19: Overview Of The Server Front-End
Introduction to Directory Server 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. Multiple client programs can speak to the server in LDAP. They can communicate using LDAP over TCP/IP. The connection can also be protected with SSL/TLS, depending on whether the client negotiates the use of Transport Layer Security (TLS) for the connection.
Page 20 Introduction to Directory Server The root of the tree is called the root suffix. For information about naming the root suffix, refer to “Choosing a Suffix,” on page 62. At installation, the directory contains up to four subtrees under your root suffix: •...
Page 21: Directory Server Data Storage
Introduction to Directory Server For more information about directory trees, refer to chapter 4, “Choosing a Suffix,” on page 62. Directory Server Data Storage Your directory data is stored in an LDBM database. The LDBM database is implemented as a plug-in that is automatically installed with the directory and is enabled by default.
Page 22: About Directory Entries
Introduction to Directory Server You can choose to use multiple databases to support your Directory Server. You can distribute your data across the databases, allowing the server to hold more data than can be stored in a single database. The following sections describe how a directory database stores data. About Directory Entries LDIF is a standard text-based format for describing directory entries.
Page 23: Distributing Directory Data
Directory Design Overview Distributing Directory Data When you store various parts of your tree in separate databases, your directory can process client requests in parallel, improving performance. You can also store your databases on different machines, to further improve performance. To connect your distributed data, you can create a special entry in a subtree of your directory.
Page 24 Directory Design Overview Your directory will contain data, such as user names, telephone numbers, and group details. In chapter 2, “How to Plan Your Directory Data,” on page 27, you analyze the various sources of data in your organization and understand their relationship with one another.
Page 25: Deploying Your Directory
Directory Design Overview • Designing Synchronization. Windows synchronization allows the Directory Server to maintain the same directory data on the Directory Server, Windows NT4 Server, and Active DIrectory servers, as described in chapter 7, “Designing Synchronization,” on page 139. This chapter describes how synchronization works, synchronization scenarios, and tips for planning a synchronized, unified directory service.
Page 26: 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 Red Hat Directory Server Installation Guide. For information on administering and maintaining your directory, refer to Red Hat Directory Server Administrator’s Guide.
Page 27: 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 28: 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 29: What Your Directory Should Not Include
Defining Your Directory Needs • Office contact information for the various sites within your enterprise What Your Directory Should Not Include Directory Server is excellent for managing large quantities of data that client applications read and write, but it is not designed to handle large, unstructured objects, such as images or other media.
Page 30: 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 31: 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 32 Performing a Site Survey • Windows NT4 Server or Active Directory. Through Windows User Sync, deployments of Windows directory services can be integrated to function in tandem with your Directory Server. Both directories can store user information (user names and passwords, email addresses, telephone numbers) and group information (members).
Page 33: Identifying Data Sources
Performing a Site Survey Identifying Data Sources To identify all of the data that you want to include in your directory, you should perform a survey of your existing data stores. Your survey should include the following: • Identify organizations that provide information. Locate all the organizations that manage information essential to your enterprise.
Page 34: Determining Level Of Service
Performing a Site Survey • Size • Number of occurrences in various applications • Data owner • Relationship to other directory data You should study each piece of data you plan to include in your directory to determine what characteristics it shares with the other pieces of data. This helps save time during the schema design stage, described in more detail in chapter 3, “How to Design the Schema,”...
Page 35: Considering A Data Master
Performing a Site Survey Considering a Data Master The data master is the server that is the master source of data. Consider which server will be the data master when your data resides in more than one physical site. For example, when you use replication or use applications that cannot communicate over LDAP, data may be spread over more than one site.
Page 36 Performing a Site Survey Here are some ways you can implement data mastering: • Master the data in both the directory and all applications that do not use the directory. Maintaining multiple data masters does not require custom scripts for moving data in and out of the directory and the other applications.
Page 37: Determining Data Ownership
Performing a Site Survey Determining Data Ownership Data ownership refers to the person or organization responsible for making sure the data is up-to-date. During the data design, decide who can write data to the directory. Some common strategies for deciding data ownership follow: •...
Page 38: Determining Data Access
Performing a Site Survey Determining Data Access After determining data ownership, decide who can read each piece of data. For example, you may decide to store an employee’s home phone number in your directory. This data may be useful for a number of organizations, including the employee’s manager and human resources.
Page 39: Documenting Your Site Survey
Performing a Site Survey As you make these decisions for each piece of directory data, you define a security policy for your directory. Your decisions depend upon the nature of your site and the kinds of security already available at your site. For example, if your site has a firewall or no direct access to the Internet, you may feel freer to support anonymous access than if you are placing your directory directly on the Internet.
Page 40: Repeating The Site Survey
Performing a Site Survey Data Name Owner Supplier Server or Self Global Read Application Read/Write Writable Writable Employee Directory US-1 Read-only Yes (must log location Office phone Facilities Phone switch Read-only number (anonymous) Looking at the row representing the employee name data, we see the following: •...
Page 41 Performing a Site Survey centralized site. In this case, each office that keeps a master copy of information should run its own site survey. After the site survey process has been completed, the results of each survey should be returned to a central team (probably consisting of representatives from each office) for use in the design of the enterprise-wide data schema model and directory tree.
Page 42 Performing a Site Survey Red Hat Directory Server Deployment Guide • May 2005...
Page 43: Chapter 3 How To Design The Schema
Chapter 3 How to Design the Schema The site survey you conducted in chapter 2,“How to Plan Your Directory Data,” generated information about the data you plan to store in your directory. Next, you must decide how to represent the data you store. Your directory schema describes the types of data you can store in your directory.
Page 44: Standard Schema
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 45 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 46: Standard Attributes
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 47: Standard Object Classes
Standard Schema sn: Jensen givenName: Babs givenName: Barbara mail: bjensen@example.com The entry for Babs contains multiple values for some of the attributes. The attribute appears twice, each time with a unique value. The object classes that givenName appear in this example are explained in the next section, “Standard Object Classes.” In the schema, each attribute definition contains the following information: •...
Page 48: Mapping Your Data To The Default Schema
Mapping Your Data to the Default Schema • 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 44. As is the case for all of the Directory Server’s schema, object classes are defined and stored directly in Directory Server.
Page 49: 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 50: Customizing The Schema
Customizing the Schema In the table, the employee name describes a person. In the default directory schema, we found the object class, which inherits from the object person class. This object class allows several attributes, one of which is the attribute, which describes the full name of the person.
Page 51: When To Extend Your Schema
Customizing the Schema 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 Attributes and Object Classes • Strategies for Defining New Object Classes •...
Page 52: Naming Attributes 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 used for more than one purpose.
Page 53 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 54: 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 55: 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 56: 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 57: Maintaining Consistent Schema
Maintaining Consistent Schema that attributes that are not will appear in the read-only 'user defined' section of the Directory Server Console, and you will not be able to use the Console to edit object classes that contain an other than X-ORIGIN 'user defined'...
Page 58: 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 59: 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 60: 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 61: 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 62: 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 63: 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 Red Hat Directory Server Administrator’s Guide.
Page 64: 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 65: 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 66: Identifying Branch Points
Designing Your Directory Tree • ou=services A directory tree organized using these objects might appear as shown below. Branching in a Hosting Environment For a hosting environment, create a tree that contains two entries of the object class and one entry of the object organization (o) organizationalUnit (ou)
Page 67 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 68: Replication Considerations
Designing Your Directory Tree Table 4-1Traditional 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 69 Designing Your Directory Tree For example, in an enterprise environment, you can organize your directory tree so that it corresponds to the network names in your enterprise. Network names tend not to change, so the directory tree structure will be stable. Further, using network names to create the top level branches of your directory tree is useful when you use replication to tie together different Directory Servers.
Page 70: 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 71: 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 72: Naming Person Entries
Designing Your Directory Tree Naming Person Entries The person entry’s name, the DN, must be unique. Traditionally, distinguished names use the , or , attribute to name their person entries. That is, commonName an entry for a person named Babs Jensen might have the distinguished name of: cn=Babs Jensen,dc=example,dc=com While allowing you to recognize instantly the person associated with the entry, it might not be unique enough to exclude people with identical names.
Page 73: 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 74: Naming Organization Entries
Designing Your Directory Tree • A Directory Server role—Roles unify the static and dynamic group concept. Refer to “About Roles,” on page 75, 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 75: 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 76: 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 77: 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 78: 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 79: 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: l (locality) Directory Tree for an ISP Internet service providers (ISPs) may support multiple enterprises with their directories.
Page 80: Virtual Directory Information Tree Views
Virtual Directory Information Tree Views Virtual Directory Information Tree Views Directory Server supports a concept for hierarchical navigation and organization of directory information called virtual directory information tree views or virtual DIT views. • Overview • Introduction to Virtual DIT Views •...
Page 81: 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 82: 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 83 Virtual Directory Information Tree Views For information about adding and modifying entries, refer to chapter 2 , “Creating Directory Entries,” in the Red Hat 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 84 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 85: Advantages Of Using Virtual Dit Views
Virtual Directory Information Tree Views Advantages of Using Virtual DIT Views Your deployment decisions become easier with virtual DIT views: • Views facilitate use of flat namespace for entries because virtual DIT views provide navigational and managerial support similar to the ones provided by traditional hierarchies.
Page 86: 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 87: Views And Other Directory Features
Virtual Directory Information Tree Views view entry itself does not contain ou=Location Views, dc=example,dc=com a filter. This feature facilitates hierarchical organization without the requirement to restrict the entries contained in the view further. Any view may omit the filter. Although the example filters are very simple, the filter used may be as complex as necessary.
Page 88: Effects Of Virtual Views On Performance
Virtual Directory Information Tree Views To clarify any doubts that you have about the effects of views on searching, understand that if the base of the search is a view and the scope of the search is not a base, then it is a views-based search. Otherwise, it is a conventional search. For example, if you perform a search with a base of , then no dc=example,dc=com...
Page 89: Other Directory Tree Resources
Other Directory Tree Resources true location of an entry by changing the DN of the entry to conform to the views hierarchy. This is by design — many applications would not function if the true location of an entry were disguised, such as those applications that rely on the DN to identify a unique entry.
Page 90 Other Directory Tree Resources Red Hat Directory Server Deployment Guide • May 2005...
Page 91: 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 Red Hat Directory Server (Directory Server) can store a large quantity of entries, you may need to distribute your entries across more than one server.
Page 92: 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 workload for each server.
Page 93: About Using Multiple Databases
Distributing Your Data About Using Multiple Databases Directory Server stores data in LDBM databases.The LDBM database is a high-performance, disk-based database. Each database consists of a set of large files that contains all of the data assigned to it. You can store different portions of your directory tree in different databases. In that instance, your directory tree appears as follows: You can also store the data of the three suffixes in three separate databases, as shown below:...
Page 94: 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 95 Distributing Your Data The suffixes that result contain the following entries: suffixes are both root suffixes. The o=NetscapeRoot dc=example,dc=com other suffix, the ou=testing,dc=example,dc=com suffix, and the ou=development,dc=example,dc=com suffix are all sub suffixes of ou=partners,ou=development,dc=example,dc=com root suffix. The root suffix contains dc=example,dc=com dc=example,dc=com the data in the...
Page 96: About Knowledge References
About Knowledge References entry represents a root suffix. The entry for each hosted dc=example,dc=com ISP is also a root suffix ( ). The and the o=example_a o=example_b ou=people branches are sub suffixes under each root suffix. ou=groups About Knowledge References Once you have distributed your data over several databases, you need to define the relationship between the distributed data.
Page 97: Using Referrals
About Knowledge References Using Referrals A referral is a piece of information returned by a server that tells a client application which server to contact to proceed with an operation request. This redirection mechanism occurs when a client application requests a directory entry that does not exist on the local server.
Page 98: About Default Referrals
About Knowledge References The referral tells the client application to contact the host europe.example.com on port and submit a search rooted at ou=people,l=europe,dc=example,dc=com The LDAP client application you use determines how a referral is handled. Some client applications automatically retry the operation on the server to which they have been referred.
Page 99: Smart Referrals
About Knowledge References Smart Referrals Directory Server also allows you to configure your directory to use smart referrals. Smart referrals allow you to associate a directory entry or directory tree to a specific LDAP URL. Associating directory entries to specific LDAP URLs allows you to refer requests to any of the following: •...
Page 100 About Knowledge References You can use the same mechanism to redirect queries to a different server that uses a different namespace. For example, an employee working in the Italian office of Corporation makes a request to the European directory for the example.com phone number of an employee in America.
Page 101: Tips For Designing Smart Referrals
About Knowledge References NOTE Creating a referral from one namespace to another works only for clients whose searches are based at that distinguished name. Other kinds of operations, such as searches below , will not be performed correctly. ou=people,o=example,c=US For more information on LDAP URLS and on how to include smart URLs on Directory Server entries, see Red Hat Directory Server Administrator’s Guide.
Page 102: Using Chaining
About Knowledge References Limit your referral usage to handle redirection at the suffix level of your directory tree. Smart referrals allow you to redirect lookup requests for leaf (non-branch) entries to different servers and DNs. As a result, you may be tempted to use smart referrals as an aliasing mechanism, leading to a complex and difficult method to secure directory structure.
Page 103 About Knowledge References Each database link is associated with a remote server holding data. You can also configure alternate remote servers containing replicas of the data for the database link to use when there is a failure. For more information on configuring database links, refer to the Red Hat Directory Server Administrator’s Guide.
Page 104: Deciding Between Referrals And Chaining
About Knowledge References Deciding Between Referrals and Chaining Both methods of linking your directory partitions have advantages and disadvantages. The method, or combination of methods, you choose depends upon the specific needs of your directory. The major difference between the two knowledge references is the location of the intelligence that knows how to locate the distributed information.
Page 105 About Knowledge References In the illustration above, the client application performs the following steps: The client application first binds with server A. Server A contains an entry for the client that provides a user name and password, so it returns a bind acceptance message. In order for the referral to work, the client entry must be present on server A.
Page 106 About Knowledge References In the illustration above, the following steps are performed: The client application binds with server A, and server A tries to confirm that the user name and password are correct. Server A does not contain an entry corresponding to the client application. Instead, it contains a database link to server B, which contains the actual entry of the client.
Page 107 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 108: 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 109: 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 (internationalization OID) with the attribute being indexed. •...
Page 110 Using Indexes to Improve Database Performance Red Hat Directory Server Deployment Guide • May 2005...
Page 111: 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 112: Replication Concepts
Introduction to Replication • Fault tolerance/Failover — By replicating directory trees to multiple servers, you can ensure your directory is available even if some hardware, software, or network problem prevents your directory client applications from accessing a particular Directory Server. Your clients are referred to another Directory Server for read and write operations.
Page 113: Unit Of Replication
Introduction to Replication Unit of Replication The smallest unit of replication is a database. This means that you can replicate an entire database but not a subtree within a database. Therefore, when you create your directory tree, you must take your replication plans into consideration. For more information on how to set up your directory tree, refer to chapter 4, “Designing the Directory Tree,”...
Page 114: Changelog
Introduction to Replication • Initiate replication to consumer servers. The supplier server is always responsible for recording the changes made to the read-write replicas that it manages, so the supplier server makes sure that any changes are replicated to consumer servers. A consumer server must: •...
Page 115: Data Consistency
Introduction to Replication • How the connection is secured (SSL, client authentication, or no SSL). • Any attributes that will not be replicated (see “Fractional Replication,” on page 127). Data Consistency Consistency refers to how closely the contents of replicated databases match each other at a given point in time.
Page 116: Common Replication Scenarios
Common Replication Scenarios Common Replication Scenarios You need to decide how the updates flow from server to server and how the servers interact when propagating updates. There are four basic scenarios: • Single-Master Replication • Multi-Master Replication • Cascading Replication •...
Page 117: 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 118 Common Replication Scenarios Multiple servers can have master copies of the same data, but, within the scope of a single replication agreement, there is only one supplier server and one consumer. That means that to create a multi-master environment between two supplier servers that share responsibility for the same data, you need to create more than one replication agreement.
Page 119 Common Replication Scenarios Figure 6-3 Multi-Master Replication Configuration (Four Suppliers) Figure 6-4 illustrates a topology where each supplier server feeds data to two other supplier servers (and to the consumer servers). 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 120 Common Replication Scenarios Figure 6-4 Multi-Master Replication Configuration (Four Suppliers) The total number of supplier servers you can have in any replication environment is limited to four. However, the number of consumer servers that hold the read-only replicas is not limited. NOTE Directory Server supports four-way multi-master replication;...
Page 121: 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 changelog like a typical supplier server.
Page 122 Common Replication Scenarios This cascading replication scenario is illustrated in Figure 6-6. Figure 6-6 Cascading Replication Scenario The same scenario is illustrated from a different perspective in Figure 6-7, below. It shows how the replicas are configured on each server (read-write or read-only) and which servers maintain a changelog.
Page 123: Mixed Environments
Common Replication Scenarios Figure 6-7 Replication Traffic and Changelogs 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 124 Common Replication Scenarios Figure 6-8 Combined Multi-Master and Cascading Replication Red Hat Directory Server Deployment Guide • May 2005...
Page 125: 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 you have multiple consumers for different locations or sections of your company or if you have some servers that are insecure, then you should use fractional replication to exclude sensitive or seldom-modified information to maintain data integrity without compromising sensitive information.
Page 126: Replication Survey
Defining a Replication Strategy Once you understand your replication strategy, you can start deploying your directory. This is a case where deploying your service in stages will pay large dividends. By placing your directory into production in stages, you can get a better sense of the loads that your enterprise places on your directory.
Page 127: Replication Resource Requirements
Defining a Replication Strategy • The number and size of the entries stored in the directory. A site that manages human resource databases or financial information is likely to put a heavier load on your directory than a site containing engineering staff that uses the directory for simple telephone book purposes.
Page 128: Replication Across A Wide-Area Network
Defining a Replication Strategy • Where the consumer server is connected via a slow network, excluding infrequently changed attributes or larger attributes such as results jpegPhoto in less network traffic. • Where the consumer server is placed on an untrusted network such as the public Internet, excluding sensitive attributes such as telephone numbers provides an extra level of protection that guarantees no access to those attributes even if the server s access control measures are defeated or the...
Page 129: Using Replication For High Availability
Defining a Replication Strategy There are performance issues to consider for both the Directory Server and the efficiency of the network connection: • Where replication is performed across a public network such as the Internet, the use of SSL is highly recommended. This will guard against eavesdropping of the replication traffic.
Page 130: Using Replication For Local Availability
Defining a Replication Strategy Therefore, you will probably need to use either DNS round-robins or network sorts to provide failover to your backup Directory Servers. For information on setting up and using DNS round robins or network sorts, see your DNS documentation.
Page 131: Example Of Network Load Balancing
Defining a Replication Strategy • By dedicating special servers to specific tasks, such as supporting mail server activities. One of the more important reasons to replicate directory data is to balance the workload of your network. When possible, you should move data to servers that can be accessed using a reasonably fast and reliable network connection.
Page 132 Defining a Replication Strategy Each office contains a high-speed network, but you are using a dial-up connection to network between the two cities. To balance your network load: • Select one server in each office to be the supplier server for the locally managed data.
Page 133: 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 134: 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 workload of your servers and your WANs, as well as ensuring high availability of directory data. Assume that you want to replicate to four sites around the country.
Page 135: 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 136: Replication And Database Links
Using Replication with Other Directory Features You cannot use multi-master replication with the attribute uniqueness plug-in at all because this plug-in can validate only attribute values on the same server, not on multiple servers in the multi-master set. • Referential Integrity Plug-in You can use the referential integrity plug-in with multi-master replication, providing that this plug-in is enabled on just one supplier in the multi-master set.
Page 137: 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 138: Replication And Synchronization
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 139: Chapter 7 Designing Synchronization
Chapter 7 Designing Synchronization An important factor to consider as you conduct the site survey for your existing site (“Performing a Site Survey,” on page 30) is to include the structure and data types of Active Directory or Windows NT4 directory services. Through Windows Sync, you can synchronize an existing Windows directory service with your Directory Server, including creating, modifying, and deleting Windows accounts on the Directory Server or, oppositely, the Directory Server accounts on Windows.
Page 140 Windows Sync Overview • Password Sync. This application captures password changes for Windows users and relays those changes back to the Directory Server over LDAPS. It must be installed on the Active Directory machine or primary domain controller (PDC) for NT4 synchronization. •...
Page 141 Windows Sync Overview Figure 7-1 Active Directory - Directory Server Synchronization Process Chapter 7 Designing Synchronization...
Page 142 Windows Sync Overview Figure 7-2 Windows NT4 Server - Directory Server Synchronization Process Syncronization is configured and controlled by one or more synchronization agreements. These are similar in purpose to replication agreements and contain a similar set of information, including the hostname and port number for the Windows server and the subtrees being synched.
Page 143 Windows Sync Overview synchronize and design or add corresponding Directory Server subtrees. The synched Windows and Directory Server suffixes are both specified in the sync agreement. All entries within the respective subtrees are available for syncronization, including entries that are not immediate children of the specified suffix.
Page 144: Designing Windows Sync
Designing Windows Sync Designing Windows Sync It may be useful to assess the type of information, Windows servers, and other considerations before you begin setting up synchronization, similar to the site survey you did for organizing data or planning replication. Some of these are explored further on.
Page 145 Designing Windows Sync Additionally, Windows Sync must be configured on a primary domain controller (PDC) for Windows NT4 servers. Synchronization will not function properly on a non-PDC machine. • Determine the type of connection you will use. Although it is not required, it is strongly recommended that you use an SSL or other secure connection for synchronization.
Page 146: Resource Requirements
Designing Windows Sync Existing Directory Server entries that are modified to contain the necessary NT attributes will not be synchronized until the next total update. Modifications to Windows entries and Directory Server entries that have already been synched are carried at the next incremental update. As a part of this strategy, try to master data in a single place, limiting the applications that can change the data, and schedule necessary total updates (these updates will not overwrite or delete existing information;...
Page 147: Considering A Data Master
Designing Windows Sync Password Sync must be installed on both Active Directory and NT4 Server in order to transfer any password changes made on the Windows server. The LDAP Service must be installed on a Windows NT4 Server for entries to be added and modified over LDAP.
Page 148: Characterizing Your Directory Data
Designing Windows Sync Figure 7-3 Multi-Master Directory Server - Windows Domain Synchronization Characterizing Your Directory Data Windows Sync allows you to synchronize user and group entries. Once you have chosen the subtrees that will be synchronized, plan the information that will be stored there, such as: •...
Page 149 Designing Windows Sync Special schema are applied to synchronized user entries in the Directory Server. A new Directory Server account is synchronized to a Windows server if the new Directory Server entry uses the object class and the ntUser ntGroup attribute.
Page 150 Designing Windows Sync User Attributes Supported by Synchronization Table 7-1 Directory Server Active Directory Attributes Attributes description description destinationIndicator destinationIndicator facsimileTelephoneNumb facsimileTelephoneNumber givenName givenName homePhone homePhone homePostalAddress homePostalAddress initials initials mail mail manager manager mobile mobile ntUserAcctExpires accountExpires ntUserCodePage codePage ntUserDomainId sAMAccountName ntUserHomeDir...
Page 151 Designing Windows Sync User Attributes Supported by Synchronization Table 7-1 Directory Server Active Directory Attributes Attributes postOfficeBox postOfficeBox postalAddress postalAddress postalCode postalCode registeredAddress registeredAddress street street telephoneNumber telephoneNumber teletexTerminalIdentifier teletexTerminalIdentifier telexNumber telexNumber title title userCertificate userCertificate x121Address x121Address Group Attributes Supported by Synchronization Table 7-2 Directory Server Active Directory Attributes...
Page 152 Designing Windows Sync Group Attributes Supported by Synchronization Table 7-2 Directory Server Active Directory Attributes Attributes seeAlso seeAlso Red Hat Directory Server Deployment Guide • May 2005...
Page 153: Chapter 8 Designing A Secure Directory
Chapter 8 Designing a Secure Directory How you secure the data in Red Hat 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 154: About Security Threats
About Security Threats About Security Threats There are many potential threats to the security of your directory. Understanding the most common threats helps you plan your overall security design. The most typical threats to directory security fall into the following three categories: •...
Page 155: Unauthorized Tampering
Analyzing Your Security Needs Unauthorized Tampering If intruders gain access to your directory or intercept communications between Directory Server and a client application, they have the potential to modify (or tamper with) your directory data. Your directory is rendered useless if the data can no longer be trusted by clients or if the directory itself cannot trust the modifications and queries it receives from clients.
Page 156: Determining Access Rights
Analyzing Your Security Needs • To provide users and applications with access to the information they need to perform their jobs. • To protect sensitive data regarding employees or your business from general access. If your directory serves an extranet or supports e-commerce applications over the Internet, in addition to the previous points, your concerns are: •...
Page 157: Ensuring Data Privacy And Integrity
Analyzing Your Security Needs For information about checking the identity of users, refer to “Selecting Appropriate Authentication Methods,” on page 159. For information about restricting access to directory information, refer to “Designing Access Control,” on page 174. Ensuring Data Privacy and Integrity When you are using the directory to support exchanges with business partners over an extranet or to support e-commerce applications with customers on the Internet, you must ensure the privacy and the integrity of the data exchanged.
Page 158: Overview Of Security Methods
Overview of Security Methods Therefore, has three main categories of information in its directory: example.com • internal information. example.com • Information belonging to corporate customers. • Information pertaining to individual subscribers. needs the following access controls: example.com • Provide access to the directory administrators of hosted companies ) to their own directory information.
Page 159: Selecting Appropriate Authentication Methods
Selecting Appropriate Authentication Methods • Account inactivation — Disables a user account, group of accounts, or an entire domain so that all authentication attempts are automatically rejected. • Secure connections — Maintains the integrity of information by encrypting connections with SSL, Start TLS, or SASL. If information is encrypted during transmission, the recipient can determine that it was not tampered with during transit.
Page 160: Simple Password
Selecting Appropriate Authentication Methods However, anonymous access does not allow you to track who is performing what kinds of searches, only that someone is performing searches. When you allow anonymous access, anyone who connects to your directory can access the data. Therefore, if you attempt to block a specific user or group of users from seeing some kinds of directory data, but you have allowed anonymous access to that data, then those users can still access the data simply by binding to the directory...
Page 161: Certificate-Based Authentication
Selecting Appropriate Authentication Methods The bind DN often corresponds to the entry of a person. However, some directory administrators find it useful to bind as an organizational entry rather than as a person. The directory requires the entry used to bind to be of an object class that allows the attribute.
Page 162: Simple Password Over Tls
Selecting Appropriate Authentication Methods For more information about certificates and SSL, see Managing Servers with Red Hat Console. Simple Password over TLS When a secure connection is established between Directory Server and a client application using SSL or the Start TLS operation, the server can demand an extra level of authentication by requesting a password.
Page 163: Preventing Authentication By Account Inactivation
Preventing Authentication by Account Inactivation NOTE The proxy mechanism is very powerful and must be used sparingly. Proxy rights are granted within the scope of the ACL, and there is no way to restrict who can be impersonated by an entry that has the proxy right—that is, when you grant a user proxy rights, that user has the ability to proxy for any user under the target;...
Page 164: How Password Policy Works
Designing a Password Policy How Password Policy Works Directory Server supports fine-grained password policy, which enables you to define password policies at the subtree and user level. This allows the flexibility of defining a password policy for: • The entire directory (similar to the previous releases of Directory Server). Such a policy is known as the global password policy.
Page 165 Designing a Password Policy For a subtree (for example, ), the following ou=people, dc=example, dc=com changes are required: • Add a container entry ( ) at the subtree level for holding nsPwPolicyContainer various password policy-related entries for the subtree and all its children. For example: dn: cn=nsPwPolicyContainer, ou=people, dc=example, dc=com objectClass: top...
Page 166 Designing a Password Policy For a user (for example, ), the uid=jdoe, ou=people, dc=example, dc=com following changes are required: • Add a container entry ( ) at the parent level for holding nsPwPolicyContainer various password policy related entries for the user and its children. For example: dn: cn=nsPwPolicyContainer, ou=people, dc=example, dc=com objectClass: top...
Page 167 Designing a Password Policy • To determine whether a local policy is defined for a subtree or user, the server checks for the attribute in the corresponding user entry. If pwdPolicysubentry the attribute is present, the server enforces the local password policy configured for the user.
Page 168 Designing a Password Policy Figure 8-1 Flow Diagram Depicting How Password Policy Checking Works Red Hat Directory Server Deployment Guide • May 2005...
Page 169: Password Policy Attributes
Designing a Password Policy In addition to bind requests, password policy also occurs during add and modify operations if the attribute (which is explained in the section that userPassword follows) is present in the request. • If you try to modify , the password minimum age policy is userPassword activated, and, if it is too soon to allow the change, the server will return a...
Page 170: 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 171: Password Expiration
Designing a Password Policy Password Expiration You can set your password policy so that users can use the same passwords indefinitely. Or you can set your policy so that passwords expire after a given time. In general, the longer a password is in use, the more likely it is to be discovered. On the other hand, if passwords expire too often, users may have trouble remembering them and resort to writing their passwords down.
Page 172: 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 173: 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 174: Designing Access Control
Designing Access Control • Account lockout is enforced on the replicas. The password policy information in your directory, such as password age, the account lockout counter, and the expiration warning counter, are all replicated. However, the configuration information is kept locally and is not replicated. This information includes the password syntax and the history of password modifications.
Page 175: About The Aci Format
Designing Access Control • 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. Lastly, you can define access for a network location such as an IP address or a DNS name.
Page 176: Targets
Designing Access Control 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 177: Bind Rules
Designing Access Control • Compare — Indicates whether the data may be used in comparison operations. Compare implies the ability to search, but actual directory information is not returned because of the search. Instead, a simple Boolean value is returned that indicates whether the compared values match.
Page 178: Setting Permissions
Designing Access Control • Parent — If the bind DN is the immediate parent entry, then the bind rule is true. This allows you to grant specific permissions that allow a directory branch point to manage its immediate child entries. •...
Page 179: 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 180: 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 181: Viewing Acis: Get Effective Rights
Designing Access Control Viewing ACIs: Get Effective Rights It can be necessary to view access controls set on an entry to grant fine-grained access control or for efficient entry management. Get effective rights is an extended which returns the access control permissions set on each attribute ldapsearch within an entry and allows an LDAP client to determine what operations the server’s access control configuration will allow a user to perform.
Page 182: Using Acis: Some Hints And Tricks
Designing Access Control facsimileTelephoneNumber: +1 408 555 5409 objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson uid: tmorris cn: Ted Morris userPassword: {SSHA}bz0uCmHZM5b357zwrCUCJs1IOHtMD6yqPyhxBA== entryLevelRights: vadn attributeLevelRights: givenName:rsc, sn:rsc, ou:rsc, l:rscow, manager:rsc, roomNumber:rscwo, mail:rscwo, facsimileTelephoneNumber:rscwo, objectClass:rsc, uid:rsc, cn:rsc, userPassword:wo In this example, Ted Morris has the right to add, view, delete, or rename the DN on his own entry, as shown by the returns in .
Page 183 Designing Access Control • Minimize the number of ACIs in your directory. • Although Directory Server can evaluate over 50,000 ACIs, it is difficult to manage a large number of ACI statements. A large number of ACIs makes it hard for you to determine immediately the directory object available to particular clients.
Page 184: Database Encryption
Database Encryption Watch out for overlapping ACIs. For example, if you have an ACI at your directory root point that allows a group write access to the commonName attributes and another ACI that allows the same group write givenName access for just the attribute, then consider reworking your ACIs commonName so that only one control grants the write access for the group.
Page 185: Securing Connections With Ssl And Start Tls
Securing Connections with SSL and Start TLS Securing Connections with SSL and Start TLS 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 186: Other Security Resources
Other Security Resources More information about using SASL GSS-API, refer to chapter 11, “Managing SSL and SASL,” in the Red Hat Directory Server Administrator’s Guide. Other Security Resources For more information about designing a secure directory, take a look at the following: •...
Page 187: Chapter 9 Directory Design Examples
Chapter 9 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 188: 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 189: 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 190: Topology Design
An Enterprise • creates a class of service (CoS) that provides values for the example.com attribute depending upon whether 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. example.com For more information about CoS, refer to “About Class of Service,”...
Page 191: 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 192 An Enterprise Figure 9-3 Server Topology for example.com Corporation Modify requests from compatible servers 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 193: 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 117. The following sections provide more details about the supplier server architecture and the supplier-consumer server topology.
Page 194: 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 9-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 9-5.
Page 195: 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 196: 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 Red Hat Directory Server Installation Guide.
Page 197: 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 198: Schema Design
A Multinational Enterprise and Its Extranet • Many of the data elements need to accommodate data values of several different languages and charactersets. 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 199 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 Figure 9-1, on page 190, for more information about ou=resources this directory tree design.
Page 200: 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 9-8 Directory Tree for example.com International’s Extranet...
Page 201 A Multinational Enterprise and Its Extranet Figure 9-9 Database Topology for example.com Europe The database links point to databases stored locally in each country. For example, operation requests received by the Europe server for the data under example.com branch are chained by a database link to a database on a server in Austin, l=US Texas.
Page 202: Server Topology
A Multinational Enterprise and Its Extranet Figure 9-10 Database Topology for example.com International’s Extranet As illustrated in Figure 9-10, the master copy of the data for o=suppliers stored in database one, the master copy of the data for is stored in o=partners database two, and the master copy of the data for is stored in database...
Page 203 A Multinational Enterprise and Its Extranet Figure 9-11 Server Topology for example.com Europe ’s extranet data is mastered in Europe. This data is replicated to two example.com consumer servers in the US data center and two consumer servers in the Asia data center.
Page 204: Replication Design
A Multinational Enterprise and Its Extranet Figure 9-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 205: 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 additional example.com consumers do not affect the performance of the suppliers.
Page 206 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 workload managed by each supplier server.
Page 207: Security Design
A Multinational Enterprise and Its Extranet The same relationship as illustrated in Figure 9-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 208 A Multinational Enterprise and Its Extranet Red Hat Directory Server Deployment Guide • May 2005...
Page 209 Glossary access control instruction See ACI. ACI Also Access Control Instruction. An instruction that grants or denies permissions to entries in the directory. access control list See ACL. ACL Also Access Control List. The mechanism for controlling access to your directory.
Page 210 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 211 browser Software, such as Mozilla Firefox, used to request and view World Wide Web material stored as HTML files. The browser uses the HTTP protocol to communicate with the host server. browsing index Also virtual view index. Speeds up the display of entries in the Directory Server Console.
Page 212 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 213 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 214 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 215 hostname A name for a machine in the form machine.domain.dom, which is translated into an IP address. For example, is the machine www.example.com in the subdomain domain. example HTML Hypertext Markup Language. The formatting language used for documents on the World Wide Web. HTML files are plain text files with formatting codes that tell browsers such as the Mozilla Firefox how to display text, position graphics, and form items and to display links to other pages.
Page 216 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 217 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 218 nested role Allows the creation of roles that contain other roles. network management application Network Management Station component that graphically displays information about SNMP managed devices (which device is up or down, which and how many error messages were received, etc.). network management station See NMS.
Page 219 password file A file on Unix machines that stores Unix user login names, passwords, and user ID numbers. It is also known as because of /etc/passwd where it is kept. password policy A set of rules that governs how passwords are used in a given directory.
Page 220 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 221 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 222 service A background process on a Windows machine that is responsible for a particular system task. Service processes do not need human intervention to continue functioning. SIE Server Instance Entry. The ID assigned to an instance of Directory Server during installation. Simple Authentication and Security Layer See SASL.
Page 223 suffix The name of the entry at the top of the directory tree, below which data is stored. Multiple suffixes are possible within the same directory. Each database only has one suffix. superuser The most privileged user available on Unix machines. The superuser has complete access privileges to all files on the machine.
Page 224 uid A unique number associated with each user on a Unix system. URL Uniform Resource Locator. The addressing system used by the server and the client to request documents. It is often called a location. The format of a URL .
Page 225 Index proxy authentication 162 SASL 185 simple password 160 over TLS 162 bind rules 175, 177 branch point DN attributes 66, 68 for international trees 78 for replication and referrals 69 access network names 69 anonymous 159 browsing index 109 determining general types of 159 precedence rule 178 access control information (ACI) 174...
Page 226 custom schema files 55 Red Hat solution 17 directory tree access control considerations 70 branch point DN attributes 66, 68 for international trees 78 for replication and referrals 69 data access 38 network names 69 data management branching 65 replication example 131 creating structure 64 data master 35, 147 default 19...
Page 227 suffixes 94 hub supplier 121 equality index 108 examples deployment enterprise 187 extranet 196 multinational enterprise 196 illegal strings, passwords 172 replication index large sites 134 approximate 108 load balancing server traffic 133 browsing 109 local data management 131 equality 108 small sites 134 international 109 expiration of passwords...
Page 228 mail attribute 72 password policy attributes 169 managed roles 76 change after reset 170 minimum length, passwords 172 design 163 multi-master replication 117 expiration warning 171 with synchronization 147 global 164 multinational enterprise deployment 196 grace logins after password expiration 171 multiple databases 93 overview 169 password expiration 171...
Page 229 proxy authentication 162 supplier server 113 wide-area 128 pwdPolicysubentry attribute 167 reusing passwords 172 roles 75–76 compared to groups 76 filtered 76 managed 76 nested 76 Red Hat Directory Server 15 root suffix 94 referrals 97–102 branching to support 69 compared to chaining 104 default 98 LDAP 97...
Page 230 SHA encryption 173 trivial words 172 Simple Authentication and Security Layer 185 two-way multi-master replication 118 simple password 160 single-master replication defined 116 site survey 30 characterizing data 33 uid attribute 58, 72 identifying applications 31 identifying data sources 33 user authentication 160 network capabilities 126 user defined passwords 170...

This manual is also suitable for:

Directory server 7.1

Red Hat DIRECTORY SERVER 7.1 - DEPLOYMENT Deployment Manual

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 Synchronization

Chapter 8 Designing a Secure Directory

Chapter 9 Directory Design Examples

Quick Links

Need help?

Questions and answers

Subscribe to Our Youtube Channel

Related Manuals for Red Hat DIRECTORY SERVER 7.1 - DEPLOYMENT

Summary of Contents for Red Hat DIRECTORY SERVER 7.1 - DEPLOYMENT