HP-UX Directory Server deployment guide HP-UX Directory Server Version 8.
© Copyright 2009 Hewlett-Packard Development Company, L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. The information contained herein is subject to change without notice.
Table of Contents 1 Introduction to directory services..................................................................................9 1.1 About directory services...................................................................................................................9 1.1.1 About global directory services................................................................................................9 1.1.2 About LDAP..............................................................................
3.4.7 Creating custom schema files..................................................................................................34 3.4.8 Custom schema best practices.................................................................................................35 3.4.8.1 Naming schema files.......................................................................................................35 3.4.8.2 Using 'user defined' as the origin....................................................................
.3.1.3 Smart referrals.................................................................................................................64 5.3.1.4 Tips for designing smart referrals...................................................................................66 5.3.2 Using chaining.........................................................................................................................67 5.3.3 Deciding between referrals and chaining........................................................
7.2.4 Considering a data master......................................................................................................95 7.2.5 Determining the subtree to synchronize.................................................................................96 7.2.6 Interaction with a replicated environment.............................................................................96 7.2.7 Identifying the directory data to synchronize......................................................................
8.7.1.2 Permissions....................................................................................................................118 8.7.1.3 Bind rules.......................................................................................................................119 8.7.2 Setting permissions................................................................................................................119 8.7.2.1 The precedence rule................................................................
Index...............................................................................................................................
1 Introduction to directory services This document provides information on deploying the HP-UX Directory Server HP-UX Directory Server provides a centralized directory service for 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. Directory Server can even be extended to manage user profiles, preferences, and authentication.
1.1.2 About LDAP LDAP provides a common language that client applications and servers use to communicate with one another. LDAP is a "lightweight" version of the Directory Access Protocol (DAP) described by the ISO X.500 standard. DAP gives any application access to the directory through an extensible and robust information framework but at a high administrative cost. DAP uses a communications layer that is not the Internet standard protocol and has complex directory-naming conventions.
When communication takes place with TLS, the communication is usually encrypted. If clients have been issued certificates, TLS/SSL can be used by Directory Server to confirm that the client has the right to access the server. TLS/SSL is used to perform other security activities, such as message integrity checks, digital signatures, and mutual authentication between servers. NOTE: Directory Server runs as a daemon; the process is ns-slapd. 1.2.
• • cn=schema, the subtree containing the schema elements currently loaded in the server. user_suffix, the suffix for the default user database created when the Directory Server is setup. The name of the suffix is defined by the user when the server is created; the name of the associated database is userRoot. The database can be populated with entries by importing an LDIF file at setup or entries can be added to it later. The user_suffix suffix frequently has a dc naming convention, like dc=example,dc=com.
1.3.1 About directory entries LDAP Data Interchange Format (LDIF) is a standard text-based format for describing directory entries. An entry consists of a number of lines in the LDIF file (also called a stanza), which contains information about an object, such as a person in the organization or a printer on the network. Information about the entry is represented in the LDIF file by a set of attributes and their values.
1.4.1 Design process outline 1. Chapter 2 “Planning the directory data” The directory contains data such as user names, telephone numbers, and group details. This chapter analyzes the various sources of data in the organization and understand their relationship with one another. It describes the types of data that can be stored in the directory and other tasks to perform to design the contents of the Directory Server. 2.
For a comprehensive overview of creating and implementing a directory pilot, see Understanding and Deploying LDAP Directory Services (T. Howes, M. Smith, G. Good, Macmillan Technical Publishing, 1999).
2 Planning the directory data The data stored in the 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 the directory determines how the directory is structured, who is given access to the data, and how this access is requested and granted. This chapter describes the issues and strategies behind planning the directory's data. 2.
other media. These objects should be maintained in a file system. However, the directory can store pointers to these kinds of applications by using pointer URLs to FTP, HTTP, and other sites. 2.2 Defining directory needs When designing the directory data, think not only of the data that is currently required but also how the directory (and organization) is going to change over time.
• Determine data ownership. For each piece of data, determine the person responsible for ensuring that the data is up-to-date. • Determine data access. If data are imported 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.
Table 2-1 Example application data needs Application Class of data Data Phonebook People Name, email address, phone number, user ID, password, department number, manager, mail stop. Web server People, groups User ID, password, group name, groups members, group owner. Calendar server People, meeting rooms Name, user ID, cube number, conference room name.
• • Data owner Relationship to other directory data Study each kind of data to include in the 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 “Designing the directory schema”. A good idea is to use a table, similar to Table 2-3 “Directory data characteristics”, which characterizes the directory data.
all applications not using the directory can result in data being unsynchronized across the enterprise (which is what the directory is supposed to prevent). • Master the data in some application other than the directory, then write scripts, programs, or gateways to import that data into the directory.
• Allow an organization's administrator to create and manage entries for that organization. This approach allows an organization's administrators to function as the directory content managers. • Create roles that give groups of people read or write access privileges. For example, there can be roles created for human resources, finance, or accounting. Allow each of these roles to have read access, write access, or both to the data needed by the group.
some information may only need access controls and authentication measures to restrict access adequately; other sensitive information may need to be encrypted within the database as it is stored. In many countries, data protection laws govern how enterprises must maintain personal information and restrict who has access to the personal information.
• 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. 2.5 Repeating the site survey There may need to be more than one site survey, particularly if an enterprise has offices in multiple cities or countries.
3 Designing the directory schema The site survey conducted in Chapter 2 “Planning the directory data” revealed information about the data which will be stored in the directory. The directory schema describes the types of data in the directory, so determining what schema to use reflects decisions on how to represent the data stored in the directory. During the schema design process, each data element is mapped to an LDAP attribute, and related elements are gathered into LDAP object classes.
objectclasses: ( 2.5.6.6 NAME 'person' DESC 'Standard Person Object Class' SUP top MUST (objectclass $ sn $ cn) MAY (description $ seeAlso $ tele\ phoneNumber $ userPassword) X-ORIGIN 'RFC 2252' ) This schema entry states the object identifier, or OID, for the class (2.5.6.6), the name of the object class (person), a description of the class (Standard Person), then lists the required attributes (objectclass, sn, and cn) and the allowed attributes (description, seeAlso, telephoneNumber, and userPassword).
Table 3-1 Syntaxes support in Directory Server Syntax Description Binary Indicates that values for this attribute are binary. Boolean Indicates that this attribute has one of only two values, true or false. Country String Indicates that values for this attribute are limited to exactly two printable string characters; for example, US for the United States. DN Indicates that values for this attribute are DNs. DirectoryString Indicates that values for this attribute are case-insensitive strings.
3.3 Mapping the data to the default schema The data identified during the site survey, as described in “Performing a site survey”, must be mapped to the existing default directory schema. This section describes how to view the existing default schema and provides a method for mapping the data to the appropriate existing schema elements. If there are elements in the schema that do not match the existing default schema, create custom object classes and attributes.
Table 3-2 Data mapped to default directory schema (continued) Data Owner Object Class Attribute Home phone number HR inetOrgPerson homePhone Employee location IS inetOrgPerson localityName Office phone number Facilities person telephoneNumber In Table 3-2 “Data mapped to default directory schema”, the employee name describes a person. In the default directory schema, there is a person object class, which inherits from the top object class.
3.4.1 When to extend the schema While the object classes and attributes supplied with the Directory Server should meet most common corporate needs, a given object class may not store specialized information about an organization. Also, the schema may need extended to support the object classes and attributes required by an LDAP-enabled application's unique data needs. 3.4.
For example, suppose an administrator wants to create the attributes exampleDateOfBirth, examplePreferredOS, exampleBuildingFloor, and exampleVicePresident. A simple solution is to create several object classes that allow some subset of these attributes. • • One object class, examplePerson, is created and allows exampleDateOfBirth and examplePreferredOS. The parent of examplePerson is inetOrgPerson. A second object class, exampleOrganization, allows exampleBuildingFloor and exampleVicePresident.
3.4.5 Strategies for defining new attributes For both application compatibility and long-term maintenance, try to use standard attributes whenever possible. Search the attributes that already exist in the default directory schema and use them in association with a new object class or check out the Directory Server Schema Guide. However, if the standard schema does not contain all the information you need, then add new attributes and new object classes.
NOTE: Custom schema files should not be numerically or alphabetically higher than 99user.ldif or the server could experience problems. After creating custom schema files, there are two ways for the schema changes to be distributed among all servers: • • • Manually copy these custom schema files to the instance's schema directory, /etc/opt/dirsrv/slapd-instance_name/schema. To load the schema, restart the server or reload the schema dynamically by running the schema-reload.pl script.
3.4.8.2 Using 'user defined' as the origin Do not use 'user defined' in the X-ORIGIN field of custom schema files (such as 60example.ldif), because 'user defined' is used internally by the Directory Server when a schema is added over LDAP. In custom schema files, use something more descriptive, such as 'Example Corp. defined'. However, if the custom schema elements are added directly to the 99user.ldif manually, use 'user defined' as the value of X-ORIGIN.
3.5.1 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. NOTE: Schema checking checks only that the proper attributes are present. It does not verify whether attribute values are in the correct syntax for the attribute. By default, the directory enables schema checking. HP recommends not disabling this feature.
consistency in replicated schema allows replication to continue smoothly. Consider the following points for maintaining consistent schema in a replicated environment: • Do not modify the schema on a read-only replica. Modifying the schema on a read-only replica introduces an inconsistency in the schema and causes replication to fail. • Do not create two attributes with the same name that use different syntaxes.
4 Designing the directory tree The directory tree provides a way to refer to the data stored by the directory service. The types of information stored in the directory, the physical nature of the enterprise, the applications used with the directory, and the types of replication implemented shape the design of the directory tree. This chapter outlines the steps for designing the directory tree. 4.
information and the directory schema). For more information on these standard directory suffixes, see the HP-UX Directory Server administrator guide. 4.2.1.1 Suffix naming conventions All entries in the directory should be located below a common base entry, the root suffix. When choosing a name for the root directory suffix, consider the following: • • • • Globally unique. Static, so it rarely, if ever, changes. Short, so that entries beneath it are easier to read on screen.
The databases could be stored on a single server or multiple servers depending on resource constraints. 4.2.2 Creating the directory tree structure Decide whether to use a flat or a hierarchical tree structure. As a general rule, try to make the directory tree as flat as possible. However, a certain amount of hierarchy can be important later when information is partitioned across multiple databases, prepare replication, and set access controls.
Figure 4-2 Example environment directory tree Branching in a hosting environment For a hosting environment, create a tree that contains two entries of the object class organization (o) and one entry of the object class organizationalUnit (ou) beneath the root suffix. For example, Example ISP branches their directory as shown below. Figure 4-3 Example hosting directory tree 4.2.2.
Figure 4-5 Directory tree for example isp Beneath the root suffix entry o=example, c=US, the tree is split into three branches. The ISP branch contains customer data and internal information for Example ISP. The Internet branch is the domain tree. The groups branch contains information about the administrative groups. Consider the following when choosing attributes for the branch points: • Be consistent.
NOTE: A common mistake is to assume that the directory is searched based on the attributes used in the distinguished name. The distinguished name is only a unique identifier for the directory entry and cannot be used as a search key. Instead, search for entries based on the attribute-data pairs stored on the entry itself.
Figure 4-8 Directory branching for example isp After creating the initial structure of their directory tree, they create additional branches as follows: Figure 4-9 Extended branching for example isp Both the enterprise and the hosting organization design their data hierarchies based on information that is not likely to change often. 4.2.2.4 Access control considerations Introducing a hierarchy into the directory tree can be used to enable certain types of access control.
However, ACI filters can be difficult to manage. Decide which method of access control is best suited to the directory: organizational branching in the directory tree hierarchy, ACI filters, or a combination of the two. 4.2.3 Naming Entries After designing the hierarchy of the directory tree, decide which attributes to use when naming the entries within the structure. Generally, names are created by choosing one or more of the attribute values to form a relative distinguished name (RDN).
attribute instead of the uid attribute if the enterprise does not assign employee numbers or user IDs for temporary or contract employees. • employeeNumber For employees of the inetOrgPerson object class, consider using an employer assigned attribute value such as employeeNumber. Whatever is used for an attribute-data pair for person entry RDNs, make sure that they are unique, permanent values. Person entry RDNs should also be readable.
In a hosting environment, include the following attributes in the organization's entry: • • o objectClass with values of top and organization 4.2.3.4 Naming other kinds of entries The directory contains entries that represent many things, such as localities, states, countries, devices, servers, network information, and other kinds of data. For these types of entries, use the cn attribute in the RDN if possible. Then, for naming a group entry, name it something like cn=administrators, dc=example,dc=com.
Each role has members, entries that possess the role. Members can be specified either explicitly (meaning each entry contains an attribute associating it with a role) or dynamically (by creating a filter that assigns entries to roles according to an attribute contained in the entry). How role membership is specified depends on the type of role. There are three types of roles: • • • Managed roles create an explicit, enumerated list of members. Managed roles are added to entries using the nsRoleDN attribute.
• The attribute value stored in the CoS template entry. Each CoS template entry supplies the attribute value for a particular CoS. • The object class of the entry. CoS attribute values are generated only when an entry contains an object class allowing the attribute when schema checking is turned on; otherwise, all attribute values are generated. • The attribute stored in some particular entry in the directory tree.
Figure 4-10 Examples of a flat and an organizationally-based DIT Using a hierarchical DIT, a deployment must then determine the subject domain of the hierarchy. Only one choice can be made; the natural tendency is to choose the organizational hierarchy. This view of the organization serves well in many cases, but having only a single view can be very limiting for directory navigation and management.
Figure 4-11 A combined DIT using views The DIT Figure 4-11 “A combined DIT using views” in illustrates what happens when the two DITs shown in Figure 4-10 “Examples of a flat and an organizationally-based DIT” are combined using views. Because views inherently allow entries to appear in more than one place in a view hierarchy, this feature has been used to expand the ou=Sales entry to enable viewing the Sales entries either by location or by product.
Figure 4-12 A DIT with a virtual DIT view hierarchy • • • The sub-tree ou=People contains the real Entry A and Entry B entries. The sub-tree ou=Location Views is a view hierarchy. The leaf nodes ou=Sunnyvale and ou=Mountain View each contain an attribute, nsviewfilter, which describes the view. These are leaf nodes because they do not contain the real entries. However, when a client application searches these views, it finds Entry A under ou=Sunnyvale and Entry B under ou=Mountain View.
in the directory is not an all-or-nothing operation, it can be performed over a period of time and without service disruption. • Using multiple virtual DIT views for navigation and management allows for more flexible use of the directory service. With the functionality provided by virtual DIT views, an organization can use both the old and new methods to organize directory data without any requirement to place entries at certain points in the DIT.
It may be desirable to limit the type of entry that the view should contain. For example, to limit this hierarchy to contain only people entries, add an nsfilter attribute to ou=Location Views, dc=example, dc=com with the filter value (objectclass=organizationalperson). Each view with a filter restricts the content of all descendant views, while descendant views with filters also restrict their ancestor's contents.
working with views. Except for a few specialized cases, there is no need for directory users to know that views are being used in a Directory Server instance; views appear and behave like conventional DITs. Certain types of applications may have problems working with a views-enabled directory service. For example: • Applications that use the DN of a target entry to navigate up the DIT.
Figure 4-14 Using the l attribute to represent different countries 4.5.2 Directory tree for an ISP Internet service providers (ISPs) may support multiple enterprises with their directories. ISP should consider each of the customers as a unique enterprise and design their directory trees accordingly. For security reasons, each account should be provided a unique directory tree with a unique suffix and an independent security policy.
5 Designing the directory topology Chapter 4 “Designing the directory tree” covers how to design the directory service stores entries. Because HP-UX Directory Server can store a large number of entries, it is possible to distribute directory entries across more than one server. The directory's topology describes how the directory tree is divided among multiple physical Directory Servers and how these servers link with one another. This chapter describes planning the topology of the directory service. 5.
5.2.1 About using multiple databases Directory Server stores data in LDBM databases. This a high-performance, disk-based database. Each database consists of a set of large files that contain all the data assigned to it. Different portions of the directory tree can be stored in different databases. For example, Figure 5-1 “Storing suffix data in separate databases” shows three suffixes being stored in three separate databases.
5.2.2 About suffixes Each database contains the data within a specific suffix of the Directory Server. Both root and subsuffixes can be created to organize the contents of the directory tree. A root suffix is the entry at the top of a tree. It can be the root of the directory tree or part of a larger tree designed for the Directory Server. A subsuffix is a branch beneath a root suffix. The data for root and subsuffixes are contained by databases. For example, Example Corp.
The o=NetscapeRoot and dc=example,dc=com suffixes are both root suffixes. The ou=testing,dc=example,dc=com suffix, the ou=development,dc=example,dc=com suffix, and the ou=partners,ou=development,dc=example,dc=com suffix are all subsuffixes of the dc=example,dc=com root suffix. The root suffix dc=example,dc=com contains the data in the ou=marketing branch of the original directory tree. Using multiple root suffixes The directory service might contain more than one root suffix.
default referral can be set for the Directory Server and a separate default referral for each database. The default referral for each database is done through the suffix configuration information. When the suffix of the database is disabled, configure the directory service to return a default referral to client requests made to that suffix. For more information about suffixes, refer to “About suffixes”. For information on configuring suffixes, refer to the HP-UX Directory Server administrator guide.
Configure the default referral to point to a Directory Server that has more information about the distribution of the directory service. Default referrals for the server are set by the nsslapd-referral attribute. Default referrals for each database in the directory installation are set by the nsslapd-referral attribute in the database entry in the configuration. These attribute values are stored in the dse.ldif file.
The same mechanism can be used to redirect queries to a different server that uses a different namespace. For example, an employee working in the Italian office of Example Corp. makes a request to the European directory service for the phone number of an Example Corp. employee in America. The directory service returns the referral ldap://europe.example.com:389/ou=US employees,dc=example,dc=com.
5.3.1.4 Tips for designing smart referrals Even though smart referrals are easy to implement, consider the following points before using them: • Keep the design simple. Deploying the directory service using a complex web of referrals makes administration difficult. Overusing smart referrals can also lead to circular referral patterns. For example, a referral points to an LDAP URL, which in turn points to another LDAP URL, and so on until a referral somewhere in the chain points back to the original server.
5.3.2 Using chaining Chaining is a method for relaying requests to another server. This method is implemented through database links. A database link, as described in “Distributing the directory data”, contains no data. Instead, it redirects client application requests to remote servers that contain the data. During the chaining process, a server receives a request from a client application for data that the server does not contain.
The following sections describe some of the more specific differences between referrals and chaining in greater detail. 5.3.3.1 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. For example, a client application may have permissions to communicate with only one server inside a firewall.
Performing search requests using chaining The problem of replicating client entries across servers is resolved using chaining. On a chained system, the search request would occur as follows: Figure 5-12 Sending a client request to a server using chaining In the illustration above, the following steps are performed: 1. 2. 3. 4. The client application binds with Server A, and Server A tries to confirm that the user name and password are correct.
1. 2. 3. 4. 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. Server A sends a bind request to Server B. Server B sends an acceptance response to Server A. Server A then processes the client application's request using another database link.
• International index Improves the performance of searches for information in international directories. Configure the index to apply a matching rule by associating a locale (internationalization OID) with the attribute being indexed. • Browsing index or virtual list view (VLV) index Improves the display performance of entries in the Directory Server Console. A browsing index can be created on any branch in the directory tree to improve the display performance. 5.4.
6 Designing the replication process Replicating the directory contents increases the availability and performance of the directory service. Chapter 4 “Designing the directory tree” and Chapter 5 “Designing the directory topology” cover the design of the directory tree and the directory topology. This chapter addresses the physical and geographical location of the data and, specifically, how to use replication to ensure the data is available when and where it is needed.
For more information on how to set up the directory tree, see Chapter 4 “Designing the directory tree”. The replication mechanism also requires that one database correspond to one suffix. A suffix (or namespace) that is distributed over two or more databases cannot be replicated. 6.1.1.2 Read-write and read-only replicas A database that participates in replication is defined as a replica. Directory Server supports two types of replicas: read-write and read-only.
When an entry is modified, a change record describing the LDAP operation that was performed is recorded in the changelog. The changelog size is maintained with two attributes, nsslapd-changelogmaxage or nsslapd-changelogmaxentries. These attributes trim the old changelogs to keep the changelog size reasonable. 6.1.1.5 Replication agreement Directory Servers use replication agreements to define replication. A replication agreement describes replication between a single supplier and a single consumer.
appropriate for the environment. These basic scenarios can be combined to build the replication topology that best suits the network environment. • • • • “Single-master replication” “Multi-master replication” “Cascading replication” “Mixed environments” 6.2.1 Single-master replication In the most basic replication configuration, a supplier server copies a replica directly to one or more consumer servers.
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. Consequently, to create a multi-master environment between two supplier servers that share responsibility for the same data, create more than one replication agreement. Figure 6-2 Multi-master replication configuration (two suppliers) In the above illustration, supplier A and supplier B each hold a read-write replica of the same data.
Figure 6-4 “Multi-master replication configuration B (four suppliers)” illustrates a topology where each supplier server feeds data to two other supplier servers (which also function as consumers). Only eight replication agreements exist between the four supplier servers, compared to the twelve agreements shown for the topology in Figure 6-3 “Multi-master replication configuration A (four suppliers)”.
Figure 6-5 Replication traffic in a multi-master environment 6.2.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 also maintains a changelog like a typical supplier server. Hub suppliers forward master data as they receive it from the original suppliers.
Figure 6-6 Cascading replication scenario Figure 6-7 “Replication traffic and changelogs in cascading replication” illustrates the same scenario from a different perspective, which shows how the replicas are configured on each server (read-write or read-only), and which servers maintain a changelog.
Figure 6-7 Replication traffic and changelogs in cascading replication 6.2.4 Mixed environments Any of the replication scenarios can be combined to meet suit the needs of the network and directory environment. One common combination is to use a multi-master configuration with a cascading configuration. 6.
Figure 6-8 Combined multi-master and cascading replication 6.3 Defining a replication strategy The replication strategy is determined by the services that must be provided. To determine the replication strategy, start by performing a survey of the network, users, applications, and how they use the directory service. • Assess the resources within the network, the traffic loads, and resource requirements for the directory service.
be maintained in a single location, such as the company headquarters, or each local site can manage the parts of the DIT that are relevant for them. See “Using replication for local availability” for more information. • In all cases, balance the load of requests serviced by the Directory Servers and avoid network congestion. See “Using replication for load balancing” for more information. After planning the replication strategy, it is possible to deploy the directory service.
6.3.3 Replication resource requirements Using replication requires more resources. Consider the following resource requirements when defining the replication strategy: • Disk usage — On supplier servers, the changelog is written after each update operation. Supplier servers that receive many update operations may experience higher disk usage. NOTE: Each supplier server uses a single changelog.
6.3.5 Replication across a wide-area network Wide-area networks typically have higher latency, a higher bandwidth-delay product, and lower speeds than local area networks . Directory Server version 7.1 and later support efficient replication when a supplier and consumer are connected via a wide-area network.
network sorts to provide failover to the backup Directory Servers. For information on setting up and using DNS round-robins or network sorts, refer to the DNS documentation. 6.3.7 Using replication for local availability The necessity of replicating for local availability is determined by the quality of the network as well as the activities of the site.
Table 6-1 Effects of replication and remote lookup on the network Load type Objects1 Accesses/day2 Avg. entry size Load Replication 1 million 100,000 1Kb 100Mb/day Remote Lookup 100 1,000 1Kb 1Mb/day 1 2 For replication, objects refers to the number of entries in the database. For remote lookup, it refers to the number of users who access the database. For replication, Accesses/day is based on a 10% change rate to the database that needs to be replicated.
6.3.8.2 Example of load balancing for improved performance Suppose that the enterprise has the following characteristics: • • • • Uses a Directory Server that includes 1.
If the hardware that runs the Directory Servers supports 500 reads per second, at least six or seven Directory Servers kust be used to support this load. For enterprises with a million directory users, add more Directory Servers for local availability purposes. There are several different methods of replication: • Place two Directory Servers in a multi-master configuration in one city to handle all write traffic.
6.4 Using replication with other Directory Server features Replication interacts with other Directory Server features to provide advanced replication features. The following sections describe feature interactions to better design the replication strategy. 6.4.1 Replication and access control The directory service stores ACIs as attributes of entries. This means that the ACI is replicated together with other directory content. This is important because Directory Server evaluates ACIs locally.
Figure 6-10 Replicating chained databases 6.4.4 Schema replication In all replication scenarios, before replicating data to consumer servers, the supplier server checks whether its own version of the schema is synchronized with the version of the schema stored on the consumer servers. The following conditions apply: • • • If the schema entries on both supplier and consumers are the same, the replication operation proceeds.
and all other servers in the replication environment that will function as consumers for the schema information. NOTE: Special replication agreements are not required to replicate the schema. If replication has been configured between a supplier and a consumer, schema replication occurs by default. Changes made to custom schema files are only replicated if the schema is updated using LDAP or the Directory Server Console.
7 Designing synchronization An important factor to consider while conducting the site survey for an existing site (“Performing a site survey”) is to include the structure and data types of Active Directory directory services. Through Windows Sync, an existing Windows directory service can be synchronized and integrated with the Directory Server, including creating, modifying, and deleting Windows accounts on the Directory Server or, oppositely, the Directory Server accounts on Windows.
NOTE: Any descendant container entries need to be created separately on the Windows server by an administrator; Windows Sync does not create container entries. 7.1.2 Changelogs The Directory Server maintains a changelog, a database that records modifications that have occurred. The changelog is used by Windows Sync to coordinate and send changes made to the Windows synchronization peer server. Changes to entries in the Windows server are found by using Active Directory's Dirsync search feature.
• • Quality of the LANs and WANs connecting different buildings or remote sites and the amount of available bandwidth. 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 the directory than a site containing engineering staff that uses the directory for simple telephone book purposes. 7.2.
Windows and Directory Server services are kept continuously synchronized through the synchronization agreement, which minimizes potential conflicts between the two services. However, if the Directory Server is part of a replication deployment, then conflicts could arise between changes made within the Directory Server replication scenario and the Windows domain depending on the replication schedule.
Figure 7-1 Multi-master Directory Server — Windows domain synchronization Only create one synchronization agreement to any given Windows domain. To propagate the changes and information synchronized from the Windows server throughout the Directory Server, create the synchronization agreement with a multi-master supplier, preferably a data master for the replication deployment. 7.2.7 Identifying the directory data to synchronize Windows Sync synchronizes user and group entries between directory services.
Plan both the entries and the data contained in those entries according to the available synchronization attributes. The synchronized attributes and the differences between Directory Server and Active Directory schema are described in “Schema elements sycnhronized between Active Directory and Directory Server”. 7.2.
• • ntDomainUser corresponds to the samAccountName attribute for Active Directory entries. User entries only. ntGroupType is set automatically for Windows groups that are synchronized, but must be set manually on Directory Server entries before they are synchronized. Group entries only. A pre-defined list of attributes are synchronized between Directory Server and Active Directory entries.
Table 7-2 User schema that are the same in Directory Server and Windows servers cn physicalDeliveryOfficeName description postOfficeBox destinationIndicator postalAddress facsimileTelephoneNumber postalCode givenName registeredAddress homePhone sn homePostalAddress st initials street l telephoneNumber mail teletexTerminalIdentifier manager telexNumber mobile title o userCertificate ou x121Address pager 7.3.
7.3.2.3 Values for street and streetAddress Active Directory uses the attribute streetAddress for a user or group's postal address; this is the way that Directory Server uses the street attribute. There are two important differences in the way that Active Directory and Directory Server use the streetAddress and street attributes, respectively: • • In Directory Server, streetAddress is an alias for street.
Table 7-3 Group entry attribute mapping between Directory Server and Active Directory (continued) Directory Server Active Directory ntGroupId cn name sAMAccountName ntGroupType groupType Table 7-4 Group entry attributes that are the same between Directory Server and Active Directory cn member description ou l seeAlso 7.3.4 Group schema differences between Directory Server and Active Directory Although Active Directory supports the same basic X.
8 Designing a secure directory How the data in HP-UX Directory Server is secured affects all the previous design areas. Any security design needs to protect the data contained by the directory and meet the security and privacy needs of the users and applications. This chapter describes how to analyze the security needs and explains how to design the directory to meet these needs. 8.1 About security threats There are many potential threats to the security of the directory.
8.1.3 Denial of service In 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 use all the system's resources, thereby preventing these resources from being used by anyone else. Directory Server can prevent denial of service attacks by setting limits on the resources allocated to a particular bind DN.
8.2.2 Ensuring data privacy and integrity When using the directory to support exchanges with business partners over an extranet or to support e-commerce applications with customers on the Internet, ensure the privacy and the integrity of the data exchanged. There are several ways to do this: • • By encrypting data transfers. By using certificates to sign data transfers.
Table 8-1 Security methods available in Directory Server Security method Description Authentication A means for one party to verify another's identity. For example, a client gives a password to Directory Server during an LDAP bind operation. Password policies Defines the criteria that a password must satisfy to be considered valid; for example, age, length, and syntax. Encryption Protects the privacy of information.
Anonymous access can be limited. Usually directory administrators only allow anonymous access for read, search, and compare privileges (not for write, add, delete, or selfwrite). Often, administrators limit access to a subset of attributes that contain general information such as names, telephone numbers, and email addresses.
8.4.3 Certificate-based authentication An alternative form of directory authentication involves using digital certificates to bind to the directory. The directory prompts users for a password when they first access it. However, rather than matching a password stored in the directory, the password opens the user's certificate database. If the user supplies the correct password, the directory client application obtains authentication information from the certificate database.
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 a user is granted proxy rights, that user has the ability to proxy for any user under the target; there is no way to restrict the proxy rights to only certain users. For example, if an entity has proxy rights to the dc=example, dc=com tree, that entity can do anything.
Such a policy is known as the user level or local password policy. When configured and enabled, the policy is applied to the specified user only. This can define different password policies for different directory users. For example, specify that some users change their passwords daily, some users change it monthly, and all other users change it every six months.
NOTE: The global and local password policies are mutually exclusive. That is, if a local password policy is defined and enabled for a subtree or user, Directory Server applies that policy during the bind process. In the absence of a local password policy, the server subjects the user to the global password policy. The password policy design requires sending the password policy request control with the bind request.
Figure 8-1 Password policy checking process In addition to bind requests, password policy checking also occurs during add and modify operations if the userPassword attribute (explained in the following section) is present in the request.
Modifying the value of userPassword checks two password policy settings: • • The password minimum age policy is activated. If the minimum age requirement has not been satisfied, the server returns a [constraintViolation] error. The password update operation fails. The password history policy is activated. If the new value of userPassword is in the password history, or if it is the same as the current password, the server returns a [constraintViolation] error. The password update operation fails.
use trivial words; any word that can be found in a dictionary, names of pets or children, birthdays, user IDs, or any other information about the user that can be easily discovered (or stored in the directory itself), is a poor choice for a password. A good password should contain a combination of letters, numbers, and special characters. For the sake of convenience, however, users often use passwords that are easy to remember.
The default password syntax requires a minimum password length of eight characters and that no trivial words are used in the password. A trivial word is any value stored in the uid, cn, sn, givenName, ou, or mailattributes of the user's entry.
8.6.2.10 Password storage schemes The password storage scheme specifies the type of encryption used to store Directory Server passwords within the directory. The Directory Server supports several different password storage schemes: • Salted Secure Hash Algorithm (SSHA, SSHA-256, SSHA-384, and SSHA-512). This is the most secure password storage scheme and is the default. The recommended SSHA scheme is SSHA-256 or stronger. • CLEAR No encryption.
8.7 Designing access control After deciding on the authentication schemes to use to establish the identity of directory clients, decide how to use those schemes to protect the information contained in the directory. Access control can specify that certain clients have access to particular information, while other clients do not. Access control is defined using one or more access control lists (ACLs).
A permission can be set to allow 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. 8.7.1.1 Targets Decide which entry is targeted by every ACI created in the directory. Targeting a directory branch point entry includes that branch point and all its child entries in the scope of the permission.
8.7.1.3 Bind rules The bind rule usually indicates the bind DN subject to the permission. It can also specify bind attributes such as time of day or IP address. Bind rules easily express that the ACI applies only to a user's own entry. This allows users to update their own entries without running the risk of a user updating another user's entry.
forbidding access, the directory forbids access regardless of any conflicting permissions that may grant access. Limit the scope of allow access rules to include only the smallest possible subset of users or client applications. For example, permissions can be set 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 the uid attribute.
For example, allow read access for any entry that contains an organizationalUnit attribute that is set to Marketing. Filtered access control rules allow predefined levels of access. Suppose the directory contains home address and telephone number information. Some people want to publish this information, while others want to be unlisted. There are several ways to address that: • • • Create an attribute on every user's directory entry called publishHomeContactInfo.
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, man\ ager: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 results in ent
For more information on macro ACIs, refer to the "Managing Access Control" chapter in the HP-UX Directory Server administrator guide. • Balance allow and deny permissions. Although the default rule is to deny access to any user who has not been specifically granted access, it may be better to reduce the number of ACIs by using one ACI to allow access close to the root of the tree, and a small number of deny ACIs close to the leaf entries.
Database encryption allows individual attributes to be encrypted as they are stored in the database. When configured, every instance of a particular attribute, even index data, is encrypted and can only be accessed via a secure channel, such as SSL/TLS. For information on using database encryption, refer to the "Configuring Directory Databases" chapter in the HP-UX Directory Server administrator guide. 8.
9 Directory design examples The design the directory service depends on the size and nature of the enterprise. This chapter provides a couple of examples of how a directory can be applied within a variety of different settings. These examples are a starting point for developing a real-life directory service deployment plan. 9.1 Design example: A local enterprise Example Corp., an automobile parts manufacturer, is a small company that consists of 500 employees. Example Corp.
9.1.3 Local enterprise directory tree design Based on the data and schema design described in the preceding sections, Example Corp. creates the following directory tree: • • • The root of the directory tree is Example Corp.'s Internet domain name: dc=example, dc=com. The directory tree has four branch points: ou=people, ou=groups, ou=roles, and ou=resources. All Example Corp.'s people entries are created under the ou=people branch.
Figure 9-1 Directory tree for Example Corp. 9.1.4 Local enterprise topology design At this point, Example Corp. needs to design its database and server topologies. The following sections describe each topology in detail. 9.1.4.
Figure 9-3 Server topology for Example Corp. 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 data being modified. 9.1.5 Local enterprise replication design Example Corp. decides to use a multi-master replication design to ensure the high availability of its directory data.
Figure 9-4 Supplier architecture for Example Corp. 9.1.5.2 Supplier consumer architecture The following diagram describes how the supplier servers replicate to each consumer in the Example Corp. deployment of the directory. Each of the three consumer servers is updated by the two supplier servers. This ensures that the consumers will not be affected if there is a failure in one of the supplier servers. 9.
Figure 9-5 Supplier and consumer architecture for Example Corp. 9.1.6 Local enterprise security design Example Corp. decides on the following security design to protect its directory data: • They create an ACI that allows employees to modify their own entries. Users can modify all attributes except the uid, manager and department attributes. • • To protect the privacy of employee data, they create an ACI that allows only the employee and their manager to see the employee's home address and phone number.
9.1.7 Local enterprise tuning and optimizations The company uses the following tactics to optimize its deployment of Directory Server: • Indexing commonly searched data. Model the usage or analyze the logs of the live environment, and create indexes to support the most common types of search operations. Avoid creating superfluous indexes: they can slow down update operations. • Optimizing the entry and database caches. Example Corp.
9.2.1 Multinational enterprise data design Example Corp. International creates a deployment team to perform a site survey. The deployment team determines the following from the site survey: • • • • A messaging server is used to provide email routing, delivery, and reading services for most of Example Corp.'s sites. An enterprise server provides document publishing services. All servers run on Red Hat Enterprise Linux 5 (32-bit). Example Corp. needs to allow data to be managed locally.
• • Under the dc=exampleNet, dc=com branch, Example Corp. creates three branches. One branch for suppliers (o=suppliers), one branch for partners (o=partners), and one branch for groups (ou=groups). The ou=groups branch of the extranet contains entries for the administrators of the extranet as well as for mailing lists that partners subscribe to for up-to-date information on automobile parts manufacturing.
Figure 9-8 Directory tree for Example Corp. International's extranet 9.2.4 Multinational enterprise topology design At this point, Example Corp. designs its database and server topologies. The following sections describe each topology in more detail. 9.2.4.1 Database topology The following diagram illustrates the database topology of one of Example Corp.'s main localities, Europe: Figure 9-9 Database topology for Example Corp. Europe The database links point to databases stored locally in each country.
The master copy of the data for dc=example, dc=com and the root entry, dc=com, is stored in the l=Europe database. The data center in Europe contains the master copies of the data for the extranet. The extranet data is stored in three databases, one for each of the main branches. The master copy of the data for o=suppliers is stored in database one (DB1), that for o=partners is stored in database two (DB2), and that for ou=groups is stored in database three (DB3).
Figure 9-11 Server topology for Example Corp. Europe The data master for Example Corp.'s extranet is in Europe. This data is replicated to two consumer servers in the US data center and two consumer servers in the Asia data center. Overall, Example Corp. requires ten servers to support the extranet. The following diagram illustrates the server architecture of Example Corp.
Figure 9-12 Server topology for Example Corp. International's extranet The hub servers replicate data to two consumer servers in each of the data centers in Europe, the US and Asia. 9.2.5 Multinational enterprise replication design Example Corp. considers the following points when designing replication for its directory: • • • • Data will be managed locally. The quality of network connections varies from site to site. Database links will be used to connect data on remote servers.
Figure 9-13 Supplier architecture for Example Corp. Europe Each locality contains two suppliers, which share master copies of the data for that site. Each locality is therefore responsible for the master copy of its own data. Using a multi-master architecture ensures the availability of the data and helps balance the workload managed by each supplier server. To reduce the risk of total failure, Example Corp. uses multiple read-write supplier Directory Servers at each site.
Figure 9-14 Multi-master replication design for Example Corp. Europe and Example Corp. US The same relationship exists between Example Corp. US and Example Corp. Asia, and between Example Corp. Europe and Example Corp. Asia. 9.2.6 Multinational enterprise security design Example Corp. International builds upon its previous security design, adding the following access controls to support its new multinational intranet: • • Example Corp.
For more information about macro ACIs, refer to the HP-UX Directory Server administrator guide. Example Corp. adds the following access controls to support its extranet: • • • 140 Example Corp. decides to use certificate-based authentication for all extranet activities. When people log in to the extranet, they need a digital certificate. The directory is used to store the certificates.
10 Support and other resources 10.1 Contacting HP 10.1.1 Information to collect before contacting HP Be sure to have the following information available before you call contact HP: • • • • • • Software product name Hardware product model number Operating system type and version Applicable error message Third-party hardware or software Technical support registration number (if applicable) 10.1.
• HP-UX Directory Server administration server guide The Administration Server is a support server that drives access to the Directory Server Console , provides a web server for Directory Server web applications, and stores some Directory Server configuration. This guide covers how to manage the Administration Server through the Console, through the command line, and through the web services. It also covers basic Administration Server concepts.
10.2.3 Troubleshooting resources • You can search a technical knowledge database available on the HP IT Resource Center (ITRC) website at: http://itrc.hp.com/ • To seek solutions to problems, you can post messages on the ITRC Forums page at the following website (select the HP-UX area in the Areas of peer problem solving section): http://forums.itrc.hp.com/ 10.3 Typographic conventions This document uses the following typographical conventions: Book title The title of a book.
Glossary A access control instruction See ACI. access control list See ACL. access rights In the context of access control, specify the level of access granted or denied. Access rights are related to the type of operation that can be performed on the directory. The following rights can be granted or denied: read, write, add, delete, search, compare, selfwrite, proxy and all.
bind distinguished name See bind DN. bind DN Distinguished name used to authenticate to Directory Server when performing an operation. bind rule In the context of access control, the bind rule specifies the credentials and conditions that a particular user or client must satisfy in order to get access to directory information. branch entry An entry that represents the top of a subtree in the directory.
CoS definition entry Identifies the type of CoS you are using. It is stored as an LDAP subentry below the branch it affects. CoS template entry Contains a list of the shared attribute values. See also template entry. D daemon A background process on a Unix machine that is responsible for a particular system task. Daemon processes do not need human intervention to continue functioning. DAP Directory Access Protocol. The ISO X.500 standard protocol that provides client access to the directory.
file type The format of a given file. For example, graphics files are often saved in GIF format, while a text file is usually saved as ASCII text format. File types are usually identified by the file extension (for example, .GIF or .HTML). filter A constraint applied to a directory query that restricts the information returned. filtered role Allows you to assign entries to the role depending upon the attribute contained by each entry. You do this by specifying an LDAP filter.
L LDAP Lightweight Directory Access Protocol. Directory service protocol designed to run over TCP/IP and across multiple platforms. 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, then completing the query through LDAP. A sample LDAP URL is ldap://ldap.example.com.
are automatically replicated to the other server. In case of conflict, a time stamp is used to determine which server holds the most recent version. multiplexor The server containing the database link that communicates with the remote server. N n+1 directory problem The problem of managing multiple instances of the same information in different directories, resulting in increased hardware and personnel costs. name collisions Multiple entries with the same distinguished name.
presence index Allows searches for entries that contain a specific indexed attribute. protocol A set of rules that describes how devices on a network exchange information. protocol data unit See PDU. proxy authentication A special form of authentication where the user requesting access to the directory does not bind with its own DN but with a proxy DN. proxy DN Used with proxied authorization.
S SASL An authentication framework for clients as they attempt to bind to a directory. Also Simple Authentication and Security Layer . schema Definitions describing what types of information can be stored as entries in the directory. When information that does not match the schema is stored in the directory, clients attempting to access the directory may be unable to display the proper results. schema checking Ensures that entries added or modified in the directory conform to the defined schema.
superuser The most privileged user available on Unix machines. The superuser has complete access privileges to all files on the machine. Also called root. supplier Server containing the master copy of directory trees or subtrees that are replicated to replica servers. 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.
Index A access anonymous, 106 determining general types of, 106 precedence rule, 119 access control information (ACI), 117 bind rules, 117 filtered rules, 120 format, 117 password protection and, 116 permission, 117 target, 117 usage advice, 122 where to place, 120 access rights get effective rights, 121 granting, 104 account deactivation, 109 account lockout, 116 Active Directory schema differences between Directory Server, 100, 102 allow permissions, 119 anonymous access, 106 for read, 23 overview, 106 ap
Directory Server, 9 database, 12 directory service, 9, 10 global, 9 LDAP, 10 directory tree, 39 access control considerations, 45 branch point DN attributes , 42 for international trees , 56 for replication and referrals , 44 network names , 44 branching, 41 creating structure, 41 default, 11 design choosing a suffix , 39 creating structure , 41 naming entries , 41 examples international enterprise , 56 ISP , 57 replication considerations, 44 distinguished name name collision, 46 DIT, 39 DNS, 9 documentatio
M mail attribute, 46 managed roles, 49 minimum length, passwords, 115 multi-master replication, 76 disk space considerations, 84 multinational enterprise deployment, 131 multiple databases, 60 N name collision, 46 naming entries, 46 group entries, 47 organization, 47 people, 46 nested roles, 49 network names, branching to reflect, 44 network, load balancing, 86 nsRole, 48 nsview, 51 nsviewfilter, 51 O object class defining in schema, 32 standard, 29 object identifier. See OID.
single-master, 76 site survey, 83 strategy, 82 supplier server, 74 wide-area, 85 reporting documentation errors email address, 141 reusing passwords, 115 roles, 48 compared to groups, 49 filtered, 49 managed, 49 nested, 49 root suffix, 61 S Salted SHA encryption, 116 SASL authentication, 124 schema, 27 adding new attributes, 34 assigning OIDs, 32 best practices, 35 checking, 37 consistency, 36 custom files, 34 deleting elements, 34 differences between Directory Server and Active Directory, 100, 102 cn, 100
