Manuals / Brands / Computer Equipment / Software / HP / Computer Equipment / Software

HP UX Direry Server 6.4.4 Schema replication, WARNING, Figure 6-10Replicating chained databases, See “Creating custom schema files” for more information

1 160

Download 160 pages, 6.11 Mb

Figure 6-10 Replicating chained databases6.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.

•If the version of the schema on the supplier server is more recent than the version stored on the consumer, the supplier server replicates its schema to the consumer before proceeding with the data replication.

•If the version of the schema on the supplier server is older than the version stored on the consumer, the server may return many errors during replication because the schema on the consumer cannot support the new data.

A consumer might contain replicated data from two suppliers, each with different schema. Whichever supplier was updated last wins, and its schema is propagated to the consumer.

WARNING!

Never update the schema on a consumer server, because the supplier server is unable to resolve onflicts that occur, and replication fails. Schema should be maintained on a supplier server in a replicated topology.

If the standard 99user.ldif file is used for custom schema, these changes are replicated to all consumers. If there are custom schema files, ensure that these files are copied to all servers after making changes on the supplier. After all the files have been copied, restart the server.

See “Creating custom schema files” for more information.

The same Directory Server can hold read-write replicas for which it acts as a supplier and read-only replicas for which it acts as a consumer. Therefore, always identify the server that will function as a supplier for the schema, then set up replication agreements between this supplier

6.4 Using replication with other Directory Server features

91

Contents

HP-UXDirectory Server Version Page Table of Contents 1 Introduction to directory services 2 Planning the directory data 3 Designing the directory schema 4 Designing the directory tree 5 Designing the directory topology 6 Designing the replication process 7 Designing synchronization 8 Designing a secure directory 9 Directory design examples 10 Support and other resources Index 1 Introduction to directory services 1.1 About directory services 1.2 Introduction to Directory Server NOTE: Directory Server runs as a daemon; the process is ns-slapd 1.2.2 Server plug-insoverview Directory Server plug-in reference 1.2.3 Overview of the basic directory tree 1.3 Directory Server data storage 1.3.1.1 Performing queries on directory entries 1.4 Directory design overview 1.4.1Design process outline 1.Chapter 2 “Planning the directory data” 2.Chapter 3 “Designing the directory schema” 3.Chapter 4 “Designing the directory tree” 4.Chapter 5 “Designing the directory topology” 1.5 Other general directory resources Page 2 Planning the directory data 2.1 Introduction to directory data 2.2 Defining directory needs 2.3Performing a site survey •Determine data ownership •Determine data access •Document the site survey 2.3.1 Identifying the applications that use the directory •Directory browser applications, such as online telephone books •Email applications, especially email servers •Directory-enabledhuman resources applications •Microsoft Active Directory 2.3.2Identifying data sources •Identify organizations that provide information •Identify the tools and processes that are information sources •Determine how centralizing each piece of data affects the management of data Table 2.3.4 Determining level of service 2.3.5 Considering a data master •Replication among Directory Servers •Synchronization between Directory Server and Active Directory •Independent client applications which access the Directory Server data 2.3.6 Determining data ownership Allow •Create roles that give groups of people read or write access privileges “Grouping directory entries” 2.3.7 Determining data access For each piece of information stored in the directory, decide the following: •Can the data be read anonymously •Can the data be read widely across the enterprise For more information about access controls, see “Designing access control” 2.4 Documenting the site survey 2.5Repeating the site survey Page 3 Designing the directory schema 3.1 Schema design process overview 3.2 Standard schema This schema entry states the object identifier, or OID, for the class ), the name of the object class 3.2.2 Standard attributes cn: Babs Jensen In the schema, each attribute definition contains the following information: •A unique name •An object identifier (OID) for the attribute 3.2.3 Standard object classes Directory Server Schema Reference Object class definitions contain the following information: •An object identifier (OID) that names the object •A set of mandatory attributes 3.3 Mapping the data to the default schema 3.4 Customizing the schema 3.4.1 When to extend the schema 3.4.2 Getting and assigning object identifiers 3.4.3Naming attributes and object classes 3.4.4 Strategies for defining new object classes For example, suppose an administrator wants to create the attributes , and One object class , is created and allows and 3.4.5 Strategies for defining new attributes Directory Server Schema Guide dateOfBirth 3.4.6 Deleting schema elements 3.4.7 Creating custom schema files 3.4.8.1 Naming schema files 3.4.8.2Using 'user defined' as the origin 3.4.8.3Defining attributes before object classes 3.4.8.4Defining schema in a single file 3.5 Maintaining consistent schema 3.5.1 Schema checking For example, if an entry is defined to use the object class, then the common name ) and surname 3.5.2 Selecting consistent data formats 3.6Other schema resources 4 Designing the directory tree 4.1 Introduction to the directory tree 4.2 Designing the directory tree 4.2.1.1 Suffix naming conventions 4.2.1.2 Naming multiple suffixes 4.2.2.1Branching the directory 4.2.2.2 Identifying branch points Figure 4-5Directory tree for example isp o=example, c=US Consider the following when choosing attributes for the branch points: •Be consistent Try to use only the traditional attributes (shown in 4.2.2.3 Replication considerations 4.2.2.4 Access control considerations 4.2.3.1Naming person entries 4.2.3.2Naming group entries 4.2.3.3 Naming organization entries 4.2.3.4Naming other kinds of entries 4.3 Grouping directory entries nsRoleDN 4.3.2Deciding between roles and groups 4.3.3 About class of service facsimileTelephoneNumber Each CoS is comprised of the several entries in the directory: •A service class attribute value stored with the entry 4.4 Virtual directory information tree views Figure 4-10Examples of a flat and an organizationally-basedDIT nsview nsviewfilter Page Figure 4-12A 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 4.4.2Advantages of using virtual DIT views The deployment decisions become easier with virtual DIT views because: Virtual DIT view hierarchies can be created as a kind of 4.4.3Example of virtual DIT views A subtree search based at would return all entries below which match the filters , or 4.4.4 Views and other directory features 4.4.5 Effects of virtual views on performance 4.4.6 Compatibility with existing applications 4.5Directory tree design examples 4.6 Other directory tree resources Page 5 Designing the directory topology 5.1 Topology overview 5.2 Distributing the directory data 5.2.1 About using multiple databases 5.2.2 About suffixes 5.3 About knowledge references 5.3.1.1 The structure of an LDAP referral 5.3.1.2 About default referrals 5.3.1.3 Smart referrals Page 5.3.1.4 Tips for designing smart referrals 5.3.2 Using chaining Database links provide the following features: •Invisible access to remote data •Dynamic management •Access control 5.3.3.1 Usage differences 5.3.3.2 Evaluating access controls Figure 5-12Sending a client request to a server using chaining In the illustration above, the following steps are performed: 3.Server B sends an acceptance response to Server A Figure 5-13Authenticating a client and retrieving data using different servers In this illustration, the following steps are performed: 5.4Using indexes to improve database performance •International index •Browsing index or virtual list view (VLV) index 5.4.2Evaluating the costs of indexing •Indexes increase the time it takes to modify entries •Index files use disk space •Index files use memory •Index files take time to create Page 6 Designing the replication process 6.1 Introduction to replication 6.1.1.1 Unit of replication 6.1.1.2 Read-writeand read-onlyreplicas 6.1.1.3 Suppliers and consumers 6.1.1.4 Replication and changelogs 6.1.1.5 Replication agreement 6.2Common replication scenarios •“Single-masterreplication” •“Multi-masterreplication” •“Cascading replication” •“Mixed environments” 6.2.1Single-masterreplication Figure 6-1 Single-masterreplication 6.2.2 Multi-masterreplication Page Figure 6-4 Multi-masterreplication configuration B (four suppliers) 6.2.3 Cascading replication Page 6.2.4 Mixed environments 6.3 Defining a replication strategy See “Using replication for local availability” for more information See “Using replication for load balancing” for more information 6.3.1 Conducting a replication survey •The number and size of the entries stored in the directory service 6.3.2 Replicated selected attributes with fractional replication Fractional replication is particularly useful in the following situations: 6.3.3 Replication resource requirements 6.3.4Managing disk space required for multi-masterreplication cn=replica suffixDN nsDS5ReplicaTombstonePurgeInterval 6.3.5 Replication across a wide-areanetwork •Use a T-1or faster Internet connection for the network When creating agreements for replication over a 6.3.6Using replication for high availability 6.3.7 Using replication for local availability Use replication for local availability for the following reasons: •To keep a local master copy of the data •To mitigate unreliable or intermittently available network connections 6.3.8Using replication for load balancing 6.3.8.1 Example of network load balancing 6.3.8.2Example of load balancing for improved performance 6.3.8.3Example replication strategy for a small site 6.3.8.4Example replication strategy for a large site 6.4 Using replication with other Directory Server features Figure 6-10Replicating chained databases 6.4.4 Schema replication WARNING See “Creating custom schema files” for more information 6.4.5 Replication and synchronization 7 Designing synchronization 7.1 Windows synchronization overview 7.2 Planning windows synchronization •The number and size of the entries stored in the directory 7.2.2 Managing disk space for the changelog cn=changelog5 The other two attributes are under the synchronization agreement entry in sync_agreement 7.2.3 Defining the connection type 7.2.5 Determining the subtree to synchronize 7.2.6 Interaction with a replicated environment Figure 7-1 Multi-masterDirectory Server — Windows domain synchronization 7.2.7 Identifying the directory data to synchronize •Contact information for trading partners, clients, and customers •User’s software preferences or software configuration information •Group information and group membership 7.3Schema elements sycnhronized between Active Directory and Directory Server ntDomainUser samAccountName User entries only “User schema that are the same in Directory Server and Windows servers” “User schema mapped between Directory Server and Active Directory” 7.3.2.1 Values for cn attributes 7.3.2.2 Password policies 7.3.2.3 Values for street and streetAddress 7.3.2.4Contraints on the initials attribute 7.3.4 Group schema differences between Directory Server and Active Directory 8 Designing a secure directory 8.1 About security threats 8.2 Analyzing security needs 8.3Overview of security methods 8.4 Selecting appropriate authentication methods command 8.4.2 Simple password 1.The user enters a unique identifier, such as a user ID (for example, fchen) 8.4.3 Certificate-basedauthentication For more information about certificates and SSL, see the Administrator's Guide 8.4.4 Simple password over SSL/TLS 8.4.5 Simple authentication and security layer 8.4.6 Proxy authentication 8.5 Preventing authentication by account deactivation 8.6 Designing a password policy nsslapd-pwpolicy-local ns-newpwpolicy.pl To determine whether the off Page Page 8.6.2.1 Password change after reset 8.6.2.2User-definedpasswords 8.6.2.3Password expiration 8.6.2.4Expiration warning 8.6.2.5Grace login limit 8.6.2.6Password syntax checking 8.6.2.7Password length 8.6.2.8Password minimum age 8.6.2.9Password history 8.6.2.10 Password storage schemes 8.7 Designing access control 8.7.1.1 Targets 8.7.1.2 Permissions 8.7.1.3 Bind rules 8.7.2.1 The precedence rule 8.7.2.2 Allowing or denying access 8.7.2.3 When to deny access 8.7.2.4Where to place access control rules 8.7.2.5 Using filtered access control rules Create an attribute on every user's directory entry called publishHomeContactInfo 8.7.3 Viewing ACIs: Get effective rights ldapsearch title salary homePostalAddress 8.7.4 Using ACIs: Some hints and tricks •Minimize the number of ACIs in the directory 8.8Database encryption 8.9 Securing server to server connections 8.10 Other security resources 9 Directory design examples 9.1 Design example: A local enterprise 9.1.3 Local enterprise directory tree design 9.1.4.1 Database topology 9.1.5.1 Supplier architecture 9.1.5.2 Supplier consumer architecture Figure 9-5Supplier and consumer architecture for Example Corp 9.1.6 Local enterprise security design •They create an ACI that allows employees to modify their own entries manager department This ACI denies anonymous write access to password information 9.2 Design example: A multinational enterprise and its extranet 9.2.1 Multinational enterprise data design 9.2.2Multinational enterprise schema design exampleSupplier examplePartner exampleSupplierID Page 9.2.4.1 Database topology 9.2.4.2 Server topology Page 9.2.5.1 Supplier architecture Page 9.2.6 Multinational enterprise security design Page 10 Support and other resources 10.1 Contacting HP 10.2 Related information •HP-UXDirectory Server administration server guide •HP-UXDirectory Server configuration, command, and file reference 10.2.2 HP-UXdocumentation set •HP-UX11i v3 Operating Environments: http://docs.hp.com/en/oshpux11iv3.html •HP-UX11i v2 Operating Environments: http://docs.hp.com/en/oshpux11iv2.html 10.3 Typographic conventions Page Glossary bind See bind DN bind DN bind rule branch entry CoS definition entry affects CoS template Contains a list of the shared attribute values file type extension (for example, .GIF or .HTML) filter filtered role role LDAP and across multiple platforms LDAP client Software used to request and view LDAP entries from an LDAP Directory Server See also browser determine which server holds the most recent version multiplexor n+1 directory problem resulting in increased hardware and personnel costs 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 SASL Simple Authentication and Security Layer schema access the directory may be unable to display the proper results superuser privileges to all files on the machine. Also called root supplier servers supplier server Page Index