Red Hat Directory Server 8.
Red Hat Directory Server 8.
Red Hat Directory Server 8.0: Administrator's Guide Copyright © 2008 Red Hat, Inc. Copyright © 2008 Red Hat. This material may only be distributed subject to the terms and conditions set forth in the Open Publication License, V1.0 or later with the restrictions noted below (the latest version of the OPL is presently available at http://www.opencontent.org/openpub/). Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder.
Red Hat Directory Server 8.
Preface .................................................................................................................. xvii 1. Directory Server Overview ........................................................................... xvii 2. Example and Default References .................................................................xviii 3. Document Conventions ...............................................................................xviii 4. Related Information .....................................
Red Hat Directory Server 8.0 1. Creating and Maintaining Suffixes ..................................................................47 1.1. Creating Suffixes ................................................................................48 1.2. Maintaining Suffixes ...........................................................................54 2. Creating and Maintaining Databases ..............................................................56 2.1. Creating Databases .......................................
2.5. Access Control and CoS ...................................................................162 3. Using Views ................................................................................................162 3.1. Creating Views in the Console ..........................................................163 3.2. Deleting Views from the Directory Server Console ..............................164 3.3. Creating Views from the Command Line ............................................164 3.4.
Red Hat Directory Server 8.0 9.5. Granting Rights to Add and Delete Group Entries ...............................225 9.6. Granting Conditional Access to a Group or Role .................................227 9.7. Denying Access ...............................................................................229 9.8. Setting a Target Using Filtering .........................................................232 9.9. Allowing Users to Add or Remove Themselves from a Group ..............232 9.10.
5.1. Configuring the Read-Write Replicas on the Supplier Servers .............286 5.2. Configuring the Read-Only Replicas on the Consumer Servers ...........289 5.3. Setting up the Replication Agreements ..............................................291 5.4. Preventing Monopolization of the Consumer in Multi-Master Replication 297 6. Configuring Cascading Replication ...............................................................298 6.1. Configuring the Read-Write Replica on the Supplier Server ............
Red Hat Directory Server 8.0 2. Managing Attributes ....................................................................................353 2.1. Viewing Attributes ............................................................................353 2.2. Creating Attributes ...........................................................................355 2.3. Editing Attributes ..............................................................................356 2.4. Deleting Attributes ................................
4.1. Enabling TLS/SSL Only in the Directory Server ..................................406 4.2. Enabling TLS/SSL in the Directory Server, Administration Server, and Console .................................................................................................408 4.3. Creating a Password File for the Directory Server ..............................410 4.4. Creating a Password File for the Administration Server .......................411 5. Setting Security Preferences ................................
Red Hat Directory Server 8.0 6.1. Operations Table ..............................................................................458 6.2. Entries Table ...................................................................................460 6.3. Entity Table .....................................................................................460 6.4. Interaction Table ..............................................................................461 15. Tuning Directory Server Performance ....................
1.31. Telephone Syntax Plug-in ...............................................................488 1.32. UID Uniqueness Plug-in ..................................................................488 1.33. URI Plug-in ....................................................................................489 2. Enabling and Disabling Plug-ins ...................................................................490 17. Using the Pass-through Authentication Plug-in ....................................................
Red Hat Directory Server 8.0 3.2. Synchronizing Groups ......................................................................530 3.3. Deleting Entries ................................................................................531 3.4. Resurrecting Entries .........................................................................532 3.5. Manually Updating and Resynchronizing Entries ................................532 3.6. Checking Synchronization Status .................................................
1. About Locales .............................................................................................577 2. Identifying Supported Locales ......................................................................578 3. Supported Language Subtypes ....................................................................580 4. Troubleshooting Matching Rules ..................................................................581 Glossary ...........................................................................
xvi
Preface Red Hat Directory Server (Directory Server) is a powerful and scalable distributed directory server based on the industry-standard Lightweight Directory Access Protocol (LDAP). Directory Server is the cornerstone for building a centralized and distributed data repository that can be used in your intranet, over your extranet with your trading partners, or over the public Internet to reach your customers.
Preface • SNMP agent — Can monitor the Directory Server using the Simple Network Management Protocol (SNMP). 2. Example and Default References There are differences between the command, directory, and file locations in Red Hat Enterprise Linux, Sun Solaris, and HP-UX Directory Server installations. Locations for other platforms are listed in Section 1, “Directory Server File Locations”.
Document Conventions # gconftool-2 italic Courier font Italic Courier font represents a variable, such as an installation directory: install_dir/bin/ bold font Bold font represents application programs and text found on a graphical interface. When shown like this: OK , it indicates a button on a graphical application interface. Additionally, the manual uses different strategies to draw your attention to pieces of information.
Preface Warning A warning indicates potential data loss, as may happen when tuning hardware for maximum performance. 4. Related Information This manual describes how to administer the Directory Server and its contents. The instructions for installing the various Directory Server components are contained in the Red Hat Directory Server Installation Guide.
Chapter 1. General Red Hat Directory Server Usage Red Hat Directory Server product includes a directory service, an administration server to manage multiple server instances, and a Java-based console to manage server instances through a graphical interface. This chapter provides an overview of the basic tasks for administering a directory service. The Directory Server is a robust, scalable server designed to manage an enterprise-wide directory of users and resources.
Chapter 1. General Red Hat Directory Server Usage only instead of the instance as a directory name, the Administration Server directories are named admin-serv. For any directory or folder named slapd-instance, substitute admin-serv, such as /etc/dirsrv/slapd-example and /etc/dirsrv/admin-serv.
LDAP Tool Locations File or Directory Location Table 1.2. Red Hat Enterprise Linux 4 and 5 (x86_64) File or Directory Location Log files /var/log/dirsrv/slapd-instance Configuration files /etc/dirsrv/slapd-instance Instance directory /usr/lib/sparc9/dirsrv/slapd-instance Database files /var/lib/dirsrv/slapd-instance Runtime files /var/lock/dirsrv/slapd-instance /var/run/dirsrv/slapd-instance Initscripts /etc/rc.d/init.d/dirsrv and /etc/default/dirsrv /etc/rc.d/init.
Chapter 1. General Red Hat Directory Server Usage 2. LDAP Tool Locations Red Hat Directory Server uses Mozilla LDAP tools — such as ldapsearch, ldapmodify, and ldapdelete — for command-line operations. The MozLDAP tools are installed with Directory Server.
Starting and Stopping Directory Server from provides startup or run command (rc) scripts. On Red Hat Enterprise Linux, use the chkconfig command to enable the Directory Server and Administration Server to start on boot. On Solaris, the commands are already set up in the /etc/rc.d directories to start up the servers at boot time. For HP-UX, check the operating system documentation for details on adding these scripts. 3.1. Starting and Stopping Directory Server from the Console 1.
Chapter 1. General Red Hat Directory Server Usage There are two ways to start, stop, or restart the Directory Server: • There are scripts in the instance directories. For example: /usr/lib/dirsrv/slapd-instance/start-slapd /usr/lib/dirsrv/slapd-instance/restart-slapd /usr/lib/dirsrv/slapd-instance/stop-slapd • The Directory Server service can also be stopped and started using system tools on Red Hat Enterprise Linux and Solaris.
the Console NOTE The service name for the Administration Server process on Red Hat Enterprise Linux is dirsrv-admin. On Solaris, the service is init.d: /etc/init.d/dirsrv-admin {start|stop|restart} 4. Starting the Directory Server Console There is a simple script to launch the Directory Server Console.
Chapter 1. General Red Hat Directory Server Usage login screen. 4.1. Logging into Directory Server After starting the Directory Server Console, a login screen opens, requiring the username and password for the user logging in and the URL for the Administration Server instance being access. The user logged in at the Console is the user who is binding to Directory Server. This determines the access permissions granted and allowed operations while access the directory tree.
Viewing the Current Console Bind DN 3. A login dialog box appears. Enter the full distinguished name of the entry with which to bind to the server. For example, to bind as user Barbara Jensen, enter her full DN in the login box: cn=Barbara Jensen, ou=People,dc=example,dc=com 4.3. Viewing the Current Console Bind DN To see the bind DN that is currently logged into the Directory Server Console, click the login icon in the lower-left corner of the window. The current bind DN appears next to the login icon.
Chapter 1. General Red Hat Directory Server Usage Server, which maintains the o=NetscapeRoot subtree should be done through the Directory Server Console. Changing the configuration directory or user directory port or secure port numbers has the following repercussions: • The Directory Server port number must also be updated in the Administration Server configuration.
Creating a New Directory Server Instance 8. Open the Administration Server Console. 9. In the Configuration tab, select the Configuration DS tab. 10.In the LDAP Port field, type in the new LDAP port number for your Directory Server instance. 11.Check the Secure Connection box if this is a secure port. NOTE If you try to save these changes at this step, you will get a warning box that reads, Invalid LDAP Host/LDAP Port, can not connect. Click OK, and ignore this warning. 12.
Chapter 1. General Red Hat Directory Server Usage The Create New Instance dialog box is displayed. 3. Enter a unique identifier for the server in the Server Identifier field. NOTE This name must only have alphanumeric characters, a dash (-), or an underscore (_). 4. Enter the a port number for LDAP communications in the Network port field. 5. Enter the suffix managed by this new instance of the directory in the Base Suffix field. 6. Enter a DN for the Directory Manager in the Root DN field.
Configuring the Directory Manager 4. Enter the new distinguished name for the Directory Manager in the Root DN field. The default value is cn=Directory Manager. 5. From the Manager Password Encryption pull-down menu, select the storage scheme you want the server to use to store the password for Directory Manager. 6. Enter the new password, and confirm it. 7. Click Save.
14
Chapter 2. Creating Directory Entries This chapter discusses how to use the Directory Server Console and the ldapmodify and ldapdelete command-line utilities to modify the contents of your directory. Entries stored in Active Directory can be added to the Directory Server through Windows Sync; see Chapter 19, Synchronizing Red Hat Directory Server with Microsoft Active Directory for more information on adding or modifying synchronized entries through Windows User Sync. 1.
Chapter 2. Creating Directory Entries 1. In the Directory Server Console, select the Configuration tab. 2. Create a new database, as explained in Section 2, “Creating and Maintaining Databases”. 3. In the Directory tab, right-click the top object representing the Directory Server, and choose New Root Object. The secondary menu under New Root Object displays a list of suffixes that do not have a corresponding entry. 4. Choose the suffix corresponding to the entry to create. The New Object window opens. 5.
Creating Directory Entries Template Object Class Role nsRoleDefinition Class of Service cosSuperDefinition Table 2.1. Entry Templates and Corresponding Object Classes These templates contain fields representing all the mandatory attributes and some of the commonly used optional attributes. To create an entry using one of these templates, refer to Section 1.2.1, “Creating an Entry Using a Predefined Template”. To create any other type of entry, refer to Section 1.2.
Chapter 2. Creating Directory Entries 3. In the object class list, select an object class to define the new entry. 4. Click OK. If you selected an object class related to a type of entry for which a predefined template is available, the corresponding Create window opens, as described in Section 1.2.1, “Creating an Entry Using a Predefined Template”. In all other cases, the Property Editor opens. It contains a list of mandatory attributes for the selected object class. 5.
Modifying Directory Entries • From the Directory tab, by double-clicking an entry • From the Create... entry templates, by clicking the Advanced button (as in Section 1.2.1, “Creating an Entry Using a Predefined Template”) • From the New Object window, by clicking OK (as in Section 1.2.2, “Creating Other Types of Entries”) 1.3.2. Adding an Object Class to an Entry To add an object class to an entry, do the following: 1.
Chapter 2. Creating Directory Entries Before you can add an attribute to an entry, the entry must contain an object class that either requires or allows the attribute. refer to Section 1.3.2, “Adding an Object Class to an Entry” and Chapter 9, Extending the Directory Schema for more information. Add an attribute to an entry as follows: 1. In the Directory tab of the Directory Server Console, right-click the entry to modify, and select Advanced from the pop-up menu.
Modifying Directory Entries • The size of each attribute name in the request • The size of the values of each of the attributes in the request • The size of the DN in the request • Some overhead; usually 10 kilobytes is sufficient One common issue that requires increasing the nsslapd-maxbersize setting is using attributes which hold CRL values, such as certificateRevocationList, authorityRevocationList, and deltaRevocationList.
Chapter 2. Creating Directory Entries To remove the entire attribute and all its values from the entry, select Delete Attribute from the Edit menu. 3. Click OK to close the Advanced Property Editor, then click OK to close the Property Editor. 1.3.8. Adding an Attribute Subtype There are three different kinds of subtypes to attributes which can be added to an entry: language, binary, and pronunciation. 1.3.8.1.
Deleting Directory Entries Although you can store binary data within an attribute that does not contain the binary subtype (for example, jpegphoto), the binary subtype indicates to clients that multiple variants of the attribute type may exist. 1.3.8.3. Pronunciation Subtype Assigning the pronunciation subtype to an attribute indicates that the attribute value is a phonetic representation. The subtype is added to the attribute name as attribute;phonetic.
Chapter 2. Creating Directory Entries entries, use Ctrl or Shift. 3. Select Delete from the Edit menu. WARNING The server deletes the entry or entries immediately. There is no way to undo the delete operation. 2. Managing Entries from the Command-Line The command-line utilities allow you to manipulate the contents of your directory. They can be useful to write scripts to perform bulk management of the directory or to test the Directory Server.
Creating a Root Entry from the see Section 4, “LDIF Update Statements”. The ldapmodify and ldapdelete utilities read the statements that you enter in exactly the same way as if they were read from a file. When all of the input has been entered, enter the character that the shell recognizes as the end of file (EOF) escape sequence. The utility then begins operations based on the supplied inputs.
Chapter 2. Creating Directory Entries objectclass: newobjectclass The DN corresponds to the DN of the root or sub-suffix contained by the database. The newobjectclass value depends upon the type of object class you are adding to the database. You may need to specify additional required attributes depending on the type of root object being added. NOTE You can use ldapmodify to add root objects only if you have one database per suffix.
Command-Line then the modify operation will fail when it reaches the erroneous entry. All entries that were processed before the error was encountered will be successfully added or modified. If you run ldapmodify with the -c option (do not stop on errors), all correct entries processed after the erroneous entry will be successfully added or modified. • If a required attribute is not present, the modify operation fails. This happens even if the offending object class or attribute is not being modified.
Chapter 2. Creating Directory Entries Parameter Name Description to authenticate to the server. The value must be a DN recognized by the Directory Server, and it must also have the authority to modify the entries. -w Specifies the password associated with the distinguished name specified in the -D parameter. -h Specifies the name of the host on which the server is running. -p Specifies the port number that the server uses.
Deleting Entries Using ldapdelete • The hostname is cyclops. • The server uses port number 845. Table 2.3, “ldapmodify Parameters Used for Modifying Entries” describes the ldapmodify parameters used in the example. Parameter Name Description -D Specifies the distinguished name with which to authenticate to the server. The value must be a DN recognized by the Directory Server, and it must also have the authority to modify the entries.
Chapter 2. Creating Directory Entries are branch points in the directory tree. For example, of the following three entries, only the last two entries can be deleted. ou=People,dc=example,dc=com cn=Paula Simon,ou=People,dc=example,dc=com cn=Jerry O'Connor,ou=People,dc=example,dc=com The entry that identifies the People subtree can be deleted only if there are not any entries below it.
Using Special Characters Parameter Name Description distinguished name specified in the -D parameter. -h Specifies the name of the host on which the server is running. -p Specifies the port number that the server uses. Table 2.4. ldapdelete Parameters Used for Deleting Entries For full information on ldapdelete parameters, see the Directory Server Configuration, Command, and File Reference. 2.6.
Chapter 2. Creating Directory Entries • createTimestamp. The timestamp for when the entry was created in GMT (Greenwich Mean Time) format. • modifiersName. The distinguished name of the person who last modified the entry. • modifyTimestamp. The timestamp for when the entry was last modified in GMT format. NOTE When a database link is used by a client application to create or modify entries, the creatorsName and modifiersName attributes do not reflect the real creator or modifier of the entries.
LDIF Update Statements • A changetype that defines how a specific entry is to be modified (add, delete, modify, modrdn). • A series of attributes and their changed values. A change type is required unless ldapmodify is run with the -a parameter. If you specify the -a parameter, then an add operation (changetype: add) is assumed. However, any other change type overrides the -a parameter.
Chapter 2. Creating Directory Entries The following sections describe the change types in detail. 4.1. Adding an Entry Using LDIF changetype: add adds an entry to the directory. When you add an entry, make sure to create an entry representing a branch point before you try to create new entries under that branch. That is, to place an entry in a People and a Groups subtree, then create the branch point for those subtrees before creating entries within the subtrees.
Renaming an Entry Using LDIF changetype: add objectclass: top objectclass: groupOfNames member: cn=Sue Jacobs,ou=People,dc=example,dc=com member: cn=Pete Minsky,ou=People,dc=example,dc=com cn: Administrators dn: ou=example.com Bolivia\, S.A.,dc=example,dc=com changetype: add objectclass: top objectclass: organizationalUnit ou: example.com Bolivia\, S.A. dn: cn=Carla Flores,ou=example.com Bolivia\,S.A.
Chapter 2. Creating Directory Entries dn: cn=Sue Jacobs,ou=Marketing,dc=example,dc=com changetype: modrdn newrdn: cn=Susan Jacobs deleteoldrdn: 1 4.2.1. A Note on Renaming Entries The modrdn change type cannot move an entry to a completely different subtree. To move an entry to a completely different branch, you must create a new entry in the alternative subtree using the old entry's attributes, and then delete the old entry.
Modifying an Entry Using LDIF The specified attribute is deleted. If more than one value of an attribute exists for the entry, then all values of the attribute are deleted in the entry. To delete just one of many attribute values, specify the attribute and associated value on the line following the delete change operation. This section contains the following topics: • Section 4.3.1, “Adding Attributes to Existing Entries Using LDIF” • Section 4.3.2, “Changing an Attribute Value Using LDIF” • Section 4.3.
Chapter 2. Creating Directory Entries The following example adds a jpeg photograph to the directory.
Modifying an Entry Using LDIF cn=Barney Fife,ou=People,dc=example,dc=com objectClass: inetOrgPerson cn: Barney Fife sn: Fife telephonenumber: 555-1212 telephonenumber: 555-6789 To change the telephone number 555-1212 to 555-4321, use the following LDIF update statement: dn: cn=Barney Fife,ou=People,dc=example,dc=com changetype: modify delete: telephonenumber telephonenumber: 555-1212 add: telephonenumber telephonenumber: 555-4321 The entry is now as follows: cn=Barney Fife,ou=People,dc=example,dc=com obj
Chapter 2.
Modifying an Entry in an Internationalized changetype: delete dn: cn=Sue Jacobs,ou=People,dc=example,dc=com changetype: delete CAUTION Do not delete the suffix o=NetscapeRoot. The Administration Server uses this suffix to store information about installed Directory Servers. Deleting this suffix could force you to reinstall the Directory Server. 4.5.
Chapter 2. Creating Directory Entries NOTE The Referential Integrity Plug-in should only be enabled on one supplier replica in a multi-master replication environment to avoid conflict resolution loops. When enabling the plug-in on servers issuing chaining requests, be sure to analyze performance resource and time needs, as well as your integrity needs. Integrity checks can be time-consuming and draining on memory and CPU.
Directory • With multi-master replication, enable the plug-in on just one supplier. If the replication environment satisfies the all of those condition, you can enable the Referential Integrity Plug-in. 1. Enable the Referential Integrity Plug-in as described in Section 5.3, “Enabling/Disabling Referential Integrity”. 2. Configure the plug-in to record any integrity updates in the changelog. 3. Ensure that the Referential Integrity Plug-in is disabled on all consumer servers.
Chapter 2. Creating Directory Entries • Update immediately • 90 seconds • 3600 seconds (updates occur every hour) • 10,800 seconds (updates occur every 3 hours) • 28,800 seconds (updates occur every 8 hours) • 86,400 seconds (updates occur once a day) • 604,800 seconds (updates occur once a week) To modify the update interval, do the following: 1. Start the Directory Server Console. See Section 4, “Starting the Directory Server Console”. 2. Select the Configuration tab. 3.
Modifying the Attribute List TIP Improve the performance by removing any unused attributes from the list. 1. Start the Directory Server Console. See Section 4, “Starting the Directory Server Console”. 2. Select the Configuration tab. 3. Expand the Plugins folder in the navigation tree, and select the Referential Integrity Postoperation Plug-in. The settings for the plug-in are displayed in the right pane. 4. In the Arguments section, use the Add and Delete buttons to modify the attributes in the list. 5.
46
Chapter 3. Configuring Directory Databases The directory is made up of databases, and the directory tree is distributed across the databases. This chapter describes how to create suffixes, the branch points for the directory tree, and how to create the databases associated with each suffix. This chapter also describes how to create database links to reference databases on remote servers and how to use referrals to point clients to external sources of directory data. 1.
Chapter 3. Configuring Directory Databases • Section 1.1, “Creating Suffixes” • Section 1.2.1, “Using Referrals in a Suffix” 1.1. Creating Suffixes Both root and sub suffixes can be created to organize the contents of the directory tree. A root suffix is the parent of a sub suffix. It can be part of a larger tree designed for the Directory Server. A sub suffix is a branch underneath a root suffix. The data for root and sub suffixes are contained by databases.
Creating Suffixes Figure 3.3. A Sample Directory Tree with a Root Suffix Off Limits to Search Operations Searches performed by client applications on the dc=example,dc=com branch of Example Corporation's directory will not return entries from the l=europe,dc=example,dc=com branch of the directory, as it is a separate root suffix.
Chapter 3. Configuring Directory Databases This section describes creating root and sub suffixes for the directory using either the Directory Server Console or the command-line. • Section 1.1.1, “Creating a New Root Suffix Using the Console” • Section 1.1.2, “Creating a New Sub Suffix Using the Console” • Section 1.1.3, “Creating Root and Sub Suffixes from the Command-Line” 1.1.1. Creating a New Root Suffix Using the Console 1. In the Directory Server Console, select the Configuration tab. 2.
Creating Suffixes The root suffix is automatically added to the name. For example, it the sub suffix ou=groups is created under the dc=example,dc=com suffix, the Console automatically names it ou=groups,dc=example,dc=com. 4. Select the Create associated database automatically checkbox to create a database at the same time as the new sub suffix, and enter a unique name for the new database in the Database name field, such as example2.
Chapter 3. Configuring Directory Databases 3.
Creating Suffixes Attribute Name Value • disabled: The database is not available for processing operations. The server returns a No such search object error in response to requests made by client applications. • referral: A referral is returned for requests made to this suffix. • referral on update: The database is used for all operations except update requests, which receive a referral. The default value is disabled. nsslapd-referral Defines the LDAP URL of the referral to be returned by the suffix.
Chapter 3. Configuring Directory Databases Attribute Name Value suffix. By default, this attribute is not present, which means that the suffix is regarded as a root suffix. For example, to create a sub suffix names o=sales,dc=example,dc=com under the root suffix dc=example,dc=com, add nsslapd-parent-suffix: "dc=example,dc=com" to the sub suffix. Table 3.1. Suffix Attributes 1.2. Maintaining Suffixes This section describes the following procedures: • Section 1.2.
Maintaining Suffixes to requests from client applications. 6. Click Save. 1.2.2. Enabling Referrals Only During Update Operations It is possible to configure the directory to redirect update and write requests made by client applications to a read-only database. For example, there may be a local copy of directory data, and that data should be available company-wide for searches but not for updates.
Chapter 3. Configuring Directory Databases 2. Under Data in the left navigation pane, click the suffix to disable. 3. Click the Suffix Setting tab, and deselect the Enable this suffix checkbox. 4. Click Save. The suffix is no longer enabled. 1.2.4. Deleting a Suffix CAUTION Deleting a suffix also deletes all database entries and replication information associated with that suffix. 1. In the Directory Server Console, select the Configuration tab. 2.
Creating Databases Three databases are added to store the data contained in separate suffixes. This division of the tree corresponds to three databases.
Chapter 3. Configuring Directory Databases clients can conduct searches based at dc=example,dc=com. Database two contains the data for ou=groups, and database three contains the data for ou=contractors. • Multiple databases for one suffix. Suppose the number of entries in the ou=people branch of the directory tree is so large that two databases are needed to store them. In this case, the data contained by ou=people could be distributed across two databases.
Creating Databases 5. In the Create database in field, enter the path to the directory to store the new database. Alternatively, click Browse to locate a directory on the local machine. By default, the directory stores the new database in the /var/lib/dirsrv/slapd-instance_name/db directory. 6. Click OK. Click Yes in the confirmation dialog to create the new database. 2.1.2.
Chapter 3. Configuring Directory Databases NOTE Once entries have been distributed, they cannot be redistributed. The following restrictions apply: • The distribution function cannot be changed once entry distribution has been deployed. • The LDAP modrdn operation cannot be used to rename entries if that would cause them to be distributed into a different database. • Distributed local databases cannot be replicated.
Maintaining Directory Databases 2.1.3.2. Adding the Custom Distribution Function to a Suffix Using the Command-Line 1. Run ldapmodify.1 ldapmodify -p 389 -D "cn=directory manager" -w secret -h us.example.com 2.
Chapter 3. Configuring Directory Databases directory unavailable for updates. However, with multi-master replication, this might not be a problem. • Section 2.2.1.1, “Making a Database Read-Only Using the Console” • Section 2.2.1.2, “Making a Database Read-Only from the Command Line” • Section 2.2.1.3, “Placing the Entire Directory Server in Read-Only Mode” 2.2.1.1. Making a Database Read-Only Using the Console To place a database in read-only mode from the Directory Server Console, do the following: 1.
Maintaining Directory Databases nsslapd-readonly: on NOTE By default, the name of the database created at installation time is userRoot. 2.2.1.3. Placing the Entire Directory Server in Read-Only Mode If the Directory Server maintains more than one database and all databases need to be placed in read-only mode, this can be done in a single operation.
Chapter 3. Configuring Directory Databases the physical database itself. 1. In the Directory Server Console, select the Configuration tab. 2. In the left navigation pane, locate the database to delete, and select it. 3. From the Object menu, select Delete. Alternatively, right-click the database and select Delete from the pop-up menu. The Deleting Database confirmation dialog box is displayed. 4. Click Yes to confirm the deletion. Once deleted, the database no longer appears in the right pane. 2.2.3.
Database Encryption For highly sensitive information, this potential for information loss could present a significant security risk. In order to remove that security risk, Directory Server allows portions of its database to be encrypted. Once encrypted, the data are safe even in the event that an attacker has a copy of the server's database files. Database encryption allows attributes to be encrypted in the database. Both encryption and the encryption cipher are configurable per attribute per backend.
Chapter 3. Configuring Directory Databases There is no mechanism for recovering a lost key. Therefore, it is especially important to back up the server's certificate database safely. If the server's certificate were lost, it would not be possible to decrypt any encrypted data stored in its database. CAUTION If the SSL certificate is expiring and needs to be renewed, export the encrypted backend instance before the renewal. Update the certificate, then re-import the exported LDIF file. 2.3.2.
Database Encryption NOTE For existing attribute entries to be encrypted, the information must be exported, then re-imported. See Section 2.3.5, “Exporting and Importing an Encrypted Database”. 7. Select which encryption cipher to use. 8. Repeat steps 6 and 7 for every attribute to encrypt. Then hit Save. To remove encryption from attributes, select them from the list of encrypted attributes in the Attribute Encryption table, and hit the Delete button, then hit Save to apply the changes.
Chapter 3. Configuring Directory Databases then re-encrypted when it is imported to the database. Using the -E option when running the db2ldif and ldif2db scripts will decrypt the data on export and re-encrypt it on import. 1. Export the data using the db2ldif script, as follows: db2ldif -n Database1 -E -a /path/to/output.ldif -s "dc=example,dc=com" -s "o=userRoot" See Section 2.3, “Exporting to LDIF from the Command-Line” for more information. 2. Make any configuration changes. 3.
Creating and Maintaining Database Links • The server does not attempt to protect unencrypted data stored in memory. This data may be copied into a system page file by the operating system. For this reason, ensure that any page or swap files are adequately protected. 3. Creating and Maintaining Database Links Chaining means that a server contacts other servers on behalf of a client application and then returns the combined results.
Chapter 3. Configuring Directory Databases By default, all internal operations are not chained and no components are allowed to chain, although this can be overridden. Additionally, an ACI must be created on the remote server to allow the specified plug-in to perform its operations on the remote server. The ACI must exist in the suffix assigned to the database link.
Configuring the Chaining Policy Component Name Description Permissions authentication can work with a database link. To chain this component's operations, add the chaining component attribute, nsActiveChainingComponents: cn=certificate-based authentication,cn=components,cn=config. Referential Integrity plug-in This plug-in ensures that Read, write, search, and updates made to attributes compare containing DNs are propagated to all entries that contain pointers to the attribute.
Chapter 3. Configuring Directory Databases Table 3.2. Components Allowed to Chain NOTE The following components cannot be chained: • Roles plug-in • Password policy component • Replication plug-ins • Referential Integrity plug-in When enabling the Referential Integrity plug-in on servers issuing chaining requests, be sure to analyze performance, resource, and time needs as well as integrity needs. Integrity checks can be time-consuming and draining on memory and CPU.
Configuring the Chaining Policy plug-in: aci: (targetattr "*")(target="ldap:///ou=customers,l=us,dc=example,dc=com") (version 3.0; acl "RefInt Access for chaining"; allow (read,write,search,compare) userdn = "ldap:///cn=referential integrity postoperation,cn=plugins,cn=config";) 3.1.1.2. Chaining Component Operations from the Command-Line 1.
Chapter 3. Configuring Directory Databases • Managed DSA. This controls returns smart referrals as entries, rather than following the referral, so the smart referral itself can be changed or deleted. • Loop detection. This control keeps track of the number of times the server chains with another server. When the count reaches the configured number, a loop is detected, and the client application is notified. For more information about using this control, see Section 3.7.5, “Detecting Loops”.
Creating a New Database Link The LDAP controls which can be chained and their OIDs are listed in the following table: Control Name OID Virtual list view (VLV) 2.16.840.1.113730.3.4.9 Server-side sorting 1.2.840.113556.1.4.473 Managed DSA 2.16.840.1.113730.3.4.2 Loop detection 1.3.6.1.4.1.1466.29539.12 Table 3.3. LDAP Controls and Their OIDs For more information about LDAP controls, refer to the LDAP C-SDK documentation at http://www.mozilla.org/directory. 3.2.
Chapter 3. Configuring Directory Databases The suffix must be named in line with dc naming conventions, such as dc=example,dc=com. 4. Deselect the Create associated database automatically checkbox. The checkbox must not be selected because a database link cannot be added to a suffix that is associated with a database. This suffix is used only by the database link. 5. Click OK. The suffix appears automatically under Data in the left navigation pane. 6.
Creating a New Database Link TIP The Console provides a checklist of information that needs to be present on the remote server for the database link to bind successfully. To view this checklist, click the new database link, and click the Authentication tab. The checklist appears in the Remote server checklist box. 3.2.2. Creating a Database Link from the Command-Line 1. Use the ldapmodify command-line utility to create a new database link from the command-line.
Chapter 3. Configuring Directory Databases • Section 3.2.2.4, “Providing a List of Failover Servers” • Section 3.7.6, “Summary of Cascading Chaining Configuration Attributes” • Section 3.2.2.6, “Database Link Configuration Example” 3.2.2.1. Providing Suffix Information Use the nsslapd-suffix attribute to define the suffix managed by the database link.
Creating a New Database Link database,cn=plugins,cn=config entry. CAUTION The nsMultiplexorBindDN cannot be that of the Directory Manager. Use ldapmodify to provide a user password for the database link in the nsMultiplexorCredentials attribute of the cn=database_link, cn=chaining database,cn=plugins,cn=config entry. For example, a client application sends a request to server A. Server A contains a database link that chains the request to a database on server B.
Chapter 3. Configuring Directory Databases Server B must contain a user entry corresponding to the nsMultiplexorBindDN, and set the proxy authentication rights for this user. To set the proxy authorization correctly, set the proxy ACI as any other ACI. CAUTION Carefully examine access controls when enabling chaining to avoid giving access to restricted areas of the directory.
Creating a New Database Link remote server does not specify a suffix. It takes the form ldap://hostname:port. The URL of the remote server using the nsFarmServerURL attribute is set in the cn=database_link, cn=chaining database,cn=plugins,cn=config entry of the configuration file. nsFarmServerURL: ldap://example.com:389/ Do not forget to use the trailing slash (/) at the end of the URL.
Chapter 3. Configuring Directory Databases Attributes Value nsslapd-sizelimit Default size limit for the database link, given in number of entries. The default value is 2000 entries. nsFarmServerURL Gives the LDAP URL of the remote server (or farm server) that contains the data. This attribute can contain optional servers for failover, separated by spaces. If using cascading chaining, this URL can point to another database link.
Creating a New Database Link Attributes Value nsReferralOnScopedSearch Controls whether referrals are returned by scoped searches. This attribute is for optimizing the directory because returning referrals in response to scoped searches is more efficient. Takes the values on or off. The default value is off. nsHopLimit Maximum number of times a request can be forwarded from one database link to another. The default value is 10. † Can be both a global and instance attribute.
Chapter 3. Configuring Directory Databases 1. Run ldapmodify1 to add a database link to server A: ldapmodify -a -p 389 -D "cn=directory manager" -w secret -h us.example.com 2. Specify the configuration information for the database link: dn: cn=DBLink1,cn=chaining database,cn=plugins,cn=config objectclass: top objectclass: extensibleObject objectclass: nsBackendInstance nsslapd-suffix: l=Zanzibar,ou=people,dc=example,dc=com nsfarmserverurl: ldap://africa.example.
Creating a New Database Link nsslapd-backend: DBLink1 nsslapd-parent-suffix: ou=people,dc=example,dc=com cn: l=Zanzibar,ou=people,dc=example,dc=com In the first entry, the nsslapd-suffix attribute contains the suffix on server B to which to chain from server A. The nsFarmServerURL attribute contains the LDAP URL of server B. The second entry creates a new suffix, allowing the server to route requests made to the new database link.
Chapter 3. Configuring Directory Databases server. Access controls are always evaluated on the remote server. For the user to modify or write data successfully to the remote server, set up the correct access controls on the remote server. For more information about how access controls are evaluated in the context of chained operations, see Section 3.5, “Database Links and Access Control Evaluation”. 3.3. Chaining Using SSL Database links can be configured to communicate with the remote server using SSL.
Database Links and Access Control 1. In the Directory Server Console, select the Configuration tab. 2. In the left pane, expand the Data folder, and locate the database link to update under one of the suffixes. Select the database link. 3. In the right navigation pane, click the Authentication tab. 4. To update the remote server information, enter a new LDAP URL in the Remote Server URL field. Unlike the standard LDAP URL format, the URL of the remote server does not specify a suffix.
Chapter 3. Configuring Directory Databases server only if the user has the correct access controls on the subtree contained on the remote server. This requires adding the usual access controls to the remote server with a few restrictions: • Not all types of access control can be used. For example, role-based or filter-based ACIs need access to the user entry. Because the data are accessed through database links, only the data in the proxy control can be verified.
Evaluation NOTE By default, access controls set on the server containing the database link are not evaluated. To override this default, use the nsCheckLocalACI attribute in the cn=database_link, cn=chaining database,cn=plugins,cn=config entry. However, evaluating access controls on the server containing the database link is not recommended except with cascading chaining. 3.6.
Chapter 3. Configuring Directory Databases • Maximum LDAP connection(s). Maximum number of LDAP connections that the database link establishes with the remote server. The default value is 10 connections. • Maximum bind retries. Number of times a database link attempts to bind to the remote server. A value of 0 indicates that the database link will try to bind only once. The default value is 3 attempts. • Maximum operations per connection. Maximum number of outstanding operations per LDAP connection.
Advanced Feature: Tuning Database Link Attribute Name Description nsConcurrentOperationsLimit Maximum number of outstanding operations per LDAP connection. The default value is 2 operations per connection. nsConcurrentBindLimit Maximum number of outstanding bind operations per TCP connection. The default value is 10 outstanding bind operations. nsBindRetryLimit Number of times a database link attempts to bind to the remote server.
Chapter 3. Configuring Directory Databases The first attribute, nsMaxResponseDelay, sets a maximum duration for an LDAP operation to complete. If the operation takes more than the amount of time specified in this attribute, the database link's server suspects that the remote server is no longer online. Once the nsMaxResponseDelay period has been met, the database link pings the remote server.
Performance link contacts the remote server, forwards the operation, waits for the result, and then sends the result back to the client application. The entire operation can take much longer than a local operation. While the database link waits for results from the remote server, it can process additional operations. By default, the number of threads used by the server is 30.
Chapter 3. Configuring Directory Databases The client application sends a modify request to server one. Server one contains a database link that forwards the operation to server two, which contains another database link. The database link on server two forwards the operations to server three, which contains the data the clients wants to modify in a database. Two hops are required to access the piece of data the client want to modify.
Advanced Feature: Configuring Cascading The root suffix dc=example,dc=comand the ou=people and ou=groups sub suffixes are stored on server A. The l=europe,dc=example,dc=com and ou=groups suffixes are stored in on server B, and the ou=people branch of the l=europe,dc=example,dc=com suffix is stored on server C.
Chapter 3. Configuring Directory Databases To set cascading chaining defaults for all database links in Directory Server, do the following: 1. In the Directory Server Console, select the Configuration tab. 2. Expand the Data folder in the left pane, and click Database Link Settings. Click the Default Creation Parameters tab. 3. Select the Check local ACI checkbox to enable the evaluation of local ACIs on the intermediate database links involved in cascading chaining.
Chaining 5. Click Save. 3.7.4. Configuring Cascading Chaining from the Command-Line To configure a cascade of database links through the command-line, do the following: 1. Point one database link to the URL of the server containing the intermediate database link. To create a cascading chain, the nsFarmServerURL attribute of one database link must contain the URL of the server containing another database link. Suppose the database link on the server called example1.
Chapter 3. Configuring Directory Databases the administrator has access only to the suffix of the database link. For example: aci: (targetattr = "*")(version 3.0; acl "Proxied authorization for database links"; allow (proxy) userdn = "ldap:///cn=proxy admin,cn=config";) This ACI is like the ACI created on the remote server when configuring simple chaining. CAUTION Carefully examine access controls when enabling chaining to avoid giving access to restricted areas of the directory.
Advanced Feature: Configuring Cascading aci: (targetattr = "*")(version 3.0; acl "Client authentication for database link users"; allow (all) userdn = "ldap:///uid=* ,cn=config";) This ACI allows client applications that have a uid in the cn=config entry of server one to perform any type of operation on the data below the ou=people,dc=example,dc=com suffix on server three. 3.7.5. Detecting Loops An LDAP control included with Directory Server prevents loops.
Chapter 3. Configuring Directory Databases Attribute Description aci This attribute must contain the following ACI: aci: (targetattr = "*")(version 3.0; acl "Proxied authorization for database links"; allow (proxy) userdn = "ldap:///cn=proxy admin,cn=config";) nsCheckLocalACI To enable evaluation of local ACIs on all database links involved in chaining, turn local ACI evaluation on, as follows: nsCheckLocalACI: on Table 3.7. Cascading Chaining Configuration Attributes 3.7.7.
Chaining • Section 3.7.7.1, “Configuring Server One” • Section 3.7.7.2, “Configuring Server Two” • Section 3.7.7.3, “Configuring Server Three” 3.7.7.1. Configuring Server One 1.
Chapter 3. Configuring Directory Databases 2. Then specify the configuration information for the database link, DBLink1, on server one, as follows: dn: cn=DBLink1,cn=chaining database,cn=plugins,cn=config objectclass: top objectclass: extensibleObject objectclass: nsBackendInstance nsslapd-suffix: c=africa,ou=people,dc=example,dc=com nsfarmserverurl: ldap://africa.example.
Advanced Feature: Configuring Cascading objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson cn: server1 proxy admin sn: server1 proxy admin userPassword: secret description: Entry for use by database links CAUTION Do not use the Directory Manager or Administrator ID user as the proxy administrative user on the remote server. This creates a security hole. 2.
Chapter 3. Configuring Directory Databases add: nsTransmittedControl nsTransmittedControl: 2.16.840.1.113730.3.4.12 nsTransmittedControl: 1.3.6.1.4.1.1466.29539.12 nsTransmittedControl: 2.16.840.1.113730.3.4.12 is the OID for the proxy authorization control. nsTransmittedControl: 1.3.6.1.4.1.1466.29539.12 is the or the loop detection control. Check beforehand whether the loop detection control is already configured, and adapt the above command accordingly. 4. Configure the ACIs.
Chaining given that ACI checking is turned on. This ACI is the same as the ACI created on the destination server to provide access to the l=Zanzibar,c=africa,ou=people,dc=example,dc=com branch. All users within c=us,ou=people,dc=example,dc=com may need to have update access to the entries in l=Zanzibar,c=africa,ou=people,dc=example,dc=com on server three.
Chapter 3. Configuring Directory Databases client on server two: aci: (targetattr ="*")(target="l=Zanzibar,c=africa,ou=people,dc=example,dc=com") (version 3.0; acl "Client authentication for database link users"; allow (all) userdn = "ldap:///uid=*,c=us,ou=people,dc=example,dc=com";) The cascading chaining configuration is now set up. This cascading configuration allows a user to bind to server one and modify information in the l=Zanzibar,c=africa,ou=people,dc=example,dc=com branch on server three.
Setting Default Referrals • port is the optional port number of the Directory Server to start in referral mode. • referral_url is the referral returned to clients. The format of an LDAP URL is covered in Appendix C, LDAP URLs. 4.2. Setting Default Referrals Default referrals are returned to client applications that submit operations on a DN not contained within any of the suffixes maintained by the directory.
Chapter 3. Configuring Directory Databases ldapmodify binds to the server and prepares it to change an entry in the configuration file. 2. Add the default referral to the dir2.example.com server: dn: cn=config changetype: modify replace: nsslapd-referral nsslapd-referral: ldap://dir2.example.com/ After adding the default referral to the cn=config entry of the directory, the directory will return the default referral in response to requests made by client applications.
Creating Smart Referrals ldap://hostname:portnumber/[optional_dn] optional_dn is the explicit DN for the server to return to the requesting client application. For example, this LDAP URL references John Doe's entry: ldap://directory.example.com:389/cn=john doe,o=people,l=europe,dc=example,dc=com For the server to use the DN from the original search request instead, enter the LDAP URL in the format: ldap://hostname:portnumber/ Clicking Construct opens a wizard to direct the process of adding a referral.
Chapter 3. Configuring Directory Databases NOTE Any information after a space in an LDAP URL is ignored by the server. For this reason, use %20 instead of spaces in any LDAP URL used as a referral. To add the entry uid=jdoe,ou=people,dc=example,dc=com with a referral to directory.europe.example.
Creating Suffix Referrals • Return Referrals for all Operations. This means that a referral will be returned when this suffix receives any request from a client application. • Return Referrals for Update Operations. This means a referral will be returned when this suffix receives an update request from a client application. This option is used to redirect update and write requests made by client applications to a read-only database. 4. Click the Referrals tab.
Chapter 3. Configuring Directory Databases For more information about the suffix configuration attributes, refer to Table 3.1, “Suffix Attributes”.
Chapter 4. Populating Directory Databases Databases contain the directory data managed by the Red Hat Directory Server. 1. Importing Data Directory Server provides three methods for importing data: • Import from the Directory Server Console. Use the Directory Server Console to append data to all of the databases, including database links. • Initialize databases. The Directory Server Console can import data to one database; this method overwrites any data contained by the database.
Chapter 4. Populating Directory Databases The following sections describe importing data: • Section 1.1, “Importing a Database from the Console” • Section 1.2, “Initializing a Database from the Console” • Section 1.3, “Importing from the Command-Line” CAUTION All imported LDIF files must also contain the root suffix. 1.1.
Initializing a Database from the Console contains some entries that already exist in the database in addition to new ones. The server notes existing entries in the rejects file while adding all new entries. 4. In the File for Rejects field, enter the full path to the file in which the server is to record all entries it cannot import, or click Browse to select the file which will contain the rejects.
Chapter 4. Populating Directory Databases 3. Right-click the database, and select Initialize Database. Alterntatively, select Initialize Database from the Object menu. 4. In the LDIF file field, enter the full path to the LDIF file to import, or click Browse. 5. If the Console is running from a machine local to the file being imported, click OK and proceed with the import immediately.
Importing from the Command-Line CAUTION This script overwrites the data in the database. To import LDIF, do the following: 1. Stop the server. 2 service dirsrv stop instance 2. Open the Directory Server instance directory. cd /usr/lib/dirsrv/slapd-instance_name 3. Run the ldif2db command-line script. ldif2db -n Database1 -i /var/lib/dirsrv/slapd-instance_name/ldif/demo.ldif -i /var/lib/dirsrv/slapd-instance_name/ldif/demo2.
Chapter 4. Populating Directory Databases Table 4.2. ldif2db Parameters For more information about using this script, see the Directory Server Configuration, Command, and File Reference. 1.3.2. Importing Using the ldif2db.pl Perl Script As with the ldif2db script, the ldif2db.pl script overwrites the data in the specified database. This script requires the server to be running in order to perform the import. CAUTION This script overwrites the data in the database. 1.
Exporting Data Option Description files at a time, use multiple -i arguments. When multiple files are imported, the server imports the LDIF files in the order they are specified in the command-line. -n Specifies the name of the database to which to import the data. Table 4.3. ldif2db Options 1.3.3. Importing Using the ldif2ldap Command-Line Script The ldif2ldap script appends the LDIF file through LDAP. Using this script, data are imported to all directory databases at the same time.
Chapter 4. Populating Directory Databases • Copying data to another Directory Server. • Exporting data to another application. • Repopulating databases after a change to the directory topology. For example, if a directory contains one database, and its contents are split into two databases, then the two new databases receive their data by exporting the contents of the old databases and importing it into the two new databases, as illustrated in Figure 4.
Exporting Directory Data to LDIF Using the • Section 2.1, “Exporting Directory Data to LDIF Using the Console” • Section 2.2, “Exporting a Single Database to LDIF Using the Console” • Section 2.3, “Exporting to LDIF from the Command-Line” CAUTION Do not stop the server during an export operation. 2.1. Exporting Directory Data to LDIF Using the Console Some or all of directory data can be exported to LDIF, depending upon the location of the final exported file.
Chapter 4. Populating Directory Databases Alternatively, click Browse to select a suffix or subtree. 5. Click OK to export the file. 2.2. Exporting a Single Database to LDIF Using the Console It is also possible to export a single database to LDIF. Do the following while the server is running: 1. Select the Configuration tab. 2. Expand the Data tree in the left navigation pane. Expand the suffix, and select the database under the suffix. 3. Right-click the database, and select Export Database.
Console 2. Run the db2ldif command-line script. db2ldif -n database1 -a /export/output.ldif This exports the database contents to /export/output.ldif. If the -a option is not specified, then the database information is exported to /var/lib/dirsrv/slapd-instance_name/ldif/instance_name-database1-date.ldif. For example: db2ldif -n database1 It is also possible to specify which suffixes to export, using the -s option.
Chapter 4. Populating Directory Databases Option Description serverID-firstsuffixvalue-YYYY_MM_DD_hhmmxx.ldif with the -s option. Table 4.4. db2ldif Options 3. Backing up and Restoring Data Databases can be backed up and restored using the Directory Server Console or a command-line script. • Section 3.1, “Backing up All Databases” • Section 3.2, “Backing up the dse.ldif Configuration File” • Section 3.3, “Restoring All Databases” • Section 3.4, “Restoring a Single Database” • Section 3.
Backing up All Databases database contents and associated index files to a backup location. A backup can be performed while the server is running. To back up databases from the Directory Server Console, do the following: 1. Select the Tasks tab. 2. Click Back Up Directory Server. The Backup Directory dialog box opens. 3. Enter the full path of the directory to store the backup file in the Directory text box, or click Use default, and the server provides a name for the backup directory.
Chapter 4. Populating Directory Databases The backup directory where the server saves the backed up databases can be specified with the script. If a directory is not specified, the backup file is stored in 1 /var/lib/dirsrv/slapd-instance_name/bak. By default, the backup directory is named with the Directory Server instance name and the date of the backup (serverID-YYYY_MM_DD_hhmmss). 3.2. Backing up the dse.ldif Configuration File Directory Server automatically backs up the dse.ldif configuration file.
Restoring All Databases 3. Select the backup from the Available Backups list, or enter the full path to a valid backup in the Directory text box. The Available Backups list shows all backups located in the default directory, 1 /var/lib/dirsrv/slapd-instance_name/bak/backup_directory. backup_directory is the directory of the most recent backup, in the form serverID-YYYY_MM_DD_hhmmss. 4. Click OK. 3.3.2.
Chapter 4. Populating Directory Databases cd /usr/lib/dirsrv/slapd-instance_name 2. Run the bak2db.pl Perl script. bak2db.pl -D "cn=Directory Manager" -w secret -a /var/lib/dirsrv/slapd-instance_name/bak/instance_name-2007_04_30_11_48_30 For more information on using this Perl script, see the Directory Server Configuration, Command, and File Reference. Option Description -a Defines the full path and name of the input file. -D Specifies the DN of the administrative user.
Restoring Databases That Include If the Directory Server fails to start, remove the database transaction log files in /var/lib/dirsrv/slapd-instance_name/db/log.###, then retry starting the server. 3.5.
Chapter 4. Populating Directory Databases To restore the dse.ldif configuration file, do the following: 1. Stop the server.2 service dirsrv stop instance 2. Restore the database as outlined in Section 3.4, “Restoring a Single Database” to copy the backup copy of the dse.ldif file into the directory. 3. Restart the server.
Chapter 5. Managing Entries with Roles, Class of Service, and Views Entries contained within the directory can be grouped in different ways to simplify the management of user accounts. Red Hat Directory Server supports a variety of methods for grouping entries and sharing attributes between entries. To take full advantage of the features offered by roles and class of service, determine the directory topology when planning the directory deployment. 1.
Chapter 5. Managing Entries with Roles, Class of Service, and Views • To assign a particular role to a given entry. • To remove a particular role from a given entry. Managed roles can do everything that can normally be done with static groups. The role members can be filtered using filtered roles, similarly to the filtering with dynamic groups. Roles are easier to use than groups, more flexible in their implementation, and reduce client complexity.
Managing Roles Using the Console inactivating the role to which they belong. When a role is inactivated, it does not mean that the user cannot bind to the server using that role entry. The meaning of an inactivated role is that the user cannot bind to the server using any of the entries that belong to that role; the entries that belong to an inactivated role will have the nsAccountLock attribute set to true.
Chapter 5. Managing Entries with Roles, Class of Service, and Views 1.2.1. Creating a Managed Role Managed roles have an explicit enumerated list of members. Managed roles are added to entries by adding the nsRoleDN attribute to the entry. To create and add members to a managed role, do the following: 1. In the Directory Server Console, select the Directory tab. 2. Browse the tree in the left navigation pane, and select the parent entry for the new role. 3. Go to the Object menu, and select New > Role.
Managing Roles Using the Console 1.2.2. Creating a Filtered Role Entries are assigned to a filtered role depending upon a particular attribute contained by each entry. The role definition specifies an LDAP filter for the target attributes. Entries that match the filter possess (are members of) the role. To create and add members to a filtered role, do the following: 1. Follow the steps of Section 1.2.1, “Creating a Managed Role”. 2. Click Members in the left pane. A search dialog box appears briefly. 3.
Chapter 5. Managing Entries with Roles, Class of Service, and Views The Directory Server Console automatically shows the nsRoleDN attribute. 1.2.3. Creating a Nested Role Nested roles are roles that contain other roles. Before it is possible to create a nested role, another role must exist. When a nested role is created, the Console displays a list of the roles available for nesting. The roles nested within the nested role are specified using the nsRoleDN attribute.
Managing Roles Using the Console To view or edit a role associated with an entry from the Console, do the following: 1. In the Directory Server Console, select the Directory tab. 2. In the left navigation pane, browse the tree, and select the entry for which to view or edit a role. 3. Select Set Roles from the Object menu. The Roles dialog box opens. 4. Select the Managed Roles tab to display the managed roles to which this entry belongs.
Chapter 5. Managing Entries with Roles, Class of Service, and Views Members of a role can be temporarily disabled by inactivating the role to which they belong. Inactivating a role inactivates the entries possessed by the role, not the role itself. To temporarily disable the members of a role, do the following: 1. In the Directory Server Console, select the Directory tab. 2. Browse the navigation tree in the left pane to locate the base DN for the role. Roles appear in the right pane with other entries.
Managing Roles Using the Command-Line A dialog box appears to confirm the deletion. Click Yes. NOTE Deleting a role deletes the role entry but does not delete the nsRoleDN attribute for each role member. To delete the nsRoleDN attribute for each role member, enable the Referential Integrity plug-in, and configure it to manage the nsRoleDN attribute. For more information on the Referential Integrity plug-in, see Section 5, “Maintaining Referential Integrity”. 1.3.
Chapter 5. Managing Entries with Roles, Class of Service, and Views also means that these attributes must be explicitly requested in the search attributes list in search requests. For example, this ldapsearch command lists all of the roles (values of nsRole), all of the managed roles (values of nsRoleDN), and all of the regular attributes in the entry matched by uid=scarter. ldapsearch ... args ...
Managing Roles Using the Command-Line nsSimpleRoleDefinition object classes. dn: cn=Marketing,ou=people,dc=example,dc=com objectclass: top objectclass: LdapSubEntry objectclass: nsRoleDefinition objectclass: nsSimpleRoleDefinition objectclass: nsManagedRoleDefinition cn: Marketing description: managed role for marketing staff 3.
Chapter 5. Managing Entries with Roles, Class of Service, and Views The following entry matches the filter (possesses the o attribute with the value sales managers), and, therefore, it is a member of this filtered role automatically: dn: cn=Pat,ou=people,dc=example,dc=com objectclass: person cn: Pat sn: Pat userPassword: bigsecret o: sales managers 1.3.3.
Assigning Class of Service users to be able to adder remove themselves easily from a role. For example, if there is an interest group role called Mountain Biking, interested users should be able to add themselves or remove themselves easily. However, in some security contexts, it is inappropriate to have such open roles. Consider account inactivation roles. By default, account inactivation roles contain ACIs defined for their suffix.
Chapter 5. Managing Entries with Roles, Class of Service, and Views • Section 2.1, “About CoS” • Section 2.2, “Managing CoS Using the Console” • Section 2.3, “Managing CoS from the Command-Line” • Section 2.4, “Creating Role-Based Attributes” • Section 2.5, “Access Control and CoS” 2.1. About CoS Clients of the Directory Server read the attributes on a user's entry. With CoS, some attribute values may not be stored with the entry itself.
About CoS • Classic CoS. A classic CoS identifies the template entry using a combination of the template entry's base DN and the value of one of the target entry's attributes. For more information about the object classes and attributes associated with each type of CoS, refer to Section 2.3, “Managing CoS from the Command-Line”.
Chapter 5. Managing Entries with Roles, Class of Service, and Views Figure 5.1. Sample Pointer CoS In this example, the template entry is identified by its DN, cn=exampleUS,cn=data, in the CoS definition entry. Each time the postalCode attribute is queried on the entry cn=wholiday,ou=people,dc=example,dc=com, the Directory Server returns the value available in the template entry cn=exampleUS,cn=data. 2.1.4.
About CoS Figure 5.2. Sample Indirect CoS In this example, the target entry for William Holiday contains the indirect specifier, the manager attribute. William's manager is Carla Fuentes, so the manager attribute contains a pointer to the DN of the template entry, cn=Carla Fuentes,ou=people,dc=example,dc=com. The template entry in turn provides the departmentNumber attribute value of 318842. 2.1.5.
Chapter 5. Managing Entries with Roles, Class of Service, and Views Figure 5.3. Sample Classic CoS In this example, the CoS definition entry's cosSpecifier attribute specifies the employeeType attribute. This attribute, in combination with the template DN, identify the template entry as cn=sales,cn=exampleUS,cn=data. The template entry then provides the value of the postalCode attribute to the target entry. 2.1.6.
Managing CoS Using the Console • The postalCode attribute for Ted Morris is defined by a CoS. • The postalCode attribute for Barbara Jensen is set in her entry. • The postalCode attribute is not indexed. If an ldapsearch command uses the filter (postalCode=*), then both Barbara Jensen's and Ted Morris's entries are returned. • CoS allows for an override, an identifier given to the cosAttribute attribute in the CoS entry, which means that local values for an attribute can override the CoS value.
Chapter 5. Managing Entries with Roles, Class of Service, and Views 5. Click Attributes in the left pane. The right pane displays a list of attributes generated on the target entries. Click Add to browse the list of possible attributes and add them to the list. 6. After an attribute is added to the list, a drop-down list appears in the Class of Service Behavior column.
Managing CoS Using the Console 8. Click OK. 2.2.2. Creating the CoS Template Entry For a pointer CoS or a classic CoS, there must be a template entry, according to the template DN set when the class of service was created. Although the template entries can be placed anywhere in the directory as long as the cosTemplateDn attribute reflects that DN, it is best to place the template entries under the CoS itself.
Chapter 5. Managing Entries with Roles, Class of Service, and Views 8. Click the Add Attribute button, and add the attributes listed in the CoS. The values used here will be used throughout the directory in the targeted entries. 9. Set the cospriority. There may be more than one CoS that applies to a given attribute in an entry; the cospriority attribute ranks the importance of that particular CoS. The higher cospriority will take precedence in a conflict. The highest priority is 0.
Managing CoS from the Command-Line of service. The CoS appears in the right pane with other entries. 3. Right-click the CoS, and select Delete. A dialog box appears to confirm the deletion. Click Yes. 2.3. Managing CoS from the Command-Line Because all configuration information and template data is stored as entries in the directory, standard LDAP tools can be used for CoS configuration and management. This section contains the following topics: • Section 2.3.
Chapter 5. Managing Entries with Roles, Class of Service, and Views CoS Type Object Classes Description using both the template entry's DN (as specified in the cosTemplateDn attribute) and the value of one of the target entry's attributes (as specified in the cosSpecifier attribute). Table 5.2. CoS Definition Entry Object Classes Table 5.3, “CoS Definition Entry Attributes” lists attributes that available to use in the CoS definition entries.
Managing CoS from the Command-Line to be returned. When operational is used as a qualifier, it works as if override and operational were specified. NOTE An attribute can only be made operational if it is also defined as operational in the schema. For example, if the CoS generates a value for the description attribute, it is not possible to use the operational qualifier because this attribute is not marked operational in the schema. • Operational-default.
Chapter 5.
Managing CoS from the Command-Line be added to any other search filter using OR (|): ldapsearch -s sub -b ou=People,dc=example,dc=com “(|(objectclass=*)(objectclass=ldapSubEntry))” This search returns all regular entries in addition to CoS definition entries in the ou=People,dc=example,dc=com subtree. NOTE The Console automatically shows CoS entries. 2.3.2. Creating the CoS Template Entry from the Command-Line Each template entry is an instance of the cosTemplate object class.
Chapter 5. Managing Entries with Roles, Class of Service, and Views For example, a CoS template entry for generating a department number appears as follows: dn: cn=data,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: cosTemplate departmentNumber: 71776 cosPriority: 0 This template entry contains the value for the departmentNumber attribute.
Managing CoS from the Command-Line cosAttribute: postalCode 3. Create the template entry. dn: cn=exampleUS,ou=data,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: cosTemplate postalCode: 44438 The CoS template entry (cn=exampleUS,ou=data,dc=example,dc=com) supplies the value stored in its postalCode attribute to any entries located under the dc=example,dc=com suffix. These entries are the target entries. 2.3.4.
Chapter 5. Managing Entries with Roles, Class of Service, and Views vary depending on the department number listed in the different manager's entries. 2.3.5. Example of a Classic CoS The Example Corporation administrator is creating a classic CoS that automatically generates postal codes using a combination of the template DN and the attribute specified in the cosSpecifier attribute. 1. Add a new classic CoS definition entry to the dc=example,dc=com suffix, using ldapmodify.
Creating Role-Based Attributes 2.4. Creating Role-Based Attributes Classic CoS schemes generate attribute values for an entry based on the role possessed by the entry. For example, role-based attributes can be used to set the server look-through limit on an entry-by-entry basis. To create a role-based attribute, use the nsRole attribute as the cosSpecifier in the CoS definition entry of a classic CoS.
Chapter 5. Managing Entries with Roles, Class of Service, and Views NOTE The role entry and the CoS definition and template entries should be located at the same level in the directory tree. 2.5. Access Control and CoS The server controls access to attributes generated by a CoS in exactly the same way as regular stored attributes. However, access control rules depending upon the value of attributes generated by CoS will not work.
Creating Views in the Console Figure 5.4. A Directory Tree with a Virtual DIT View hierarchy Virtual DIT views behave like normal DITs in that a subtree or a one-level search can be performed with the expected results being returned. TIP There is a sample LDIF file with example views entries, Example-views.ldif, installed with Directory Server. This file is in the /usr/share/dirsrv/data directory on Red Hat Enterprise Linux and Solaris and the /opt/dirsrv/share/data directory on HP-UX. 3.1.
Chapter 5. Managing Entries with Roles, Class of Service, and Views object class. 6. Name the organization unit according to how to organize the views. For instance, ou=Sunnyvale. Make the ou attribute the naming attribute. 7. Hit the Add Attribute button, and add the nsviewfilter attribute. 8. Create a filter that reflects the views. For example: (l=Sunnyvale) 9. Hit OK to close the attributes box, and hit OK again to save the new view entry.
Deleting Views from the Command Line dn: ou=Example View,dc=example,dc=com objectClass: top objectClass: organizationalunit objectClass: nsview ou=Example View nsViewFilter: l=Mountain View description: Example View 3.4. Deleting Views from the Command Line To delete a view from the command line, do the following: 1. Use the ldapdelete utility to bind to the server and prepare it to remove the view entry to the configuration file.
Chapter 5. Managing Entries with Roles, Class of Service, and Views NOTE If a user has an entry on a remote Directory Server (for example, in a chained database), different from the Directory Server which has the entry that defines the static group, then use the Referential Integrity plug-in to ensure that deleted user entries are automatically deleted from the static group, but there are some performance and access control considerations.
Managing Dynamic Groups 3. Click OK. To view the changes, go to the View menu, and select Refresh. NOTE The Console for managing static groups may not display all possible selections during a search operation if there is no VLV index for users' search. This problem occurs only when the number of users is 1000 or more and there is no VLV index for search. To work around the problem, create a VLV index for the users suffix with the filter (objectclass=person) and scope sub-tree. 4.2.
Chapter 5. Managing Entries with Roles, Class of Service, and Views The Edit Group dialog box appears. 3. Make any changes to the group information. Click OK. To view the changes, go to the View menu, and select Refresh. NOTE The Console for managing dynamic groups may not display all possible selections during a search operation if there is no VLV index for users' search. This problem can occur when the number of users is 1000 or more and there is no VLV index for search.
Chapter 6. Managing Access Control Red Hat Directory Server allows you to control access to your directory. This chapter describes the how to implement access control. To take full advantage of the power and flexibility of access control, while you are in the planning phase for your directory deployment, define an access control strategy as an integral part of your overall security policy. 1. Access Control Principles The mechanism which defines user access is called access control.
Chapter 6. Managing Access Control 1.2. ACI Placement If an entry containing an ACI does not have any child entries, the ACI applies to that entry only. If the entry has child entries, the ACI applies to the entry itself and all entries below it. As a direct consequence, when the server evaluates access permissions to any given entry, it verifies the ACIs for every entry between the one requested and the directory suffix, as well as the ACIs on the entry itself.
Default ACIs When creating an access control policy for your directory service, you need to be aware of the following restrictions: • If your directory tree is distributed over several servers using the chaining feature, some restrictions apply to the keywords you can use in access control statements: • ACIs that depend on group entries (groupdn keyword) must be located on the same server as the group entry. If the group is dynamic, then all members of the group must have an entry on the server, too.
Chapter 6. Managing Access Control security attributes, such as aci, nsroledn, and passwordExpirationTime, cannot be modified by users. • Users have anonymous access to the directory for search, compare, and read operations. • The administrator (by default uid=admin,ou=Administrators, ou=TopologyManagement,o=NetscapeRoot) has all rights except proxy rights. • All members of the Configuration Administrators group have all rights except proxy rights.
Defining Targets 3.1. The ACI Syntax The aci attribute uses the following syntax: aci: (target)(version 3.0;acl "name";permissionbind_rules;) • target specifies the entry, attributes, or set of entries and attributes for which to control access. The target can be a distinguished name, one or more attributes, or a single LDAP filter. The target is an optional part of the ACI. • version 3.0 is a required string that identifies the ACI version. • name is a name for the ACI.
Chapter 6. Managing Access Control The target identifies to what the ACI applies. If the target is not specified, the ACI applies to the entry containing the aci attribute and to the entries below it. A target can be any of the following: • A directory entry or all of the entries in a subtree, as described in Section 3.2.1, “Targeting a Directory Entry”. • Attributes of an entry, as described in Section 3.2.2, “Targeting Attributes”.
Defining Targets accounting branch of the example.com tree. As a counter example, if you place an ACI on the ou=accounting,dc=example,dc=com entry, you cannot target the uid=sarette,ou=people,dc=example,dc=com entry because it is not located under the accounting tree. Be wary of using != when specifying an attribute to deny. ACLs are treated as a logical OR, which means that if you created two ACLs as shown below, the result allows all values of the target attribute. acl1: ( target=...
Chapter 6. Managing Access Control (target="ldap:///uid=lfuentes,dc=example.com Bolivia\,S.A."). Wildcards can be used when targeting a distinguished name using the target keyword. The wildcard indicates that any character or string or substring is a match for the wildcard. Pattern matching is based on any other strings that have been specified with the wildcard. The following are legal examples of wildcard usage: • (target="ldap:///uid=*,dc=example,dc=com") — Matches every entry in the entire example.
Defining Targets the targeted entries. This is useful to deny or allow access to partial information about an entry. For example, you could allow access to only the common name, surname, and telephone number attributes of a given entry while denying access to sensitive information such as passwords. You can specify that the target is equal or is not equal to a specific attribute. The attributes you supply do not need to be defined in the schema.
Chapter 6. Managing Access Control The order in which you specify the target and the targetattr keywords is not important. 3.2.4. Targeting Entries or Attributes Using LDAP Filters You can use LDAP filters to target a group of entries that match certain criteria. To do this, you must use the targetfilter keyword with an LDAP filter. The syntax of the targetfilter keyword is as follows: (targetfilter = "LDAP_filter") LDAP_filter is a standard LDAP search filter.
Defining Targets should verify that they target the correct entries and attributes by using the same filter in an ldapsearch operation. 3.2.5. Targeting Attribute Values Using LDAP Filters You can use access control to target specific attribute values. This means that you can grant or deny permissions on an attribute if that attribute's value meets the criteria defined in the ACI. An ACI that grants or denies access based on an attribute's value is called a value-based ACI.
Chapter 6. Managing Access Control except the superAdmin role. It also allows users to add a telephone number with a 123 prefix. NOTE You cannot create value-based ACIs from the Directory Server Console. 3.2.6. Targeting a Single Directory Entry Targeting a single directory entry is not straightforward because it goes against the design philosophy of the access control mechanism.
Defining Permissions • Assigning rights 3.3.1. Allowing or Denying Access You can either explicitly allow or deny access permissions to the directory tree. NOTE From the Directory Server Console, you cannot explicitly deny access, only grant permissions. 3.3.2. Assigning Rights Rights detail the specific operations a user can perform on directory data.
Chapter 6. Managing Access Control Right Description operation. Selfwrite Indicates whether users can add or delete their own DN from a group. This right is used only for group management. Proxy Indicates whether the specified DN can access the target with the rights of another entry. All Indicates that the specified DN has all rights (read, write, search, delete, compare, and selfwrite) to the targeted entry, excluding proxy rights. Table 6.2.
Defining Permissions default but could be restricted using the targattrfilters keyword. • Deleting an entry: • Grant delete permission on the entry to be deleted. • Grant write permission on the value of each attribute in the entry. This right is granted by default but could be restricted using the targattrfilters keyword. • Modifying an attribute in an entry: • Grant write permission on the attribute type. • Grant write permission on the value of each attribute type.
Chapter 6. Managing Access Control The search result list is empty because this ACI does not grant access to the objectclass attribute. If you want the search operation described above to be successful, modify the ACI to allow read and search access for the mail and objectclass attributes. aci: (targetattr = "mail || objectclass")(version 3.0; acl "self access to mail"; allow (read, search) userdn = "ldap:///self";) 3.3.4.
Bind Rule Syntax Bind rules define who can access the directory, when, and from where by defining any of the following: • Users, groups, and roles that are granted access. • Locations from which an entity must bind. • Times or days on which binding must occur. • Types of authentication that must be in use during binding. Additionally, bind rules can be complex constructions that combine these criteria by using Boolean operators. See Section 4.10, “Using Boolean Bind Rules” for more information. 4.1.
Chapter 6. Managing Access Control Keyword Valid Expressions Wildcard Allowed groupdn ldap:///DN|| DN No roledn ldap:///DN|| DN No userattr attribute#bindType orattribute#value No ip IP_address Yes dns DNS_host_name Yes dayofweek sun mon tue wed thu fri sat No timeofday 0 - 2359 No authmethod No none simple ssl sasl sasl_mechanism Table 6.3. LDIF Bind Rule Keywords 4.2. Defining User Access - userdn Keyword User access is defined using the userdn keyword.
Defining User Access - userdn Keyword 4.2.1. Anonymous Access (anyone Keyword) Granting anonymous access to the directory means that anyone can access it without providing a bind DN or password and regardless of the circumstances of the bind. You can limit anonymous access to specific types of access (for example, read or search access) or to specific subtrees or individual entries within the directory. From the Directory Server Console, you define anonymous access through the Access Control Editor.
Chapter 6. Managing Access Control NOTE Do not specify a hostname or port number within the LDAP URL. LDAP URLs always apply to the local server. For more information about LDAP URLs, see Appendix C, LDAP URLs. 4.2.6. Wildcards You can also specify a set of users by using the wildcard character (*). For example, specifying a user DN of uid=u*,dc=example,dc=com indicates that only users with a bind DN beginning with the letter u are allowed or denied access based on the permissions you set.
Defining Group Access - groupdn Keyword Scenario Example Userdn userdn = "ldap:///self"; keyword containing self keyword Description The bind rule is evaluated to be true if the user is accessing the entry represented by the DN with which the user bound to the directory. That is, if the user has bound as uid=ssarette, dc=example,dc=com and the user is attempting an operation on the uid=ssarette,dc=example,dc=com entry, then the bind rule is true. If you want to grant all users in the example.
Chapter 6. Managing Access Control 4.3. Defining Group Access - groupdn Keyword Members of a specific group can access a targeted resource. This is known as group access. Group access is defined using the groupdn keyword to specify that access to a targeted entry is granted or denied if the user binds using a DN that belongs to a specific group. The groupdn keyword requires one or more valid distinguished names in the following format: groupdn="ldap:///dn [|| ldap:///dn]...
Defining Access Based on Value Matching or denied if the user binds using a DN that belongs to a specific role. The roledn keyword requires one or more valid distinguished names in the following format : roledn = "ldap:///dn [|| ldap:///dn]... [|| ldap:///dn]" The bind rule is evaluated to be true if the bind DN belongs to the specified role. NOTE If a DN contains a comma, the comma must be escaped by a backslash (\).
Chapter 6. Managing Access Control userattr = "attrName#bindType Using an attribute type that requires a value other than a user DN, group DN, role DN, or an LDAP filter has the following format: userattr = "attrName#attrValue • attrName is the name of the attribute used for value matching. • bindType is either USERDN, GROUPDN, or LDAPURL. • attrValue is any string representing an attribute value. 4.5.1.1.
Defining Access Based on Value Matching intensive. If you are using static groups that are under the same suffix as the targeted entry, you can use the following expression: userattr = "ldap:///dc=example,dc=com?owner#GROUPDN" In this example, the group entry is under the dc=example,dc=com suffix. The server can process this type of syntax more quickly than the previous example. (By default, owner is not an allowed entry in a user's entry.
Chapter 6. Managing Access Control The following associates the userattr keyword with a bind based on an LDAP filter: userattr = "myfilter#LDAPURL The bind rule is evaluated to be true if the bind DN matches the filter specified in the myfilter attribute of the targeted entry. The myfilter attribute can be replaced by any attribute that contains an LDAP filter. 4.5.1.5.
Defining Access Based on Value Matching userattr = "parent[0,1].manager#USERDN" This bind rule is evaluated to be true if the bind DN matches the manager attribute of the targeted entry. The permissions granted when the bind rule is evaluated to be true apply to the target entry and to all entries immediately below it. The example in Figure 6.
Chapter 6. Managing Access Control hole, and the server's normal behavior is modified to avoid it. Consider the following example: aci: (target="ldap:///dc=example,dc=com")(targetattr=*) (version 3.0; acl "manager-write"; allow (all) userattr = "manager#USERDN";) This ACI grants managers all rights on the entries of employees that report to them.
Defining Access from a Specific Domain ip = "12.123.1.*"; The bind rule is evaluated to be true if the client accessing the directory is located at the named IP address. This can be useful for allowing certain kinds of directory access only from a specific subnet or machine. For example, use a wildcard IP address such as 12.3.45.* to specify a specific subnetwork or 123.45.6.*+255.255.255.115 to specify a subnetwork mask.
Chapter 6. Managing Access Control The bind rule is evaluated to be true if the client accessing the directory is located in the named domain. This can be useful for allowing access only from a specific domain. Wildcards will not work if your system uses a naming service other than DNS. In such a case, if you want to restrict access to a particular domain, use the ip keyword, as described in Section 4.6, “Defining Access from a Specific IP Address”. 4.8.
Defining Access Based on Authentication • The bind rule is evaluated to be true if the client is accessing the directory at noon. timeofday = "1200"; • The bind rule is evaluated to be true if the client is accessing the directory at any time other than 1 a.m. timeofday != "0100"; • The bind rule is evaluated to be true if the client is accessing the directory at any time after 8 a.m.
Chapter 6. Managing Access Control Simple. The client must provide a user name and password to bind to the directory. • SSL. The client must bind to the directory over a Secure Sockets Layer (SSL) or Transport Layer Security (TLS) connection, using a client certificate for authentication. In the case of SSL, the connection is established to the LDAPS second port; in the case of TLS, the connection is established through a Start TLS operation. In both cases, a certificate must be provided.
Method authentication (bind DN and password) over LDAPS. authmethod = "ssl"; • The bind rule is evaluated to be true if the client is accessing the directory using the SASL DIGEST-MD5 mechanism. authmethod = "sasl DIGEST-MD5"; 4.10. Using Boolean Bind Rules Bind rules can be complex expressions that use the Boolean expressions AND, OR, and NOT to set very precise access rules. You cannot use the Directory Server Console to create Boolean bind rules. You must create an LDIF statement.
Chapter 6. Managing Access Control Because Boolean expressions are evaluated from left to right, in the first case, bind rule A is evaluated before bind rule B, and, in the second case, bind rule B is evaluated before bind rule A. However, the Boolean NOT is evaluated before the Boolean OR and Boolean AND. Thus, in the following example, bind rule B is evaluated before bind rule A despite the left-to-right rule. (bind_rule_A) AND NOT (bind_rule_B) 5.
Displaying the Access Control Editor 5.1. Displaying the Access Control Editor 1. Start the Directory Server Console. Log in using the bind DN and password of a privileged user, such as the Directory Manager, who has write access to the ACIs configured for the directory. /usr/bin/redhat-idm-console 2. Select the Directory tab. 3. Right-click the entry in the navigation tree for which to set access control, and select Set Access Permissions from the pop-up menu.
Chapter 6. Managing Access Control Figure 6.2. Access Control Editor Window 5.2. Creating a New ACI To create a new ACI in the Directory Server Console, do the following: 1. Open the Access Control Editor, as described in Section 5.1, “Displaying the Access Control Editor”. If the view displayed is different from Figure 6.2, “Access Control Editor Window”, click the Edit Visually button. 2. Type the ACI name in the ACI Name field. The name can be any unique string to identify the ACI.
Creating a New ACI a. Select a search area from the drop-down list, enter a search string in the Search field, and click the Search button. You can use wilcards (an asterisk, *) to search for partial usernames. The search results are displayed in the list below. b. Highlight the entries you want in the search result list, and click the Add button to add them to the list of entries which have access permission. c. Click OK to dismiss the Add Users and Groups window.
Chapter 6. Managing Access Control 5. Click the Targets tab. Click This Entry to display the current node as the target for the ACI or click Browse to select a different suffix.
Creating a New ACI NOTE You can change the value of the target DN, but the new DN must be a direct or indirect child of the selected entry. If you do not want every entry in the subtree under this node to be targeted by the ACI, enter a filter in the Filter for Sub-entries field. The filter applies to every entry below the target entry; for example, setting a filter of ou=Sales means that only entries with ou=Sales in their DN are returned.
Chapter 6. Managing Access Control You can specify a hostname or an IP address. With an IP address, you can use an asterisk (*) as a wildcard. 7. Click the Times tab to display the table showing at what times access is allowed. By default, access is allowed at all times. You can change the access times by clicking and dragging the cursor over the table. You cannot select discrete blocks of time, only continuous time ranges.
Editing an ACI 8. When you have finished editing the ACI, click OK. The Access Control Editor closes, and the new ACI is listed in the Access Control Manager window. NOTE For any point of creating the ACI, you can click the Edit Manually button to display the LDIF statement corresponding to the wizard input. You can modify this statement, but your changes may not be visible in the graphical interface. 5.3. Editing an ACI To edit an ACI, do the following: 1.
Chapter 6. Managing Access Control 2. In the Access Control Manager window, highlight the ACI to edit, and click Edit. 3. Make the edits to the ACI in the Access Control Editor; the different screens are described more in Section 5.2, “Creating a New ACI” and in the online help. 4. When you have finished editing the ACI, click OK. The Access Control Editor windows closes, and the modified ACI is listed in the Access Control Manager. 5.4. Deleting an ACI To delete an ACI, do the following: 1.
Get Effective Rights Control Permissions. The Access Control Manager opens with a list of the ACIs belonging to the selected entry. 3. Check the Show Inherited ACIs checkbox to display all ACIs created on entries above the selected entry that also apply. 7. Get Effective Rights Control Finding the rights on existing attributes within a specific entry offers a convenient way for administrators to find and control the access rights.
Chapter 6. Managing Access Control In this example, Ted Morris has the right to add, view, delete, or rename the DN on his own entry, as shown by the return values in entryLevelRights. For attributes, he has the right to read, search, compare, self-modify, or self-delete the location (l) attribute but only self-write and self-delete rights to his password, as shown in the attributeLevelRights return value.
Using Get Effective Rights from the • search_base specifies the entry or entries being checked, while AuthId checks the rights of the AuthId entry over the search_base entry. • control OID is the OID for the get effective rights control, 1.3.6.1.4.1.42.2.27.9.5.2. • boolean criticality specifies whether the search operation should return an error if the server does not support this control (true) or if it should be ignored and let the search return as normal (false).
Chapter 6. Managing Access Control ldapsearch -p 389 -h localhost -D "cn=directory manager" -w password -b "uid=tmorris,ou=people,dc=example,dc=com" -J "1.3.6.1.4.1.42.2.27.9.5.2:true:dn: uid=dmiller,ou=people,dc=example,dc=com" "(objectClass=*)" version: 1 dn: uid=tmorris, ou=People, dc=example,dc=com givenName: Ted sn: Morris ou: Accounting ou: People l: Santa Clara manager: uid=dmiller, ou=People, dc=example,dc=com roomNumber: 4117 mail: tmorris@example.
Command-Line uid=scarter,ou=people,dc=example,dc=com, then Ted Morris would retrieve the following effective rights information: entryLevelRights: v attributeLevelRights: givenName:rsc, sn:rsc, ou:rsc, l:rsc,manager:rsc, roomNumber:rsc, mail:rsc, facsimileTelephoneNumber:rsc, objectClass:rsc, uid:rsc, cn:rsc,userPassword:none This means that Sam Carter has the right to view the DN of the entry and to read, search; the right to compare the ou, givenName, l, and other attributes; and no rights to the userP
Chapter 6. Managing Access Control Code Description queried, then this error is returned. 16 No such attribute. If an attribute is specifically queried for access rights but that attribute does not exist in the schema, this error is returned. 17 Undefined attribute type. 21 Invalid attribute syntax. 50 Insufficient rights. 52 Unavailable. 53 Unwilling to perform. 80 Other. Table 6.8. Returned Result Codes 8.
Granting Anonymous Access actually hosts and partially manages the directories of two medium-sized companies, HostedCompany1 and HostedCompany2. It also provides Internet access to a number of individual subscribers. These are the access control rules that example.com wants to put in place: • Grant anonymous access for read, search, and compare to the entire example.com tree for example.com employees (Section 9.1, “Granting Anonymous Access”). • Grant write access to example.
Chapter 6. Managing Access Control "Anonymous World"”. 9.1.1. ACI "Anonymous example.com" In LDIF, to grant read, search, and compare permissions to the entire example.com tree to example.com employees, write the following statement: aci: (targetattr !="userPassword")(version 3.0; acl "Anonymous Example"; allow (read, search, compare) userdn= "ldap:///anyone" and dns="*.example.com";) This example assumes that the aci attribute is added to the dc=example,dc=com entry.
Granting Write Access to Personal Entries This example assumes that the ACI is added to the ou=subscribers,dc=example,dc=com entry. It also assumes that every subscriber entry has an unlistedSubscriber attribute which is set to yes or no. The target definition filters out the unlisted subscribers based on the value of this attribute. For details on the filter definition, see Section 9.8, “Setting a Target Using Filtering”. From the Console, set this permission by doing the following: 1.
Chapter 6. Managing Access Control It is also example.com's policy to let their subscribers update their own personal information in the example.com tree, provided that they establish an SSL connection to the directory. This is illustrated in Section 9.2.2, “ACI "Write Subscribers"”. 9.2.1. ACI "Write example.com" NOTE By setting this permission, you are also granting users the right to delete attribute values. Granting example.
Granting Write Access to Personal Entries suffix in the Target directory entry field. In the attribute table, select the checkboxes for the homePhone, homePostalAddress, and userPassword attributes. All other checkboxes should be clear; if it is easier, click the Check None button to clear the checkboxes for all attributes in the table, then click the Name header to organize them alphabetically, and select the appropriate ones. 6. In the Hosts tab, click Add to display the Add Host Filter dialog box.
Chapter 6. Managing Access Control a. Select and remove All Users, then click Add. The Add Users and Groups dialog box opens. b. Set the Search area to Special Rights, and select Self from the search results list. c. Click the Add button to list Self in the list of users who are granted access permission. d. Click OK to dismiss the Add Users and Groups dialog box. 4. In the Rights tab, select the checkbox for write. Make sure the other checkboxes are clear. 5.
Restricting Access to Key Roles see Section 1, “Using Roles”. When a role gives any sort of privileged user rights over critical corporate or business functions, consider restricting access to that role. For example, at example.com, employees can add any role to their own entry except the superAdmin role. This is illustrated in Section 9.3.1, “ACI "Roles"”. 9.3.1. ACI "Roles" In LDIF, to grant example.
Chapter 6. Managing Access Control 7. To create the value-based filter for roles, switch to manual editing by clicking the Edit Manually button. Add the following to the beginning of the LDIF statement: (targattrfilters="add=nsroledn:(nsroledn != "cn=superAdmin, dc=example,dc=com")") The LDIF statement should read as follows: (targattrfilters="add=nsroledn:(nsroledn != "cn=superAdmin, dc=example,dc=com")") (targetattr = "*") (target = "ldap:/// ou=example-people,dc=example,dc=com") (version 3.
Granting Rights to Add and Delete Group display the Access Control Manager. 2. Click New to display the Access Control Editor. 3. In the Users/Groups tab, in the ACI name field, type HR. In the list of users granted access permission, do the following: a. Select and remove All Users, then click Add. The Add Users and Groups dialog box opens. b. Set the Search area to Users and Groups, and type HRgroup in the Search for field. This example assumes that you have created an HR group or role.
Chapter 6. Managing Access Control (version 3.0; acl "Create Group"; allow (add) (userdn= "ldap:///uid=*,ou=example-people,dc=example,dc=com") and dns="*.example.com";) NOTE This ACI does not grant write permission, which means that the entry creator cannot modify the entry. This example assumes that the ACI is added to the ou=social committee, dc=example,dc=com entry. From the Console, set this permission by doing the following: 1.
Entries (targattrfilters="add=objectClass:(objectClass=groupOfNames)") The LDIF statement should read as follows: (targattrfilters="add=objectClass:(objectClass=groupOfNames)") (targetattr = "*") (target="ldap:///ou=social committee,dc=example,dc=com) (version 3.0; acl "Create Group"; allow (read,search,add) (userdn= "ldap:///all") and (dns="*.example.com"); ) 8. Click OK. The new ACI is added to the ones listed in the Access Control Manager window. 9.5.2. ACI "Delete Group" In LDIF, to grant example.
Chapter 6. Managing Access Control of the directory tree, provided the following conditions are fulfilled: • Connection authenticated using SSL • Access requested between 8 a.m. and 6 p.m., Monday through Thursday • Access requested from a specified IP address for each company These conditions are illustrated in a single ACI for each company, HostedCompany1 and HostedCompany2. Because the content of these ACIs is the same, the examples below illustrate the HostedCompany1 ACI only. 9.6.1.
Denying Access c. Click the Add button to list the administrators role in the list of users who are granted access permission. d. Click OK to dismiss the Add Users and Groups dialog box. 4. In the Rights tab, click the Check All button. 5. In the Targets tab, click This Entry to display the ou=HostedCompany1,ou=corporate-clients,dc=example,dc=com suffix in the Target directory entry field. 6. In the Hosts tab, click Add to display the Add Host Filter dialog box.
Chapter 6. Managing Access Control For example, example.com wants all subscribers to be able to read billing information such as connection time or account balance under their own entries but explicitly wants to deny write access to that information. This is illustrated in Section 9.7.1, “ACI "Billing Info Read"” and Section 9.7.2, “ACI "Billing Info Deny"”, respectively. 9.7.1.
Denying Access This example assumes that you have added the connectionTime and accountBalance attributes to the schema. 6. Click OK. The new ACI is added to the ones listed in the Access Control Manager window. 9.7.2. ACI "Billing Info Deny" In LDIF, to deny subscribers permission to modify billing information in their own entry, write the following statement: aci: (targetattr="connectionTime || accountBalance") (version 3.
Chapter 6. Managing Access Control All other checkboxes should be clear; if it is easier, click the Check None button to clear the checkboxes for all attributes in the table, then click the Name header to organize them alphabetically, and select the appropriate ones. This example assumes that the connectionTime and accountBalance attributes were added to the schema. 7. Click OK. The new ACI is added to the ones listed in the Access Control Manager window. 9.8.
Allowing Users to Add or Remove At example.com, employees can add themselves to any group entry under the ou=social committee subtree. This is illustrated in Section 9.9.1, “ACI "Group Members"”. 9.9.1. ACI "Group Members" In LDIF, to grant example.com employees the right to add or delete themselves from a group, write the following statement: aci: (targettattr="member")(version 3.
Chapter 6. Managing Access Control The new ACI is added to the ones listed in the Access Control Manager window. 9.10. Defining Permissions for DNs That Contain a Comma DNs that contain commas require special treatment within your LDIF ACI statements. In the target and bind rule portions of the ACI statement, commas must be escaped by a single backslash (\). For example: dn: dc=example.com Bolivia\, S.A.,dc=com objectClass: top objectClass: organization aci: (target="ldap:///dc=example.com Bolivia\,S.A.
Themselves from a Group userdn="ldap://uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com") With this ACI in place, the MoneyWizAcctSoftware client application can bind to the directory and send an LDAP command such as ldapsearch or ldapmodify that requires the access rights of the proxy DN.
Chapter 6. Managing Access Control subdomains with the same tree structure (ou=groups, ou=people). This pattern is also repeated across the tree because the example.com directory tree stores the suffixes dc=hostedCompany2, dc=example,dc=com and dc=hostedCompany3,dc=example,dc=com. The ACIs that apply in the directory tree also have a repeating pattern.
Macro ACI Syntax The following ACI is located on the dc=hostedCompany2,dc=example,dc=com node: aci: (targetattr="*")(targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany2,dc=example,dc=com";) The following ACI is located on the dc=subdomain1,dc=hostedCompany2, dc=example,dc=com node: aci: (targetattr="*")(targetfilter=(objectClass=nsManagedDomain)) (version 3.
Chapter 6. Managing Access Control Macro ACI Keyword ($dn) target, targetfilter, userdn, roledn, groupdn, userattr [$dn] targetfilter, userdn, roledn, groupdn, userattr ($attr.attrName) userdn, roledn, groupdn, userattr Table 6.9. Macros in ACI Keywords The following restrictions apply: • If you use ($dn) in targetfilter, userdn, roledn, groupdn, userattr, you must define a target that contains ($dn).
Macro ACI Syntax In this case, if the string matching ($dn) in the target is dc=subdomain1, dc=hostedCompany1, then the same string is used in the subject. The ACI is then expanded as follows: aci: (target="ldap:///ou=Groups,dc=subdomain1,dc=hostedCompany1, dc=example,dc=com") (targetattr = "*") (version 3.
Chapter 6. Managing Access Control For example, consider the following ACI: aci: (target="ldap:///ou=*, ($dn),dc=example,dc=com") (targetattr="*")(targetfilter=(objectClass=nsManagedDomain)) (version 3.
Access Control and Replication ou: People, dc=HostedCompany1,dc=example,dc=com... In this case, when the Directory Server evaluates the ACI, it performs a logical OR on the following expanded expressions: roledn = "ldap:///cn=DomainAdmins,ou=Engineering,dc=HostedCompany1,dc=example,dc=com" roledn = "ldap:///cn=DomainAdmins,ou=People,dc=HostedCompany1,dc=example,dc=com" 11.
242
Chapter 7. Managing User Accounts and Passwords When a user connects to the Red Hat Directory Server, first the user is authenticated. Then, the directory grants access rights and resource limits to the user depending upon the identity established during authentication.
Chapter 7. Managing User Accounts and Passwords Essentially, the password policy is comprised of the following information: • The type or level of password policy checks. This information indicates whether the server should check for and enforce a global password policy or local (subtree/user level) password policies. • Password add and modify information. The password information includes password syntax and password history details. • Bind information.
Configuring the Password Policy force the users to update their password. 5. To allow users to change their own passwords, select the User may change password checkbox. 6. To prevent users from changing their password for a specific duration, enter the number of days in the Allow changes in X day(s) text box. 7. For the server to maintain a history list of passwords used by each user, select the Keep password history checkbox.
Chapter 7. Managing User Accounts and Passwords server to use when storing passwords. For detailed information about the encryption methods, refer to the passwordStorageScheme attribute in Table 7.1, “Password Policy Attributes”. The Password Encryption menu might contain other encryption methods, as the directory dynamically creates the menu depending upon the existing encryption methods it finds in the directory. 13.Click Save. 1.1.2. Configuring a Subtree/User Password Policy Using the Console 1.
Configuring the Password Policy 1.1.3. Configuring a Global Password Policy Using the Command-Line To set up the password policy for a subtree or user, add the required entries and attributes at the subtree or user level, set the appropriate values to the password policy attributes, and enable fine-grained password policy checking. This section describes the attributes to create a password policy for the entire server (globally) using ldapmodify to change these attributes in the cn=config entry. Table 7.
Chapter 7. Managing User Accounts and Passwords Attribute Name Definition user's password will expire after an interval given by the passwordMaxAge attribute. Making passwords expire helps protect the directory data because the longer a password is in use, the more likely it is to be discovered. This attribute is off by default. passwordMaxAge This attribute indicates the number of seconds after which user passwords expire.
Configuring the Password Policy Attribute Name Definition discourage users from reusing old passwords. For example, setting the minimum password age to 2 days prevents users from repeatedly changing their passwords during a single session to cycle through the password history and reuse an old password once it has been removed from the history list. The minimum age can be from 0 to 2147472000 seconds (24,855 days). A value of zero indicates that the user can change the password immediately.
Chapter 7. Managing User Accounts and Passwords Attribute Name Definition Shorter passwords are easier to crack. Passwords can be two (2) to 512 characters long. Generally, a length of eight characters is long enough to be difficult to crack but short enough for users to remember without writing it down. This attribute is set to 8 by default. passwordMaxRepeats This attribute set the maximum number of times that the same character can be used in row, such as aaaaa.
Configuring the Password Policy Attribute Name Definition Lowercase letters (a to z) Numbers (0 through 9) Special ASCII characters, such as $ ASCII alphabetic characters, regardless of case (a to z and A to Z) 8-bit characters Repeated characters, such as aaaaaa This attribute is set to 3 by default. passworMinUppers This attribute sets the minimum number of upper case alphabetic characters, A to Z, which must be used in the password.
Chapter 7. Managing User Accounts and Passwords Attribute Name Definition password will appear in plain text. The only password storage scheme that can be used with SASL DIGEST-MD5 is CLEAR. Passwords stored using crypt, SHA, or SSHA formats cannot be used for secure login through SASL Digest MD5. To provide a customized storage scheme, consult Red Hat professional services. Table 7.1. Password Policy Attributes 1.1.4.
Configuring the Password Policy • The actual password policy specification entry (nsPwPolicyEntry) for holding all the password policy attributes that are specific to the subtree.
Chapter 7. Managing User Accounts and Passwords dn: cn="cn=nsPwPolicyEntry,uid=jdoe,ou=people,dc=example,dc=com", cn=nsPwPolicyContainer,ou=people,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: ldapsubentry objectclass: passwordpolicy 3. Assign the value of the above entry DN to the pwdpolicysubentry attribute of the target entry.
Setting User Passwords ldapmodify -h myserver -p 389 -D "cn=directory manager" -w secretpwd dn: cn=config changetype: modify replace: nsslapd-pwpolicy-local: on nsslapd-pwpolicy-local: off This attribute can also be disabled by modifying it directly in the configuration file (dse.ldif). 1. Stop the server. 2 service dirsrv stop instance 2. Open the dse.ldif file in a text editor. 3. Set the value of nsslapd-pwpolicy-local to off, and save. nsslapd-pwpolicy-local: off 4. Start the server.
Chapter 7. Managing User Accounts and Passwords Directory Server supports the password change extended operation as defined in RFC 3062, so users can change their passwords, using a suitable client, in a standards-compliant way. Directory Server does not include a client application for the password change extended operation. However, the ldappasswd utility can be used as follows: ldappasswd -h hostname -p secure_port -Z -P /path/to/cert8.
Configuring the Account Lockout Policy To use Start TLS, which runs the command on a non-secure port, run ldappasswd with the -ZZ option and the standard LDAP port number. The password extended change operation has the following format: ldappasswd -h hostname -p standard_port -ZZ -P /path/to/cert8.db -D bindDN -w bindPassword -s newPassworduser [-a oldPassword] Use the -ZZZ for additional certificate hostname validation. To modify an entry's password, run ldappasswd like any other LDAP operation.
Chapter 7. Managing User Accounts and Passwords 1. Select the Configuration tab and then the Data node. 2. In the right pane, select the Account Lockout tab. 3. To enable account lockout, select the Accounts may be locked out checkbox. 4. Enter the maximum number of allowed bind failures in the Lockout account after X login failures text box. The server locks out users who exceed the limit specified here. 5.
Managing the Password Policy in a Attribute Name Definition out of the directory. This attribute takes affect only if the passwordLockout attribute is set to on. This attribute is set to 3 bind failures by default. passwordLockoutDuration This attribute indicates the time, in seconds, that users will be locked out of the directory. The passwordUnlock attribute specifies that a user is locked out until the password is reset by an administrator. By default, the user is locked out for 3600 seconds.
Chapter 7. Managing User Accounts and Passwords Some of the password policy information in the directory is replicated: • passwordMinAge and passwordMaxAge • passwordExp • passwordWarning However, the configuration information is kept locally and is not replicated. This information includes the password syntax and the history of password modifications. Account lockout counters and tiers are not replicated, either.
Replicated Environment • The Password Sync utility must be installed locally on the Windows machine that will be synchronized with a Directory Server. • Password Sync can only link the Windows machine to a single Directory Server; to sync changes with multiple Directory Server instances, configure the Directory Server for multi-master replication.
Chapter 7. Managing User Accounts and Passwords creating the entry for a root or sub suffix, and Chapter 3, Configuring Directory Databases has information on creating root and sub suffixes. 2.1. Inactivating User and Roles Using the Console The following procedure describes inactivating a user or a role using the Console: 1. Select the Directory tab. 2. Browse the navigation tree in the left navigation pane, and double-click the user or role to inactivate. The Edit Entry dialog box appears.
Activating User and Roles Using the For more information about running the ns-inactivate.pl script, refer to the Directory Server Configuration, Command, and File Reference. 2.3. Activating User and Roles Using the Console The following procedure describes activating a user or a role using the Console: 1. Select the Directory tab. 2. Browse the navigation tree in the left navigation pane, and double-click the user or role to activate. Alternatively, select Activate from the Object menu.
Chapter 7. Managing User Accounts and Passwords For more information about running the ns-activate.pl script, refer to the Directory Server Configuration, Command, and File Reference. 3. Setting Resource Limits Based on the Bind DN Server limits for search operations are controlled using special operational attribute values on the client application binding to the directory. You can set the following search operation limits: • Look through limit.
Console Entering a value of -1 indicates no limit. 4. Click OK. 3.2. Setting Resource Limits Using the Command-Line The following operational attributes can be set for each entry using the command-line. Use ldapmodify to add the following attributes to the entry: Attribute Description nsLookThroughLimit Specifies how many entries are examined for a search operation. Giving this attribute a value of -1 indicates that there is no limit.
266
Chapter 8. Managing Replication Replication is the mechanism by which directory data is automatically copied from one Red Hat Directory Server instance to another; it is an important mechanism for extending the directory service beyond a single server configuration. This chapter describes the tasks to be performed on the master and consumer servers to set up single-master replication, multi-master replication, and cascading replication. 1.
Chapter 8. Managing Replication read-write replicas. 1.3. Suppliers and Consumers A server that holds a replica that is copied to a replica on a different server is called a supplier for that replica. A server that holds a replica that is copied from a different server is called a consumer for that replica.
Replication Agreement another server), this entry must be specified as the one authorized to perform replication updates. • The replication agreement is created on the supplier server, the DN of this entry must be specified in the replication agreement. • The supplier bind DN entry must not be part of the replicated database for security reasons.
Chapter 8. Managing Replication of Directory Server. Compatibility is provided through two Directory Server plug-ins: • Legacy Replication Plug-in. The Legacy Replication Plug-in makes a Directory Server 8.0 instance behave as a 4.x Directory Server in a consumer role. For information on how to implement legacy replication using this plug-in, see Section 15, “Replication with Earlier Releases”. • Retro Changelog Plug-in.
Multi-Master Replication Figure 8.1. Single-Master Replication In this particular configuration, the ou=people,dc=example,dc=com suffix receives a large number of search requests. Therefore, to distribute the load, this tree, which is mastered on server A, is replicated to two read-only replicas located on server B and server C. For information on setting up a single-master replication environment, see Section 4, “Configuring Single-Master Replication”. 2.2.
Chapter 8. Managing Replication Figure 8.2, “Multi-Master Replication (Two Masters)” shows an example of multi-master replication scenario with two supplier servers and two consumer servers. Figure 8.2. Multi-Master Replication (Two Masters) Figure 8.3, “Multi-Master Replication (Four Masters)” shows a sample of multi-master replication scenario with four supplier servers and eight consumer servers.
Multi-Master Replication Figure 8.3. Multi-Master Replication (Four Masters) Multi-master configurations have the following advantages: • Automatic write failover when one supplier is inaccessible. • Updates are made on a local supplier in a geographically distributed environment. NOTE The speed that replication proceeds depends on the speed of the network.
Chapter 8. Managing Replication Replication”. 2.3. Cascading Replication In a cascading replication scenario, one server, a hub, acts both as a consumer and a supplier. It holds a read-only replica and maintains a changelog, so it receives updates from the supplier server that holds the master copy of the data and, in turn, supplies those updates to the consumer.
Creating the Supplier Bind DN Entry For information on setting up cascading replication, see Section 6, “Configuring Cascading Replication”. NOTE Multi-master and cascading replication can be combined. For example, in the multi-master scenario illustrated in Figure 8.2, “Multi-Master Replication (Two Masters)”, server C and server D could be hub servers that would replicate to any number of consumer servers. 3.
Chapter 8. Managing Replication Manager entry or replication manager (supplier bind DN) entry under cn=config since this centralizes configuration information. On each server that acts as a consumer in replication agreements, create a special entry that the supplier will use to bind to the consumers. Make sure to create the entry with the attributes required by the authentication method specified in the replication agreement. 1. Stop the Directory Server.
Configuring the Read-Write Replica on the • Section 4.1, “Configuring the Read-Write Replica on the Supplier Server” • Section 4.2, “Configuring the Read-Only Replica on the Consumer” • Section 4.3, “Create the Replication Agreement” 4.1. Configuring the Read-Write Replica on the Supplier Server 1. Specify the supplier settings for the server. a. In the Directory Server Console, select the Configuration tab. b. In the navigation tree, select the Replication folder. c.
Chapter 8. Managing Replication 2. Specify the replication settings required for a read-write replica. a. In the navigation tree on the Configuration tab, expand the Replication node, and highlight the database to replicate. The Replica Settings tab opens in the right-hand side of the window. b. Check the Enable Replica checkbox. c. In the Replica Role section, select the Single Master radio button. d. In the Common Settings section, specify a Replica ID, which is an integer between 1 and 65534, inclusive.
Supplier Server c. Check the Enable Replica checkbox. d. In the Replica Role section, select the Dedicated Consumer radio button. e. In the Common Settings section, specify a purge delay in the Purge delay field. This option indicates how often the state information stored in the replicated entries is purged. f. In the Update Settings section, specify the bind DN that the supplier will use to bind to the replica. Enter the supplier bind DN in the Enter a new Supplier DN field, and click Add.
Chapter 8. Managing Replication NOTE There can be multiple supplier bind DNs per consumer but only one supplier DN per replication agreement. g. Specify the URL for any supplier servers to which to refer updates. By default, all updates are first referred to the supplier servers that are specified here. If no suppliers are set here, updates are referred to the supplier servers that have a replication agreement that includes the current replica.
Create the Replication Agreement • Unless there is more than one instance of Directory Server configured, by default, there are no consumers available in the drop-down menu. • The port listed is the non-SSL port, even if the Directory Server instance is configured to run over SSL. This port number is used only for identification of the Directory Server instance in the Console; it does not specify the actual port number or protocol that is used for replication.
Chapter 8. Managing Replication NOTE If attribute encryption is enabled, a secure connection must be used for the encrypted attributes to be replicated. Hit Next. 4. Fractional replication controls which entry attributes are replicated between servers. By default, all attributes are replicated. To select attributes that will not be replicated to the consumer, check the Enable Fractional Replication checkbox.
Create the Replication Agreement NOTE To safeguard against potential integrity problems, the consumer in fractional replication must be a dedicated consumer, not a multi-master supplier or hub. This is not enforced at the time the replication agreement is made, but replication will fail if the consumer is not a read-only replica. 5. Set the schedule for when replication runs. By default, replication runs continually.
Chapter 8. Managing Replication Hit Next. 6. Set when the consumer is initialized. Initializing a consumer manually copies all data over from the supplier to the consumer. The default is to create an initialization file (an LDIF of all supplier data) so that the consumer can be initialized later. It is also possible to initialize the consumer as soon as the replication agreement is completed or not at all. For information on initializing consumers, see Section 10, “Initializing Consumers”.
Configuring Multi-Master Replication dse.ldif file. Hit Done to save the agreement. The replication agreement is set up. NOTE After creating a replication agreement, the connection type (SSL or non-SSL) cannot be changed because LDAP and LDAPS connections use different ports. To change the connection type, re-create the replication agreement.
Chapter 8. Managing Replication 5. Configuring Multi-Master Replication This section provides information on configuring multi-master replication. In a multi-master configuration, many suppliers can accept updates, synchronize with each other, and update all consumers. The consumers can send referrals for updates to all masters. Directory Server supports 4-way multi-master replication. To set up multi-master replication such as the configuration shown in Figure 8.
Configuring the Read-Write Replicas on the d. Check the Enable Changelog checkbox. This activates all of the fields in the pane below that were previously grayed out. e. Specify a changelog by clicking the Use default button, or click the Browse button to display a file selector. f. Set the changelog parameters for the number and age of the log files. Clear the unlimited checkboxes to specify different values. g. Click Save. 2.
Chapter 8. Managing Replication 3. Specify the replication settings for the multi-mastered read-write replica. a. In the Directory Server Console, select the Configuration tab. b. In the navigation tree, expand the Replication folder, and highlight the replica database. The Replica Settings tab for that database opens in the right-hand side of the window. c. Check the Enable Replica checkbox. d. In the Replica Role section, select the Multi-Master radio button. e.
Supplier Servers The purge delay is how often the state information stored in the replicated entries is deleted. g. In the Update Settings section, specify the bind DN that the supplier will use to bind to the replica. Enter the supplier bind DN in the Enter a new Supplier DN field, and click Add. The supplier bind DN appears in the Current Supplier DNs list. The supplier bind DN should be the entry created in step 2.
Chapter 8. Managing Replication c. Check the Enable Replica checkbox. d. In the Replica Role section, select the Dedicated Consumer radio button. e. In the Common Settings section, specify a purge delay in the Purge delay field. This option indicates how often the state information stored in the replicated entries is purged. f. In the Update Settings section, specify the bind DN that the supplier will use to bind to the replica.
Setting up the Replication Agreements NOTE There can be multiple supplier bind DNs per consumer but only one supplier DN per replication agreement. g. Specify the URL for any supplier servers to which to refer updates. By default, all updates are first referred to the supplier servers that are specified here. If no suppliers are set here, updates are referred to the supplier servers that have a replication agreement that includes the current replica.
Chapter 8. Managing Replication • Unless there is more than one instance of Directory Server configured, by default, there are no consumers available in the drop-down menu. • The port listed is the non-SSL port, even if the Directory Server instance is configured to run over SSL. This port number is used only for identification of the Directory Server instance in the Console; it does not specify the actual port number or protocol that is used for replication.
Setting up the Replication Agreements NOTE If attribute encryption is enabled, a secure connection is required for the encrypted attributes to be replicated. Hit Next. 4. Fractional replication controls which entry attributes are replicated between servers. By default, all attributes are replicated. To select attributes that will not be replicated to the consumer, check the Enable Fractional Replication checkbox.
Chapter 8. Managing Replication NOTE To safeguard against potential integrity problems, the consumer in fractional replication must be a dedicated consumer, not a multi-master supplier or hub. This is not enforced at the time the replication agreement is made, but replication will fail if the consumer is not a read-only replica. 5. Set the schedule for when replication runs. By default, replication runs continually.
Setting up the Replication Agreements Hit Next. 6. Set when the consumer is initialized. Initializing a consumer manually copies all data over from the supplier to the consumer. The default is to create an initialization file (an LDIF of all supplier data) so that the consumer can be initialized later. It is also possible to initialize the consumer as soon as the replication agreement is completed or not at all. For information on initializing consumers, see Section 10, “Initializing Consumers”.
Chapter 8. Managing Replication NOTE Replication will not begin until the consumer is initialized. Hit Next. 7. The final screen shows the settings for the replication agreement, as it will be included in the dse.ldif file. Hit Done to save the agreement. The replication agreement is set up.
Preventing Monopolization of the Consumer NOTE At the end of this procedure, all supplier servers will have mutual replication agreements, which means that they can accept updates from each other. NOTE After creating a replication agreement, the connection type (SSL or non-SSL) cannot be changed because LDAP and LDAPS connections use different ports. To change the connection type, re-create the replication agreement. 5.4.
Chapter 8. Managing Replication These two attributes may be present in the nsds5ReplicationAgreement object class, which is used to describe replication agreements. Set the attributes at any time by using changetype:modify with the replace operation. The change takes effect for the next update session if one is already in progress. NOTE If either attribute is set to a negative value, Directory Server sends the client a message and an LDAP_UNWILLING_TO_PERFORM error code.
in Multi-Master Replication • Section 6.3, “Configuring the Read-Only Replica on the Hub” • Section 6.4, “Setting up the Replication Agreements” 6.1. Configuring the Read-Write Replica on the Supplier Server Next, configure the supplier server, which holds the original copy of the database: 1. Specify the supplier settings for the server. a. In the Directory Server Console, select the Configuration tab. b. In the navigation tree, select the Replication folder. c.
Chapter 8. Managing Replication 2. Specify the replication settings required for a read-write replica. a. In the navigation tree on the Configuration tab, expand the Replication node, and highlight the database to replicate. The Replica Settings tab opens in the right-hand side of the window. b. Check the Enable Replica checkbox. c. In the Replica Role section, select the Single Master radio button. d. In the Common Settings section, specify a Replica ID, which is an integer between 1 and 65534, inclusive.
Configuring the Read-Only Replica on the c. Check the Enable Replica checkbox. d. In the Replica Role section, select the Dedicated Consumer radio button. e. In the Common Settings section, specify a purge delay in the Purge delay field. This option indicates how often the state information stored in the replicated entries is purged. f. In the Update Settings section, specify the bind DN that the supplier will use to bind to the replica.
Chapter 8. Managing Replication NOTE There can be multiple supplier bind DNs per consumer but only one supplier DN per replication agreement. g. Specify the URL for any supplier servers to which to refer updates. By default, all updates are first referred to the supplier servers that are specified here. If no suppliers are set here, updates are referred to the supplier servers that have a replication agreement that includes the current replica.
Consumer Server d. Check the Enable Changelog checkbox. This activates all of the fields in the pane below that were previously grayed out. e. Specify a changelog by clicking the Use default button, or click the Browse button to display a file selector. f. Set the changelog parameters for the number and age of the log files. Clear the unlimited checkboxes to specify different values. g. Click Save. 4. Specify the required hub replica settings. a.
Chapter 8. Managing Replication c. Check the Enable Replica checkbox. d. In the Replica Role section, select the Hub radio button. e. In the Common Settings section, specify a purge delay in the Purge delay field. This option indicates how often the state information stored in the replicated entries is purged. f. In the Update Settings section, specify the bind DN that the supplier will use to bind to the replica. Enter the supplier bind DN in the Enter a new Supplier DN field, and click Add.
Setting up the Replication Agreements NOTE There can be multiple supplier bind DNs per consumer but only one supplier DN per replication agreement. g. Specify the URL for any supplier servers to which to refer updates. By default, all updates are first referred to the supplier servers that are specified here. If no suppliers are set here, updates are referred to the supplier servers that have a replication agreement that includes the current replica.
Chapter 8. Managing Replication DN and password on that consumer. If the target server is not available, hit in other to fill in the information manually. • Unless there is more than one instance of Directory Server configured, by default, there are no consumers available in the drop-down menu. • The port listed is the non-SSL port, even if the Directory Server instance is configured to run over SSL.
Setting up the Replication Agreements DN and password. NOTE If attribute encryption is enabled, a secure connection must be used for the encrypted attributes to be replicated. Hit Next. 4. Fractional replication controls which entry attributes are replicated between servers. By default, all attributes are replicated. To select attributes that will not be replicated to the consumer, check the Enable Fractional Replication checkbox.
Chapter 8. Managing Replication NOTE To safeguard against potential integrity problems, the consumer in fractional replication must be a dedicated consumer, not a multi-master supplier or hub. This is not enforced at the time the replication agreement is made, but replication will fail if the consumer is not a read-only replica. 5. Set the schedule for when replication runs. By default, replication runs continually.
Setting up the Replication Agreements Hit Next. 6. Set when the consumer is initialized. Initializing a consumer manually copies all data over from the supplier to the consumer. The default is to create an initialization file (an LDIF of all supplier data) so that the consumer can be initialized later. It is also possible to initialize the consumer as soon as the replication agreement is completed or not at all. For information on initializing consumers, see Section 10, “Initializing Consumers”.
Chapter 8. Managing Replication NOTE Replication will not begin until the consumer is initialized. Hit Next. 7. The final screen shows the settings for the replication agreement, as it will be included in the dse.ldif file. Hit Done to save the agreement.
Configuring Replication from the Command NOTE After creating a replication agreement, the connection type (SSL or non-SSL) cannot be change because LDAP and LDAPS connections use different ports. To change the connection type, re-create the replication agreement. 7. Configuring Replication from the Command Line Replication can be configured on the command line by creating the appropriate replica and agreement entries on the servers.
Chapter 8. Managing Replication ldapmodify -v -h supplier1.example.com -p 389 -D "cn=directory manager" -w password dn: cn=changelog5,cn=config changetype: add objectclass: top objectclass: extensibleObject cn: changelog5 nsslapd-changelogdir: /var/lib/dirsrv/slapd-instance_name/changelogdb There is one important attribute with the changelog, nsslapd-changelogdir, which sets the directory where the changelog is kept. The changelog entry attributes are described in Table 8.1, “Changelog Attributes”.
Line be 1. The replica entry attributes are described in Table 8.2, “Replica Attributes”. After creating every supplier which will take part in the replication setup, then begin creating the replication agreements. Object Class or Attribute Description Values objectclass: top Required object class for every entry. objectclass: extensibleObject An object class which allows any other object class or attribute to be added to an entry. cn: changelog5 The naming attribute for the changelog entry.
Chapter 8. Managing Replication Object Class or Attribute Description Values dc=example,dc=com nsds5replicaid: number The ID of the replica. This must not be set for consumers or hubs, but is required for suppliers. 1 to 65534, inclusive. nsds5replicatype: number Sets the type of replica, either 2 for consumers and hubs read-only or read-write.
Configuring Consumers from the Command Object Class or Attribute Description Values bind DN. nsds5replicareferral: URL Optional. An LDAP URL Any LDAP URL. For example: which a consumer or hub to nsds5replicareferral: which a consumer or hub can ldap://supplier1.example.com:389 forward update requests. By default, update requests are . sent to the masters for the consumer; use this parameter to override the default. Table 8.2. Replica Attributes 7.2.
Chapter 8. Managing Replication nsds5replicatype: 2 nsds5ReplicaBindDN: cn=replication manager,cn=config nsds5flags: 0 The replica entry attributes are described in Table 8.2, “Replica Attributes”. These attributes are described in more detail in the Directory Server Configuration, Command, and File Reference. 7.3. Configuring Hubs from the Command Line Hubs are intermediate read-only replicas which receive updates from suppliers and pass them on to other consumers.
Line nsds5ReplicaPurgeDelay: 604800 nsds5ReplicaBindDN: cn=replication manager,cn=config nsds5flags: 1 This entry identifies the database and suffix as participating in replication and sets what kind of replica the database is. There are five key attributes: • nsds5replicaroot sets the subtree (suffix) which is being replicated. • nsds5replicatype sets what kind of replica this database is. For a hub, this value must be 2.
Chapter 8.
Configuring Replication Agreements from Object Class or Attribute Description Values is not used, this attribute can be absent. nsds5ReplicaBindDN: DN The supplier bind DN used by Any DN; the recommended the supplier to bind to the DN is cn=Replication consumer. This is required for Manager,cn=config. consumers, hubs, and multi-master suppliers, but not for single-master suppliers. nsds5replicabindmethod: type The connection type for replication between the servers.
Chapter 8. Managing Replication Object Class or Attribute Description Values midnight and 2359 is 11:59 PM. For example, the setting 1030 1630 schedules replication from 10:30 AM to 4:30 PM. The times cannot wrap around midnight, so the setting 2300 0100 is not valid. The days ranging from 0 (Sunday) to 6 (Saturday). Setting 06 schedules replication on Sunday and Saturday, while 135 schedules replication on Monday, Wednesday, and Friday.
the Command Line 7.5. Initializing Consumers Online from the Command Line An online initialization can be initiated from the command line by adding the nsds5replicarefresh attribute to the replication agreement entry. If the attribute is included when the replication agreement is created, initialization begins immediately. It can be added later to initialize the consumer at any time. This attribute is absent by default, and it will be automatically deleted once the consumer initialization is complete. 1.
Chapter 8. Managing Replication Depending on the replication scenario, this can be more difficult in mixed replication environments, but, even when manually initializing consumers, consider four things: • Use one supplier, a data master, as the source for initializing consumers. • Do not reinitialize a data master when the replication agreements are created. For example, do not initialize server1 from server2 if server2 has already been initialized from server1.
Moving the Changelog to a New Location 9.1. Removing the Changelog To remove the changelog from the supplier server, do the following: 1. In the Directory Server Console, select the Configuration tab. 2. Select the Replication Agreements folder in the left navigation tree and then the Supplier Server Settings tab in the right pane. 3. Clear the Enable Changelog checkbox. This deletes the changelog. 4. Click Save. 5. Restart the Directory Server. 6.
Chapter 8. Managing Replication • Section 10.2, “Online Consumer Initialization Using the Console” • Section 10.3, “Initializing Consumers Online Using the Command Line” • Section 10.4, “Manual Consumer Initialization Using the Command Line” • Section 10.5, “Filesystem Replica Initialization” 10.1. When to Initialize a Consumer Consumer initialization involves copying data from the supplier server to the consumer server.
Initializing Consumers Online Using the To initialize or reinitialize a consumer online, do the following: 1. Create a replication agreement. 2. On the supplier server, on the Directory Server Console, select the Configuration tab. 3. Expand the Replication folder, then expand the replicated database. Right-click the replication agreement, and choose Initialize Consumer from the pop-up menu. A message opens warning that any information already stored in the replica on the consumer will be removed. 4.
Chapter 8. Managing Replication dn: cn=ExampleAgreement,cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config changetype: modify replace: nsds5beginreplicarefresh nsds5beginreplicarefresh: start ldapmodify does not prompt for input; simply type in the LDIF statement, and then hit enter twice when the LDIF statement is complete. Close the ldapmodify utility by hitting Ctrl+C. To check the initialization status, do an ldapsearch for the replication agreement entry.
Command Line There are three ways to convert a replica database to LDIF: • When creating a replication agreement, by selecting Create consumer initialization file in the Initialize Consumer dialog box of the Replication Agreement Wizard. • From the Directory Server Console, by right-clicking the replication agreement under the Replication folder and choosing Create LDIF File from the pop-up menu. • From the command-line by using the export command, as described in Section 2.
Chapter 8. Managing Replication NOTE The destination server must have the same architecture and the same bit size as the supplier server for the initialization to succeed. For example, Red Hat Enterprise Linux 32-bit to Red Hat Enterprise Linux 32-bit. 10.5.1. Initializing the Consumer Replica from the Backup Files 1. Create a new database on the destination server to match the database from the source server.
Forcing Replication Updates 8. Stop the destination Directory Server if it is running. service dirsrv stop slapd-example2 9. On the destination server, restore the archives with the bak2db script, using the optional -n parameter to specify the backend instance name. This -n parameter is similar to the -n used with ldif2db and db2ldif. For example: /usrlib/dirsrv/slapd-example2/bak2db /tmp/archiveDirectory -n userRoot 10.Restart the destination Directory Server.
Chapter 8. Managing Replication 11.1. Forcing Replication Updates from the Console To ensure that replication updates are sent immediately when a consumer or a supplier in a multi-master replication configuration comes back online after a period of time, do the following on the supplier server that holds the most recent version of the directory information: 1.
Replicating Account Lockout Attributes print "replace:nsds5ReplicaUpdateSchedule";} /^nsds5ReplicaUpdateSchedule: / { s = 1; print $0; }/^$/{if ( $s == 1 ){ print "-" ; print ""; }else{ print "nsds5ReplicaUpdateSchedule: 0000-2359 0123456";print "-" ; print ""; };s = 0; } ' > /tmp/ldif.$$echo "Ldif is in /tmp/ldif.$$"echo ldapmodify -c -h ${SUP_HOST} -p ${SUP_PORT} -D "${SUP_MGRDN}" \-w ${SUP_MGRPW} -f /tmp/ldif.$$ Example 8.1.
Chapter 8. Managing Replication attributes related to the account lockout counts for an entry, so that the malicious user is locked out of every supplier and consumer replica in the configuration if a login attempt fails on a single master. By default, three password policy attributes are not replicated, even if other password attributes are.
Replicating o=NetscapeRoot for the supplier's certificate is only capable of behaving as a server certificate, and not also a client during an SSL handshake. Replication with certificate-based authentication uses the Directory Server's server certificate for authentication to the remote server. When the servers are configured to use SSL, configure an SSL connection for replication in the Replication Agreement Wizard.
Chapter 8. Managing Replication databases, suffixes, and replication entries. (The inf file is described in more detail in the Directory Server Installation Guide.) /usr/sbin/setup-ds-admin.pl -f /tmp/server1.inf To configure the o=NetscapeRoot database on server1 as a multi-master supplier replica, use the following statements in the inf file: [slapd] ... ConfigFile ConfigFile ConfigFile ConfigFile ... = = = = repluser.ldif example supplier bind DN entry changelog.ldif example changelog entry replica.
Administration Server Failover switch the configuration directory for server2 to its own o=NetscapeRoot database from server1. /usr/sbin/register-ds-admin.pl 5. Disable the PTA Plug-in on server2 so that it does not pass bind operations for the administrative users in its o=NetscapeRoot to server1. See Section 2, “Enabling and Disabling Plug-ins”. 15. Replication with Earlier Releases This section provides information on how to optimize replication with earlier releases of Directory Server.
Chapter 8. Managing Replication 5. Click Save. 6. Now configure legacy consumer settings for each replica that will receive updates from a legacy supplier. a. In the navigation tree, expand the Replication node, and select a replica that will receive updates from the legacy supplier. b. In the Replica Settings tab, select the Enable Replica and Updatable by a 4.x Replica checkboxes. These options are the only ones required for replication to work. Optionally, specify a replica ID.
Enabling the Retro Changelog Plug-in Retro Changelog Entry”. Attribute Definition changeNumber This single-valued attribute is always present. It contains an integer which uniquely identifies each change. This number is related to the order in which the change occurred. The higher the number, the later the change. targetDN This attribute contains the DN of the entry that was affected by the LDAP operation.
Chapter 8. Managing Replication 1. Create an LDIF file that contains the following LDIF update statements: dn: cn=Retro Changelog Plugin,cn=plugins,cn=config cn: Retro Changelog Plugin changetype: modify replace: nsslapd-pluginenabled nsslapd-pluginenabled: on 2. Use the ldapmodify command to import the LDIF file into the directory. For more information on the ldapmodify command, see Section 2, “Managing Entries from the Command-Line” and the Directory Server Configuration, Command, and File Reference. 3.
Retro Changelog and the Access Control 16.3. Searching and Modifying the Retro Changelog The changelog supports search operations and is optimized for searches that include filters of the form (&(changeNumber>=X)(changeNumber<=Y)). As a general rule, do not perform add or modify operations on the retro changelog entries, although entries can be deleted to trim the size of the changelog. Only modify the retro changelog entry to modify the default access control policy. 16.4.
Chapter 8. Managing Replication 3. Click Refresh to update the contents of the tab. The status information displayed is described in Table 8.6, “Directory Server Console Replication Status”. Table Header Description Agreement The name of the replication agreement. Replica suffix The suffix that is replicated. Supplier The supplier server in the agreement. Consumer The consumer server in the agreement. Number of changes The number of changes sent to this replica since the server started.
Policy replica ID, replica root, and maximum change sequence number (maxcsn). • Lists corresponding to each supplier replica listed above and for each direct or indirect consumer replicas discovered, server URL or alias, replica root, replica type, connection type of the replication sessions, replication schedule, replication status, supplier maxcsn, and time lag between the consumer maxcsn and the supplier maxcsn. The time lag field uses different colors to indicate the degree of time lag.
Chapter 8. Managing Replication Table Description supplier replica, the replica root, and the maximum Change State Number (CSN) on the supplier. The important thing is to make sure that each supplier LDAP server has its unique replica ID. Multiple replica roots on one LDAP server, however, could share the same replica ID. Table Row Each row represents a direct or indirect consumer of the supplier (identified in the Table Header).
Solving Naming Conflicts the conflicting changes need to be resolved. Mostly, resolution occurs automatically, based on the timestamp associated with the change on each server. The most recent change takes precedence. However, there are some cases where change conflicts require manual intervention in order to reach a resolution. Entries that have a change conflict that cannot be resolved automatically by the replication process contain a conflict marker attribute nsds5ReplConflict.
Chapter 8. Managing Replication To rename an entry that has a multi-valued naming attribute, do the following: 1. Rename the entry using a new value for the naming attribute, and keep the old RDN. For example: ldapmodify -D adminDN -w password dn: nsuniqueid=66446001-1dd211b2+uid=adamss,dc=example,dc=com changetype: modrdn newrdn: uid=NewValue deleteoldrdn: 0 2. Remove the old RDN value of the naming attribute and the conflict marker attribute.
Solving Naming Conflicts dn: cn=John Doe changetype: modrdn newrdn: uid=jdoe1 deleteoldrdn: 1 18.1.2. Renaming an Entry with a Single-Valued Naming Attribute To rename an entry that has a single-valued naming attribute, do the following: 1. Rename the entry using a different naming attribute, and keep the old RDN. For example: ldapmodify -D adminDN -w password dn: nsuniqueid=66446001-1dd211b2+dc=pubs,dc=example,dc=com changetype: modrdn newrdn: cn=TempValue deleteoldrdn: 0 2.
Chapter 8. Managing Replication For more information on the ldapmodify command, see Section 2, “Managing Entries from the Command-Line” and the Directory Server Configuration, Command, and File Reference. 18.2. Solving Orphan Entry Conflicts When a delete operation is replicated and the consumer server finds that the entry to be deleted has child entries, the conflict resolution procedure creates a glue entry to avoid having orphaned entries in the directory.
Troubleshooting Replication-Related (targetfilter="(!(nsds5ReplConflict=*))")(version 3.0;acl "Anonymous read-search access";allow (read, search, compare) (userdn="ldap:///anyone");) > - The new ACI filters out all entries that contain the nsds5ReplConflict attribute from search results. For more information on the ldapmodify command, see Section 2, “Managing Entries from the Command-Line” and the Directory Server Configuration, Command, and File Reference. 19.
Chapter 8. Managing Replication Error/Symptom Reason Replica has a different generation ID than the local data specified at the not replicate any data beginning of this to the consumer. message has not been (successfully) initialized yet, or it was initialized from a different root supplier. it occurs before the consumer is initialized. Otherwise, reinitialize the consumer if the message is persistent.
Problems Error/Symptom Reason Impact Remedy reinitialize the consumer. agmt=%s(%s:%d): Can't locate CSN %s in the changelog (DB rc=%d). The consumer may need to be reinitialized. Most likely the changelog was recreated because of the disk is full or the server ungracefully shutdown. The local server will not be able to send any more change to that consumer until the consumer is reinitialized or gets the CSN from other suppliers. If this is a single-master replication, reinitialize the consumers.
Chapter 8. Managing Replication Error/Symptom Reason Impact Remedy no supplier can get in, restart the consumer. Changelog is getting too big. Either changelog purge is turned off, which is the default setting, or changelog purge is turned on, but some consumers are way behind the supplier. By default changelog purge is turned off.
Troubleshooting Replication-Related Error/Symptom Reason Impact Remedy maximum time lag from the replication monitor among all the consumers. Irrespective of what the purge threshold is, no change will be purged before it is replayed by all the consumers. The Replication Monitor is not responding. (For information on Replication Monitor, see Section 17, “Monitoring Replication Status”.) In the Replication Monitor, some consumers show just the header of the table.
352
Chapter 9. Extending the Directory Schema Red Hat Directory Server comes with a standard schema that includes hundreds of object classes and attributes. While the standard object classes and attributes should meet most deployments' requirements, it can be necessary to extend the schema for specific directory data. Extending the schema is done by creating new object classes and attributes. 1. Overview of Extending Schema There are two steps, in the proper order, required to extend the directory schema: 1.
Chapter 9. Extending the Directory Schema 1. In the Directory Server Console, select the Configuration tab. 2. In the left navigation tree, select the Schema folder, and then select the Attributes tab in the right pane. This tab contains information about all the standard (read-only) and user-defined attributes in the schema. The fields and lists in the Attributes tab are described in Table 9.1, “Attributes Tab Reference”. Field Description Name The name of the attribute.
Creating Attributes Field Description Case Ignore String — Values for this attribute are not case-sensitive. Case Exact String — Values for this attribute are case-sensitive. Distinguished Name — Values for this attribute are DNs. Binary — Values for this attribute are binary. Telephone Number — Values for this attribute are in telephone number format. Integer — Values for this attribute are numbers. There are many more syntaxes available for attributes.
Chapter 9. Extending the Directory Schema 5. Enter an object identifier for the attribute in the Attribute OID (Optional) text box. OIDs are described in Table 9.1, “Attributes Tab Reference”. 6. Select a syntax that describes the data to be held by the attribute from the Syntax drop-down menu. Available syntaxes are described in Table 9.1, “Attributes Tab Reference”. 7. To make the attribute multi-valued, select the Multi-Valued checkbox.
Managing Object Classes attribute, do the following: 1. Display the Attributes tab. This procedure is explained in Section 2.4, “Deleting Attributes”. 2. In the User Defined Attributes table, select the attribute, and click Delete. 3. If prompted, confirm the delete. WARNING The server immediately deletes the attribute. There is no undo. 3. Managing Object Classes The Directory Server Console can manage and show the directory schema's object classes.
Chapter 9. Extending the Directory Schema The fields and lists in the Object Classes tab are described in Table 9.2, “Object Classes Tab Reference”. Field Description Parent The parent identifies the object class from which this object class inherits its attributes and structure. For example, the parent object for the inetOrgPerson object class is the organizationalPerson object. That means that an entry with the object class inetOrgPerson must also include the object class organizationalPerson.
Creating Object Classes Field Description request a prefix, email IANA at mailto:iana@iana.org, or visit the IANA website at http://www.iana.org/. Object Classes Lists all of the standard and user-defined object classes in the Directory Server schema. Required Attributes Contains a list of attributes that must be present in entries that use this object class, including inherited attributes.
Chapter 9. Extending the Directory Schema Any existing object class can be the parent of the new object class. See Table 9.2, “Object Classes Tab Reference” for more information on parent object classes. 8. To add an attribute that must be present in entries that use the new object class, highlight the attribute in the Available Attributes list, and then click the Add button to the left of the Required Attributes box. Both standard attributes and user-defined are allowed.
Deleting Object Classes c. To change the parent object for the object class, select the new parent from the Parent pull-down menu. d. To add an attribute that must be present in entries that use the new object class, highlight the attribute in the Available Attributes list, and then click the Add button to the left of the Required Attributes box. Both standard attributes and user-defined attributes are allowed for the object class. Creating custom attributes is described in Section 2.
Chapter 9. Extending the Directory Schema 4. Turning Schema Checking On and Off When schema checking is on, the Directory Server ensures three things: • The object classes and attributes using are defined in the directory schema. • The attributes required for an object class are contained in the entry. • Only attributes allowed by the object class are contained in the entry.
Chapter 10. Managing Indexes Indexing makes searching for and retrieving information easier by classifying and organizing attributes or values. This chapter describes the searching algorithm itself, placing indexing mechanisms in context, and then describes how to create, delete, and manage indexes. 1. About Indexes This section provides an overview of indexing in Directory Server. It contains the following topics: • Section 1.1, “About Index Types” • Section 1.
Chapter 10. Managing Indexes • Substring index (sub) is a costly index to maintain, but it allows efficient searching against substrings within entries. Substring indexes are limited to a minimum of three characters for each entry. For example, searches of the form cn=*derson , match the common names containing strings such as Bill Anderson, Jill Henderson, or Steve Sanderson. Similarly, the search for telephonenumber= *555* returns all the entries in the directory with telephone numbers that contain 555.
About Default, System, and Standard Attribute Eq Pres Sub Purpose performance of the most common types of user directory searches. mail Improves the performance of the most common types of user directory searches. mailHost Used by a messaging server. member Improves Directory Server performance. This index is also used by the Referential Integrity Plug-in. See Section 5, “Maintaining Referential Integrity” for more information. owner Improves Directory Server performance.
Chapter 10. Managing Indexes Attribute Eq Pres Sub Purpose This index is also used by the Referential Integrity Plug-in. See Section 5, “Maintaining Referential Integrity” for more information. sn Improves the performance of the most common types of user directory searches. telephoneNumber Improves the performance of the most common types of user directory searches. uid Improves Directory Server performance. unique member Improves Directory Server performance.
Indexes System indexes cannot be deleted or modified. They are required by the directory to function properly. Table 10.2, “System Indexes” lists the system indexes included with the directory. Attribute Eq Pres Purpose aci Allows the Directory Server to quickly obtain the access control information maintained in the database. objectClass Used to help accelerate subtree searches in the directory. entryDN Speeds up entry retrieval based on DN searches.
Chapter 10. Managing Indexes Serverprocesses a search request as follows: 1. An LDAP client application sends a search request to the directory. 2. The directory examines the incoming request to make sure that the specified base DN matches a suffix contained by one or more of its databases or database links. • If they do match, the directory processes the request. • If they do not match, the directory returns an error to the client indicating that the suffix does not match.
Approximate Searches See Directory Server Configuration, Command, and File Reference for further information about these attributes. 1.4. Approximate Searches In addition, the directory uses a variation of the metaphone phonetic algorithm to perform searches on an approximate index. Each value is treated as a sequence of words, and a phonetic code is generated for each word. NOTE The metaphone phonetic algorithm in Directory Server supports only US-ASCII letters.
Chapter 10. Managing Indexes Before creating new indexes, balance the benefits of maintaining indexes against the costs. • Approximate indexes are not efficient for attributes commonly containing numbers, such as telephone numbers. • Substring indexes do not work for binary attributes. • Equality indexes should be avoided if the value is big (such as attributes intended to contain photographs or passwords containing encrypted data).
Creating Indexes • Equality, approximate, and substring indexes for cn (common name) and sn (surname) attributes. • Equality and substring indexes for the telephone number attribute. • Substring indexes for the description attribute. When adding that entry to the directory, the Directory Server must perform these steps: 1. Create the cn equality index entry for John and John Doe. 2. Create the appropriate cn approximate index entries for John and John Doe. 3.
Chapter 10. Managing Indexes index to your second database instance, it will not be maintained in your first database instance but will be maintained in any subsequent instances. NOTE The procedure for creating browsing indexes is different than for creating other index types; that procedure is covered in Section 2.3, “Creating Browsing Indexes from the Server Console”. • Section 2.1, “Creating Indexes from the Server Console” • Section 2.2, “Creating Indexes from the Command-Line” • Section 2.
Creating Indexes from the Command-Line The server adds the attribute to the Additional Indexes table. 6. Select the checkbox for each type of index to maintain for each attribute. 7. To create an index for a language other than English, enter the OID of the collation order to use in the Matching Rules field. To index the attribute using multiple languages, list multiple OIDs separated by commas, but no whitespace.
Chapter 10. Managing Indexes cn=plugins,cn=config entry. • To create a new index for a particular database, add it to the cn=index,cn=database_name,cn=ldbm database,cn=plugins,cn=config entry, where cn=database_name corresponds to the name of the database. NOTE Avoid creating entries under cn=config in the dse.ldif file. The cn=config entry in the simple, flat dse.ldif configuration file is not stored in the same highly scalable database as regular entries.
Creating Indexes from the Command-Line objectClass:top objectClass:nsIndex cn:sn nsSystemIndex:false nsIndexType:pres nsIndexType:eq nsIndexType:sub nsMatchingRule:2.16.840.1.113730.3.3.2.3.1 The cn attribute contains the name of the attribute to index, in this example the sn attribute. The entry is a member of the nsIndex object class. The nsSystemIndex attribute is false, indicating that the index is not essential to Directory Server operations.
Chapter 10. Managing Indexes Always use the attribute's primary name (not the attribute's alias) when creating indexes. The primary name of the attribute is the first name listed for the attribute in the schema; for example, uid for the user ID attribute. See Table 10.7, “Attribute Name Quick Reference Table” for a list of all primary and alias attribute names. 2.2.2. Running the db2index.
Creating Browsing Indexes from the 2.3. Creating Browsing Indexes from the Server Console A virtual list view (VLV) index is a way of creating a truncated list for faster searching while enhancing server performance. The VLV index itself can be resource-intensive to maintain, but it can be beneficial in large directories (over 1000 entries). A browsing index is a type of VLV index that organizes the entries listed into alphabetical order, making it easier to find entries.
Chapter 10. Managing Indexes • The scope of the search (base, one, sub) • The base of the search (the entry to use as a starting point for the search) • The attributes to sort • The filter of the search For more information on specifying filters for searches, see Appendix B, Finding Directory Entries. • The LDBM database to which the entry that forms the base of the search belongs. You can only create browsing indexes in LDBM databases.
Command-Line the browsing index; in this example, the ou=People,dc=example,dc=com entry. Red Hat recommends using the dn of the entry for the browsing index identifier, which is the approach adopted by the Directory Server Console, to prevent identical browsing indexes from being created. The entry is a member of the vlvSearch object class.
Chapter 10. Managing Indexes directory. To run the vlvindex script, do the following: 1. Open the Directory Server instance directory.2 cd /usr/lib/dirsrv/slapd-instance_name 2. Stop the server.3 service dirsrv stop instance 3. Run the vlvindex script. vlvindex -n Example1 -T "by MCC ou=people dc=example dc=com" For more information about using this script, see the Directory Server Configuration, Command, and File Reference. 4. Restart the server. service dirsrv start instance Table 10.
Deleting Indexes 2. In a text editor, open the dse.ldif file. 3. Locate the oid=2.16.840.1.113730.3.4.9 entry. dn: oid=2.16.840.1.113730.3.4.9,cn=features,cn=config objectClass: top objectClass: directoryServerFeature oid: 2.16.840.1.113730.3.4.9 cn: VLV Request Control aci: (targetattr != "aci")(version 3.0; acl "VLV Request Control"; allow( read, search, compare, proxy ) userdn = "ldap:///all" ;) creatorsName: cn=server,cn=plugins,cn=config modifiersName: cn=server,cn=plugins,cn=config ... 4.
Chapter 10. Managing Indexes the cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config entry. Also, be cautious when deleting default indexes since this can also affect how Directory Server works. 3.1. Deleting Indexes from the Server Console The Directory Server Console allows you to delete any indexes you have created, indexes used by other server applications such as a messaging or web server, and default indexes. NOTE You cannot delete system indexes.
Deleting Indexes from the Command-Line 1. Delete an entire index entry or delete unwanted index types from an existing index entry using the ldapdelete command-line utility (Section 3.2.1, “Deleting an Index Entry”). 2. Generate the new set of indexes to be maintained by the server using the db2index.pl Perl script (Section 3.2.2, “Running the db2index.pl Script”). 3.2.1.
Chapter 10. Managing Indexes Option Description be a DN recognized by the Directory Server, and it must also have the authority to modify the entries. -w Specifies the password associated with the distinguished name specified in the -D option. -h Specifies the name of the host on which the server is running. -p Specifies the port number that the server uses. Table 10.5.
Deleting Browsing Indexes from the Server Option Description -n Specifies the name of the database into which you are importing the data. Table 10.6. db2index Options 3.3. Deleting Browsing Indexes from the Server Console To delete a browsing index through the Directory Server Console, do the following: 1. Select the Directory tab. 2. Select the entry from which to delete the index in the navigation tree, and select Delete Browsing Index from the Object menu.
Chapter 10. Managing Indexes For example, there is a browsing index for accelerating ldapsearch operations on the entry ou=People,dc=example,dc=com. It held in the Example1 database where the search base is ou=People,dc=example,dc=com, the search filter is (|(objectclass=*)(objectclass=ldapsubentry)), the scope is 1, and the sorting order for the returned attributes is cn, givenName, o, ou, and sn. 1. Run ldapdelete.
Console Option Description -p Specifies the port number that the server uses. After deleting the two browsing index entries, the browsing index will no longer be maintained by the Example1 database. 3.4.2. Running the vlvindex Script After deleting browsing indexing entries or unwanted attribute types from existing browsing indexing entries, run the vlvindex script to generate the new set of browsing indexes to be maintained by the Directory Server.
Chapter 10. Managing Indexes 4.1. Indexing Performance While achieving extremely high read performance, in previous versions of Directory Server, write performance was limited by the number of bytes per second that could be written into the storage manager's transaction log file. Large log files were generated for each LDAP write operation; in fact, log file verbosity could easily be 100 times the corresponding number of bytes changed in the Directory Server.
Backwards Compatibility and Migration the server. In previous versions of Directory Server, this limit was called the All IDs Threshold. Because maintaining large ID lists in memory can affect performance, the All IDs Threshold set a limit on how large a single entry ID list could get. When a list hit a certain pre-determined size, the search would treat it as if the index contained the entire directory. The difficulty in setting the All IDs Threshold hurt performance.
Chapter 10. Managing Indexes 4.3. Backwards Compatibility and Migration While current versions of Directory Server can support the old database design, only the new design is supported for this and later releases of Directory Server. Upon startup, the server will read the database version from the DBVERSION file, which contains the text Netscape-ldbm/6.2 (old database version), Netscape-ldbm/7.1 (new database format), or bdb/4.2/libback-ldbm (new database format).
Attribute Name Quick Reference Table Attribute Primary Name Attribute Alias ttl timeToLive dc domainComponent authorCn documentAuthorCommonName authorSn documentAuthorSurname drink favoriteDrink Table 10.7.
392
Chapter 11. Managing SSL To provide secure communications over the network, Red Hat Directory Server includes the LDAPS communications protocol. LDAPS is the standard LDAP protocol, running over Transport Layer Security (TLS, formerly Secure Sockets Layer or SSL). Directory Server also allows spontaneous secure connections over otherwise-insecure LDAP ports, using the Start TLS LDAP extended operation. This chapter describes how to use TLS/SSL with Directory Server. 1.
Chapter 11. Managing SSL 1. Obtain and install a certificate for the Directory Server, and configure the Directory Server to trust the certification authority's (CA's) certificate. For information, see Section 2, “Obtaining and Installing Server Certificates”. 2. Turn on TLS/SSL in the directory. For information, refer to Section 4, “Starting the Server with TLS/SSL Enabled”. 3. Configure the Administration Server connect to an SSL-enabled Directory Server. 4.
Obtaining and Installing Server Certificates For information on the command-line options available, see the Directory Server Configuration, Command, and File Reference. 1.2.1. Troubleshooting Start TLS With the -ZZ option, the following errors could occur: • If there is no certificate database, the operation fails. See Section 2, “Obtaining and Installing Server Certificates” for information on using certificates. • If the server does not support Start TLS, the connection proceeds in clear text.
Chapter 11. Managing SSL 4. Set the Directory Server to trust the certificate authority. 5. Confirm that the certificates are installed. Two wizards automate the process of creating a certificate database and of installing the key-pair. The Certificate Request Wizard in the Directory Server Console can generate a certificate request and send it to a certificate authority. The Certificate Install Wizard in the Directory Server Console can then install the server certificate and the CA certificate. 2.1.
Step 1: Generate a Certificate Request • Server Name. Enter the fully qualified hostname of the Directory Server as it is used in DNS and reverse DNS lookups; for example, dir.example.com. The server name is critical for client-side validation to work, which prevents man-in-the-middle attacks. • Organization. Enter the legal name of the company or institution. Most CAs require this information to be verified with legal documents such as a copy of a business license. • Organizational Unit. Optional.
Chapter 11. Managing SSL The Next button is grayed out until a password is supplied. 6. The Request Submission dialog box provides two ways to submit a request: directly to the CA (if there is one internally) or manually. To submit the request manually, select Copy to Clipboard or Save to File to save the certificate request which will be submitted to the CA.
Step 2: Send the Certificate Request 7. Click Done to dismiss the Certificate Request Wizard. After generating the certificate request, send it to the CA. 2.2. Step 2: Send the Certificate Request After the certificate request is generated, send it to a certificate authority (CA); the CA will generate return a server certificate. 1. Most certificate requests are emailed to the CA, so open a new message. 2.
Chapter 11. Managing SSL 3. Send the email message to the CA. After emailing the certificate request, wait for the CA to respond with the server certificate. Response time for requests varies. For example, if the CA is internal to the company, it may only take a day or two to respond to the request. If the selected CA is a third-party, it could take several weeks to respond to the request. After receiving the certificate, install it in the Directory Server's certificate database.
Step 4: Trust the Certificate Authority text file, and paste it in this field. 4. Check that the certificate information displayed is correct, and click Next. 5. Give a name to the certificate, and click Next. 6. Provide the password that protects the private key. This password is the same as the one provided in step 5 in Section 2.1, “Step 1: Generate a Certificate Request”. After installing the server certificate, configure the Directory Server to trust the CA which issued the server's certificate. 2.
Chapter 11. Managing SSL 2.5. Step 5: Confirm That The New Certificates Are Installed 1. In the Directory Server Console, select the Tasks tab, and click Manage Certificates. 2. Select the Server Certs tab. A list of all the installed certificates for the server opens. 3. Scroll through the list. The certificates installed previously should be listed. It is now possible to set up the Directory Server to run in TLS/SSL.
Creating Directory Server Certificates tar -cf /tmp/db-backup.tar * 3. Create a password file for the security token password. vi /tmp/pwdfile secretpw This password locks the server's private key in the key database and is used when the keys and certificates are first created. The password in this file is also the default password to encrypt PK12 files used by pk12util.
Chapter 11. Managing SSL "cn=ldap.example.com"; it is beneficial to have a more descriptive name to help with server identification, such as "cn=ldap.example.com, ou=DS1". The FQDN must be available for DNS and reverse DNS lookups to Directory Server clients because certificate validation may fail if the clients cannot properly resolve the FQDN, and some clients refuse to connect if a server certificate does not have its FQDN in the subject. Additionally, using the format cn=hostname.
through the Command Line The -w argument is the password used to encrypt the .p12 file for transport. The -k argument specifies the password for the key database containing the server certificate being exported to .p12. 10.If the Directory Server will run with TLS/SSL enabled, then create a password file (pin.txt) for the server to use so it will not prompt you for a password every time it restarts. Creating the password file is described in Section 4.3, “Creating a Password File for the Directory Server”.
Chapter 11. Managing SSL the key database. This is the same password used when the server certificate and key were imported into the database. Restarting the Directory Server without the password prompt is possible by using use a hardware crypto device or creating a PIN file (Section 4.3, “Creating a Password File for the Directory Server”).
Enabling TLS/SSL Only in the Directory 8. Set the preferences for client authentication. • Do not allow client authentication. With this option, the server ignores the client's certificate. This does not mean that the bind will fail. • Allow client authentication. This is the default setting. With this option, authentication is performed on the client's request. For more information about certificate-based authentication, see Section 6, “Using Certificate-Based Authentication”.
Chapter 11. Managing SSL 2 service dirsrv restart instance When the server restarts, it prompts for the PIN or password to unlock the key database. This is the same password used when the server certificate and key were imported into the database. To restart the Directory Server without the password prompt, create a PIN file or use a hardware crypto device. See Section 4.3, “Creating a Password File for the Directory Server” for information on how to create a PIN file. 4.2.
Server 8. Click Cipher Settings. The Cipher Preference dialog box opens. By default, all ciphers are selected. 9. Set the preferences for client authentication. • Do not allow client authentication. With this option, the server ignores the client's certificate. This does not mean that the bind will fail. • Allow client authentication. This is the default setting. With this option, authentication is performed on the client's request.
Chapter 11. Managing SSL 12.In the Administration Server Console, select the Configuration tab. Select the Encryption tab, check the Enable SSL checkbox, and fill in the appropriate certificate information. 13.In the Configuration DS tab, change the port number to the new Directory Server secure port information. See Section 5, “Changing Directory Server Port Numbers” for more information. Do this even if the default port of 636 is used. Check the Secure Connection checkbox. 14.
Creating a Password File for the CAUTION This password is stored in clear text within the password file, so its usage represents a significant security risk. Do not use a password file if the server is running in an unsecured environment. The password file must be in the same directory where the other key and certificate databases for Directory Server are stored. This is usually the main configuration directory, /etc/dirsrv/slapd-instance_name. The file should be named pin.txt.
Chapter 11. Managing SSL TIP To find out what the Administration Server user ID is, run grep in the Administration Server configuration directory: cd /etc/dirsrv/admin-serv grep \^User console.conf 3. In the /etc/dirsrv/admin-serv directory, edit the nss.conf file to point to the location of the new password file. # Pass Phrase Dialog: # Configure the pass phrase gathering process. # The filtering dialog program (`builtin' is a internal # terminal dialog) has to provide the pass phrase on stdout.
Administration Server Console. • Key exchange. The key exchange algorithm. DHE stands for Diffie-Hellman; DSS stands for Digital Signature Standard. The 1024 bit ciphers are lower strength ciphers formerly used for export control. • Encryption Algorithm. AES stands for the American Encryption Standard. DES stands for Data Encryption Standard. • Symmetric Key Bit Size. The size in bits of the key used for the actual transport data encryption. • Message Authentication. SHA stands for Secure Hash Algorithm.
Chapter 11.
Using Certificate-Based Authentication Unless there is a security reason not to use a specific cipher, select all of the ciphers, except for none,MD5. 6. In the Encryption tab, click Save. CAUTION Avoid selecting the none,MD5 cipher because the server will use this option if no other ciphers are available on the client, instead of refusing the connection. The none,MD5 cipher is not secure because encryption does not occur. 6.
Chapter 11. Managing SSL nsCertFile and nsKeyFile to give the locations for the key and certificate databases. 6.1. Setting up Certificate-Based Authentication To set up certificate-based authentication, do the following: 1. Create a certificate database for the client and the server or for both servers involved in replication. In the Directory Server, the certificate database creation automatically takes place when a certificate is installed.
Configuring LDAP Clients to Use SSL 1. Stop the Directory Server. 2 service dirsrv stop instance 2. Modify the cn=encryption,cn=config entry by changing the value of the nsSSLClientAuth attribute from required to allowed. For information on modifying entries from the command-line, see Section 2.4, “Adding and Modifying Entries Using ldapmodify”. 3. Start the Directory Server. service dirsrv start instance Now start Red Hat Console. 7.
Chapter 11. Managing SSL client certificate resembles the following: -----BEGIN CERTIFICATE----MIICMjCCAZugAwIBAgICCEEwDQYJKoZIhvcNAQEFBQAwfDELMAkGA1UEBh MCVVMxIzAhBgNVBAoTGlBhbG9va2FWaWxsZSBXaWRnZXRzLCBJbmMuMR0w GwYDVQQLExRXaWRnZXQgTWFrZXJzICdSJyBVczEpMCcGA1UEAxMgVGVzdC BUZXN0IFRlc3QgVGVzdCBUZXN0IFRlc3QgQ0EwHhcNOTgwMzEyMDIzMzU3 WhcNOTgwMzI2MDIzMzU3WjBPMQswCQYDVQQGEwJVUzEoMCYGA1UEChMfTm V0c2NhcGUgRGlyZWN0b3 ------END CERTIFICATE----- 3.
Configuring LDAP Clients to Use SSL c. Click Set Value. A file selector opens. Use it to select the binary file created in Section 7, “Configuring LDAP Clients to Use SSL”. For information on using the Directory Server Console to edit entries, refer to Section 1.3, “Modifying Directory Entries”. Now TLS/SSL and client authentication can be used with the LDAP clients.
420
Chapter 12. Managing SASL Red Hat Directory Server supports LDAP client authentication through the Simple Authentication and Security Layer (SASL), an alternative to TLS/SSL and a native way for some applications to share information securely. Directory Server supports SASL authentication using the DIGEST-MD5 and GSS-API mechanisms, allowing Kerberos tickets to authenticate sessions and encrypt data. This chapter describes how to use SASL with Directory Server.
Chapter 12. Managing SASL NOTE GSS-API and, thus, Kerberos are only supported on platforms that have GSS-API support. To use GSS-API, it may be necessary to install the Kerberos client libraries; any required Kerberos libraries will be available through the operating system vendor. CRAM-MD5, DIGEST-MD5, and GSS-API are shared secret mechanisms. The server challenges the client attempting to bind with a secret, such as a password, that depends on the mechanism.
SASL Identity Mapping dn: cn=sasl,cn=config objectClass: top objectClass: nsContainer cn: sasl SASL identity mapping entries are children of this entry: dn: cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsContainer cn: mapping Mapping entries contain three attributes, nsSaslMapRegexString, nsSaslMapBaseDNTemplate, and nsSaslMapFilterTemplate. The nsSaslMapping object class sets these identity mapping parameters.
Chapter 12. Managing SASL This will match any user ID and map to the result of the the subtree search with base ou=People,dc=example,dc=com and filter cn=userId. The Directory Server has pre-defined SASL mapping rules to handle some of the most common cases: • Kerberos UID Mapping. This mapping matches a Kerberos principal using a two part realm, such as user@example.com. The realm is then used to define the search base, and the authid defines the filter.
Configuring SASL Identity Mapping from the 3. To add a new SASL identity mapping, select the Add button, and fill in the required values. • Name. This field sets the unique name of the SASL mapping. • Regular expression. This field sets the regular expression used to match the DN components, such as \(.*\). This field corresponds to the nsSaslMapRegexString value in the SASL mapping LDIF entry. • Search base DN.
Chapter 12. Managing SASL ou=People,dc=example,dc=com. This field corresponds to the nsSaslMapBaseDNTemplate value in the SASL mapping LDIF entry. • Search filter. This field gives the search filter for the components to replace, such as (objectclass=*). This field corresponds to the nsSaslMapFilterTemplate value in the SASL mapping LDIF entry. To edit a SASL identity mapping, highlight that identity in the SASL Mapping tab, and click Modify. Change any values, and save.
Console 5.1. Realms A realm is a set of users and the authentication methods for those users to access the realm. A realm resembles a fully-qualified domain name and can be distributed across either a single server or a single domain across multiple machines. A single server instance can also support multiple realms.
Chapter 12. Managing SASL NOTE On Red Hat Enterprise Linux, the client-side Kerberos configuration is in the /etc/krb5.conf. On Solaris, the client-side Kerberos configuration is in the /etc/krb5/krb5.conf. The HP server and client are separate packages with their own configuration. The server stores config files in /opt/krb5. The client is classic MIT and uses /etc/krb5.conf. Both the server and client must be configured to have a working Kerberos system.
Configuring SASL Authentication at admin_server =adminserver.company.example.com:749 default_domain = company.example.com } [appdefaults] pam = { debug = true ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false } [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log admin_server = FILE:/var/log/kadmind.log 5.4.
Chapter 12. Managing SASL For more information on the keytab file, see Section 5.2, “Configuring the KDC Server”.
Chapter 13. Monitoring Server and Database Activity This chapter describes monitoring database and Red Hat Directory Server logs. For information on using SNMP to monitor the Directory Server, see Chapter 14, Monitoring Directory Server Using SNMP. 1. Viewing and Configuring Log Files Directory Server provides three types of logs to help better manage the directory and tune performance.
Chapter 13. Monitoring Server and Database Activity The access mode or file permissions with which log files are to be created. The default value is 600. The valid values are any combination of 000 to 777, as they mirror numbered or absolute UNIX file permissions.
Defining a Log File Deletion Policy Red Hat-Directory/8.0 B2007.188.1157 myhost.example.com:389 (/usr/lib/dirsrv/slapd-example) 1.2. Defining a Log File Deletion Policy For the directory to automatically delete old archived logs, define a log file deletion policy from the Directory Server Console. NOTE The log deletion policy only makes sense if there is already a defined log file rotation policy. Log file deletion will not work if there is just one log file.
Chapter 13. Monitoring Server and Database Activity display to refresh automatically every ten seconds. NOTE Continuous log refresh does not work well with log files over 10 megabytes. • To view an archived access log, select it from the Select Log pull-down menu. • To display a different number of messages, enter the number to view in the Lines to show text box, and then click Refresh.
Error Log For information on these parameters, see Section 1.2, “Defining a Log File Deletion Policy”. 7. Click Save. The logconv.pl Perl script reports the statistical information retrieved from the access log. For more information on logconv.pl, refer to the Directory Server Configuration, Command, and File Reference. 1.4. Error Log The error log contains detailed messages of errors and events the directory experiences during normal operations.
Chapter 13. Monitoring Server and Database Activity containing text box, and click Refresh. 1.4.2. Configuring the Error Log There are several configuration settings for the error log, including where the directory stores the log and what information the directory includes in the log. To configure the error log, do the following: 1. In the Directory Server Console, select the Configuration tab. 2. In the navigation tree, expand the Logs folder, and select the Error Log icon.
Audit Log 1.5. Audit Log The audit log contains detailed information about changes made to each database as well as to server configuration. 1.5.1. Viewing the Audit Log Before the audit log can be viewed, audit logging must be enabled for the directory, so the audit log will not be kept. Section 1.5.2, “Configuring the Audit Log” has more information. To view the audit log, do the following: 1. In the Directory Server Console, select the Status tab. 2.
Chapter 13. Monitoring Server and Database Activity 4. Enter the full path and filename for the directory to use for the audit log in the field provided. The default path is /var/log/dirsrv/slapd-instance_name/audit. 5. Set the maximum number of logs, log size, and time period when the file is archived. For information on these parameters, see Section 1.1, “Defining a Log File Rotation Policy”. 6.
Monitoring the Server from the Directory 3.1. Monitoring the Server from the Directory Server Console To monitor the server's activities using Directory Server Console, do the following: 1. In the Directory Server Console, select the Status tab. 2. In the navigation tree, select Performance Counters. The Status tab in the right pane displays current information about server activity. If the server is currently not running, this tab will not provide performance monitoring information. 3.
Chapter 13. Monitoring Server and Database Activity Field Description made to the directory. This number starts at one and increments by one for each change made to the database. Startup Time on Server The date and time the server was started. Current Time on Server The current date and time on the server. Table 13.1. General Information (Server) Resource Usage Since Startup Average Per Minute Connections The total number of connections to this server since server startup.
Server Console Resource Current Total connection can account for multiple operations, and therefore multiple threads. Remaining Available Connections The total number of remaining connections that the server can concurrently open. This number is based on the number of currently open connections and the total number of concurrent connections that the server is allowed to open.
Chapter 13. Monitoring Server and Database Activity Table Header Description Read/Write Indicates whether the server is currently blocked for read or write access to the client. There are two possible values: Not blocked means that the server is idle,actively sending data to the client, or actively reading data from the client. Blocked means that the server is trying to send data to the client or read data from the client but cannot. The probable cause is a slow network or client. Table 13.4.
Monitoring the Directory Server from the Table 13.5. Global Database Cache Information 3.2. Monitoring the Directory Server from the Command Line The Directory Server's current activities can be monitored using LDAP tools such as 3 ldapsearch , with the following characteristics: • Search with the attribute filter objectClass=*. • Use the search base cn=monitor; the monitoring attributes for the server are found in the cn=monitor entry. • Use the search scope base. For example: ldapsearch -h directory.
Chapter 13. Monitoring Server and Database Activity Attribute Description opentime — The time this connection was opened. opsinitiated — The number of operations initiated by this connection. opscompleted — The number of operations completed. binddn — The distinguished name used by this connection to connect to the directory. rw — The field shown if the connection is blocked for read or write. By default, this information is available to Directory Manager.
Command Line Attribute Description Time (GMT) in UTC format. nbackends Identifies the number of back ends (databases) the server services. backendmonitordn Identifies the DN of each directory database. Table 13.6. Server Monitoring Attributes 4. Monitoring Database Activity The database's current activities can be monitored through Directory Server Console or from the command line. 4.1.
Chapter 13. Monitoring Server and Database Activity Field Description used as a search base to obtain these results using the ldapsearch command-line utility. 3 Table 13.7. General Information (Database) Performance Metric Current Total Read-Only Status Shows whether the database is currently in read-only mode. The database is in read-only mode when the nsslapd-readonly attribute is set to on. Entry Cache Hits The total number of successful entry cache lookups.
Monitoring Database Activity from the Performance Metric Current Total “Tuning Database Performance” for information on changing this value using the Directory Server Console. Current Entry Cache Size (in Entries) The total number of directory entries currently present in the entry cache. Maximum Entry Cache Size (in Entries) The maximum number of directory entries that can be maintained in the entry cache. This value is managed by the Maximum Entries in Cache setting.
Chapter 13. Monitoring Server and Database Activity Performance Metric Current Total Pages Written Out The number of pages written from the cache back to disk. A database page is written to disk whenever a read-write page has been modified and then subsequently deleted from the cache. Pages are deleted from the database cache when the cache is full and a directory operation requires a database page that is not currently stored in cache.
Directory Server Console • Search with the attribute filter objectClass=*. • Use the search base cn=monitor,cn=database_instance,cn=ldbm database, cn=plugins, cn=config. database_instance is the name of the database to monitor. • Use the search scope base. For example: ldapsearch -h directory.example.
Chapter 13. Monitoring Server and Database Activity Attribute Description increases, and directory search performance drops. To improve this ratio, increase the number of entries that the directory maintains in the entry cache by increasing the value of the Maximum Entries in Cache attribute. See Section 2, “Tuning Database Performance” for information on changing this value using the Directory Server Console.
Monitoring Database Link Activity Attribute Description lower the number of page evicts the better. dbfilename-number The name of the file. number provides a sequential integer identifier (starting at 0) for the file. All associated statistics for the file are given this same numerical identifier. dbfilecachehit-number The number of times that a search result resulted in a cache hit on this specific file.
Chapter 13. Monitoring Server and Database Activity Attribute Name Description nsAddCount The number of add operations received. nsDeleteCount The number of delete operations received. nsModifyCount The number of modify operations received. nsRenameCount The number of rename operations received. nsSearchBaseCount The number of base-level searches received. nsSearchOneLevelCount The number of one-level searches received. nsSearchSubtreeCount The number of subtree searches received.
Chapter 14. Monitoring Directory Server Using SNMP The server and database activity monitoring log setup described in Chapter 13, Monitoring Server and Database Activity is specific to Directory Server. You can also monitor your Directory Server using Simple Network Management Protocol (SNMP), which is a management protocol used for monitoring network activity which can be used to monitor a wide range of devices in real time. Directory Server can be monitored with SNMP through an AgentX subagent.
Chapter 14. Monitoring Directory Server Using SNMP managed objects, have values and titles that are reported to the NMS as necessary. Communication between an NMS and a managed device takes place either by the NMS sending updates or requesting information or by the managed object sending a notice or warning, called a trap, when a server shuts down or starts up. 2. Configuring the Master Agent To use the subagent, you must have a master agent that supports AgentX.
Starting the Subagent agentx-master localhost:705 3.1.2. agent-logdir The agent-logdir setting specifies the directory where the subagent will write its logfile. For example: agent-logdir /var/log If this parameter is not specified, the agent will write its logfile to the same location as your subagent configuration file. The logfile will be named ldap-agent.log. Make sure that the user as whom your subagent is running has write permission to this directory. 3.1.3.
Chapter 14. Monitoring Directory Server Using SNMP NOTE The Directory Server does not have to be started for the subagent to be started. To stop your subagent, you must use the kill command against its process ID. Your subagent will print its process ID in its logfile, or you can run ps -ef | grep ldap-agent to find the process ID. 3.3. Testing the Subagent To test your subagent, use any SNMP client tools to query the master agent.
Configuring the Directory Server for SNMP Table is described in Section 6.3, “Entity Table”. This means that the action the master agent takes when it receives a trap is flexible, such as sending an email to an email address defined in the dsEntityContact variable for one instance while sending a notification to a a pager number in the dsEntityContact variable for another instance. There are two traps supported by the subagent: • DirectoryServerDown.
Chapter 14. Monitoring Directory Server Using SNMP directory like all other managed devices on your network. For more information on using the MIB, refer to Section 3.3, “Testing the Subagent”. The client tools need to load the Directory Server MIB to use the variable names listed in the following sections. You can see administrative information about your directory and monitor the server in real-time using the directory MIB.
Entries Table Managed Object Description this directory since application start. The value of this object will always be 0 because LDAP implements read operations indirectly via the search operation. dsCompareOps The number of compare operations serviced by this directory since server startup. dsAddEntryOps The number of add operations serviced by this directory since server startup. dsRemoveEntryOps The number of delete operations serviced by this directory since server startup.
Chapter 14. Monitoring Directory Server Using SNMP 6.2. Entries Table The Entries Table provides information about the contents of the directory entries. Table 14.2, “Entries Table: Managed Objects and Descriptions” describes the managed objects stored in the Entries Table in the redhat-directory.mib file. Managed Object Description dsMasterEntries The number of directory entries for which this directory contains the master entry.
Interaction Table Managed Object Description dsEntityContact The name and contact information for the person responsible for the Directory Server instance. dsEntityName The name of the Directory Server instance. Table 14.3. Entity Table: Managed Objects and Descriptions 6.4. Interaction Table NOTE The Interaction Table is not supported by the subagent. The subagent can query the table, but it will not ever be updated with valid data. Table 14.
Chapter 14. Monitoring Directory Server Using SNMP Managed Object Description management subsystem was initialized, this object will contain a value of zero. dsTimeOfLastSuccess The value of sysUpTime when the last attempt made to contact this Directory Server was successful. This entry will have a value of zero if there have been no successful attempts or if the last successful attempt was made before the network management subsystem was initialized.
Chapter 15. Tuning Directory Server Performance This chapter describes the tools provided with Red Hat Directory Server to help optimize performance. It also provides tips to improve the performance of the directory. 1.
Chapter 15. Tuning Directory Server Performance in the Idle Timeout text box. To keep from setting a limit, type zero (0) in this text box. 5. Set the maximum number of file descriptors available to the Directory Server in the Max Number of File Descriptors text box. For more information on this parameter, see the Directory Server Configuration, Command, and File Reference. For a better understanding of how these parameters impact the server's search performance, see Section 1, “About Indexes”. 2.
Optimizing Search Performance values set on these attributes does not help directory performance. In fact, changing these attributes may harm overall performance. The following attributes can be tuned: • The attributes of the database that manages all other database instances. The Directory Server Console only shows the databases that contain the directory data and the NetscapeRoot database. However, the server uses another database to manage these.
Chapter 15. Tuning Directory Server Performance specified here. To configure the attributes of each database that stores the directory data: 5. In the Directory Server Console, select the Configuration tab; then, in the navigation tree, expand the Data Icon. Expand the suffix of the database to tune, and highlight the database. The tabs displayed in the right pane control parameter settings for this database. 1. Select the Database Settings tab in the right pane. 2.
Changing the Database Checkpoint Interval themselves. Because the purpose of the transaction log is to aid in the recovery of a directory database that was shut down abnormally, it is a good idea to store the database transaction log on a different disk from the one containing the directory database. Storing the database transaction log on a separate physical disk may also improve directory performance. To change the location of the database transaction logfile, use the following procedure: 1.
Chapter 15. Tuning Directory Server Performance 2.5. Disabling Durable Transactions Durable transaction logging means that the temporary database transaction log is, in fact, physically written to disk. When durable transaction logging is disabled, every directory database operation is written to the database transaction log file but may not be physically written to disk immediately.
Avoid Creating Entries Under the cn=config This section covers some common performance-related tips and concepts to remember. 3.1. Avoid Creating Entries Under the cn=config Entry in the dse.ldif File The cn=config entry in the simple, flat dse.ldif configuration file is not stored in the same highly scalable database as regular entries. As a result, if many entries, particularly entries that are likely to be updated frequently, are stored under cn=config, performance will probably suffer.
470
Chapter 16. Administering Directory Server Plug-ins Plug-ins extend the functionality of the server. Red Hat Directory Server ships with several plug-ins to help manage the directory. This chapter contains general information on the types of plug-ins available and how to enable or disable them. 1.
Chapter 16. Administering Directory Server Plug-ins Plug-in Information Description Configurable Options on | off Default Setting on Configurable Arguments None Dependencies None Performance Related Information Access control incurs a minimal performance hit. Leave this plug-in enabled since it is the primary means of access control for the server. Further Information See Chapter 6, Managing Access Control. Table 16.2. Details of ACI Plug-in 1.3.
Boolean Syntax Plug-in Plug-in Information Description Default Setting on Configurable Arguments None Dependencies None Performance Related Information Do not modify the configuration of this plug-in. Leave this plug-in running at all times. Further Information Table 16.4. Details of Binary Syntax Plug-in 1.5.
Chapter 16. Administering Directory Server Plug-ins Plug-in Information Description Performance Related Information Do not modify the configuration of this plug-in. Leave this plug-in running at all times. Further Information Table 16.6. Details of Case Exact String Syntax Plug-in 1.7.
Class of Service Plug-in Plug-in Information Description Further Information A chaining database is also known as a database link. Database links are described in Section 3, “Creating and Maintaining Database Links”. Table 16.8. Details of Cloning Database Plug-in 1.9.
Chapter 16. Administering Directory Server Plug-ins Plug-in Information Description Further Information Table 16.10. Details of Country String Plug-in 1.11.
Integer Syntax Plug-in Plug-in Information Description four digit year two digit month (for example, 01 for January) two digit day, two digit hour two digit minute two digit second decimal part of a second (optional) a time zone indication Red Hat strongly recommends using the Z time zone indication, which stands for Greenwich Mean Time. Table 16.12. Details of Generalized Time Syntax Plug-in 1.13.
Chapter 16. Administering Directory Server Plug-ins Plug-in Information Description Default Setting on Configurable Arguments The Internationalization Plug-in has one argument which must not be modified, which specifies the location of the /etc/dirsrv/config/slapd-collations.conf file. This file stores the collation orders and locales used by the Internationalization Plug-in. Dependencies None Performance Related Information Do not modify the configuration of this plug-in.
Multi-Master Replication Plug-in Plug-in Information Description Plug-in Name Legacy Replication Plug-in Configuration Entry DN cn=Legacy Replication plug-in,cn=plugins,cn=config Description Enables this version of Directory Server to be a consumer of a 4.x supplier Configurable Options on | off Default Setting off Configurable Arguments None. This plug-in can be disabled if the server is not (and never will be) a consumer of a 4.x server.
Chapter 16. Administering Directory Server Plug-ins Plug-in Information Description Plug-in Name Octet String Syntax Configuration Entry DN cn=Octet String Syntax,cn=plugins,cn=config Description Syntax for handling octet strings Configurable Options on | off Default Setting on Configurable Arguments None Dependencies None Performance Related Information Do not modify the configuration of this plug-in. Leave this plug-in running at all times. Further Information Table 16.18.
NS-MTA-MD5 Password Storage Plug-in Plug-in Information Description Schemes,cn=plugins, cn=config Description CRYPT password storage scheme used for password encryption Configurable Options on | off Default Setting on Configurable Arguments None Dependencies None Performance Related Information Do not modify the configuration of this plug-in. Leave this plug-in running at all times. Further Information See Section 1, “Managing the Password Policy”. Table 16.20.
Chapter 16. Administering Directory Server Plug-ins 1.22.
Postal Address String Syntax Plug-in Plug-in Information Description Schemes,cn=plugins,cn=config Description SSHA password storage scheme for password encryption Configurable Options on | off Default Setting on Configurable Arguments None Dependencies None Performance Related Information Do not modify the configuration of this plug-in. Leave this plug-in running at all times. Further Information See Section 1, “Managing the Password Policy”. Table 16.23.
Chapter 16. Administering Directory Server Plug-ins Plug-in Information Description Description Enables pass-through authentication, the mechanism which allows one directory to consult another to authenticate bind requests. This plug-in is not listed in the Directory Server Console if the same server is used for the user directory and configuration directory.
Retro Changelog Plug-in Plug-in Information Description -1= no check for referential integrity 0= check for referential integrity is performed immediately Positive integer= request for referential integrity is queued and processed at a later stage. This positive integer serves as a wake-up call for the thread to process the request at intervals corresponding to the integer (number of seconds) specified. • Log file for storing the change; for example /var/log/dirsrv/slapd-instance_name/referint.
Chapter 16. Administering Directory Server Plug-ins Plug-in Information Description occurring in the Directory Server. The retro changelog offers the same functionality as the changelog in the 4.x versions of Directory Server. This plug-in exposes the cn=changelog suffix to clients, so that clients can use this suffix with or without persistent search for simple sync applications.
State Change Plug-in Plug-in Information Description Plug-in Name Space Insensitive String Syntax Configuration Entry DN cn=Space Insensitive String Syntax,cn=plugins,cn=config Description Syntax for handling space-insensitive values. Configurable Options on | off Default Setting on Configurable Arguments None Dependencies None Performance Related Information Do not modify the configuration of this plug-in. Leave this plug-in running at all times.
Chapter 16. Administering Directory Server Plug-ins Table 16.30. Details of State Change Plug-in 1.31. Telephone Syntax Plug-in Plug-in Information Description Plug-in Name Telephone Syntax Configuration Entry DN cn=Telephone Syntax,cn=plugins,cn=config Description Syntax for handling telephone numbers Configurable Options on | off Default Setting on Configurable Arguments None Dependencies None Performance Related Information Do not modify the configuration of this plug-in.
URI Plug-in Plug-in Information Description entry containing the ObjectClass as defined by the MarkerObjectClass attribute. Dependencies N/A Performance Related Information This plug-in may slow down Directory Server performance. In a multi-master replication environment, the UID Uniqueness Plug-in will not work at all and should therefore not be enabled.
Chapter 16. Administering Directory Server Plug-ins Plug-in Information Description Configurable Arguments None Dependencies None Performance Related Information Do not modify the configuration of this plug-in. Leave this plug-in running at all times. Further Information Table 16.33. Details of URI Plug-in 2. Enabling and Disabling Plug-ins To enable and disable plug-ins over LDAP using the Directory Server Console, do the following: 1.
Chapter 17. Using the Pass-through Authentication Plug-in Pass-through authentication (PTA) is a mechanism which allows one Red Hat Directory Server instance to consult another to authenticate bind requests. Pass-through authentication is implement through the PTA Plug-in; when enabled, the plug-in lets a Directory Server instance accept simple bind operations (password-based) for entries not stored in its local database.
Chapter 17. Using the Pass-through Authentication Plug-in userdir.example.com. 3. When the user directory is set up on machine B, the setup script prompts for the LDAP URL of the configuration directory on machine A. 4. The setup program enables the PTA Plug-in and configures it to use the configuration directory LDAP URL. This entry contains the LDAP URL for the configuration directory. For example: dn: cn=Pass Through Authentication,cn=plugins, ...
PTA Plug-in Syntax NOTE The LDAP URL (ldap|ldaps://authDS/subtree) must be separated from the optional parameters (maxconns, maxops, timeout, ldver, connlifetime) by a single space. If any of the optional parameters are defined, all of them must be defined, even if only the default values are used. Several authenticating directories or subtrees can be specified by incrementing the nsslapd-pluginarg attribute suffix by one each time, as in Section 4.2, “Specifying Multiple Authenticating Directory Servers”.
Chapter 17. Using the Pass-through Authentication Plug-in Variable Definition subtree The pass-through subtree. The PTA Directory Server passes through bind requests to the authenticating Directory Server from all clients whose DN is in this subtree. See Section 3.4, “Specifying the Pass-through Subtree” for more information. This subtree must not exist on this server. To pass the bind requests for o=NetscapeRoot to the configuration directory, the subtree o=NetscapeRoot must not exist on the server.
Configuring the PTA Plug-in Variable Definition has expired, the server closes the connection and opens a new connection to the authenticating directory. The server will not close the connection unless a bind request is initiated and the directory determines the connection lifetime has been exceeded. If this option is not specified, or if only one host is listed, no connection lifetime will be enforced. If two or more hosts are listed, the default is 300 seconds (five minutes). See Section 3.
Chapter 17. Using the Pass-through Authentication Plug-in • Section 3.3, “Specifying the Authenticating Directory Server” • Section 3.4, “Specifying the Pass-through Subtree” • Section 3.5, “Configuring the Optional Parameters” 3.1. Turning the Plug-in On or Off To turn the PTA Plug-in on from the command line, do the following: 1.
Specifying the Pass-through Subtree ldapmodify -p 389 -D "cn=Directory Manager" -w password -h example dn: cn=Pass Through Authentication,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginarg0 nsslapd-pluginarg0: ldap://dirserver.example.com/o=NetscapeRoot Optionally, include the port number. If the port number is not given, the PTA Directory Server attempts to connect using either the standard port (389) for ldap:// or the secure port (636) for ldaps://.
Chapter 17. Using the Pass-through Authentication Plug-in For information on the variable components in this syntax, see Table 17.1, “PTA Plug-in Parameters”. 2. Restart the server. 1 service dirsrv restart instance_name 3.5. Configuring the Optional Parameters Additional parameters the control the PTA connection can be set with the LDAP URL.
PTA Plug-in Syntax Examples nsslapd-pluginarg0: ldap://dirserver.example.com/o=NetscapeRoot 3,5,300,3,300 (In this example, each of the optional parameters is set to its default value.) Make sure there is a space between the subtree parameter, and the optional parameters. NOTE Although these parameters are optional, if any one of them is defined, they all must be defined, even if they use the default values. 2. Restart the server. 1 service dirsrv restart instance_name 4.
Chapter 17. Using the Pass-through Authentication Plug-in ... 4.2. Specifying Multiple Authenticating Directory Servers If the connection between the PTA Directory Server and the authenticating Directory Server is broken or the connection cannot be opened, the PTA Directory Server sends the request to the next server specified, if any. There can be multiple authenticating Directory Servers specified, as required, to provide failover if the first Directory Server is unavailable.
Specifying Different Optional Parameters dn: cn=Pass Through Authentication,cn=plugins,cn=config ... nsslapd-pluginEnabled: on nsslapd-pluginarg0: ldap://configdir.example.com/o=NetscapeRoot 10,5,300,3,300 ... 4.5. Specifying Different Optional Parameters and Subtrees for Different Authenticating Directory Servers To specify a different pass-through subtree and optional parameter values for each authenticating Directory Server, set more than one LDAP URL/optional parameters pair.
502
Chapter 18. Using the Attribute Uniqueness Plug-in The Attribute Uniqueness Plug-in can be used to ensure that the new or edited attributes always have unique values in the directory. A new instance of the Attribute Uniqueness Plug-in must be created for every attribute for which values must be unique. The Attribute Uniqueness Plug-in can enforce the uniqueness of the value for any attribute. 1. Overview of the Attribute Uniqueness Plug-in The Attribute Uniqueness Plug-in is a preoperation plug-in.
Chapter 18. Using the Attribute Uniqueness Plug-in object class. For example, a check may be performed only if the updated entry includes objectclass=inetorgperson. This configuration option is explained in more detail in Section 4.3.3, “Using the markerObjectClass and requiredObjectClass Keywords”. For information on using the Attribute Uniqueness Plug-in in a replicated environment, see Section 6, “Replication and the Attribute Uniqueness Plug-in”.
Attribute Uniqueness Plug-in Syntax • Only one attribute can be specified on which the uniqueness check will be performed. • It is possible to specify several DNs of suffixes or subtrees in which to perform the uniqueness check by incrementing the nsslapd-pluginarg attribute suffix by one each time. The variable components of the Attribute Uniqueness Plug-in syntax are described in Table 18.1, “Attribute Uniqueness Plug-in Variables”.
Chapter 18. Using the Attribute Uniqueness Plug-in Variable Definition dn The DN of the suffix or subtree in which to ensure attribute uniqueness. To specify several suffixes or subtrees, increment the suffix of the nsslapd-pluginarg attribute by one for each additional suffix or subtree. attribute=attribute_name The name of the attribute for which to ensure unique values. Only one attribute can be named.
Configuring Attribute Uniqueness Plug-ins Uniqueness Plug-in entry and only modify the attributes listed below. For example, to create an instance the Attribute Uniqueness Plug-in for the mail attribute, do the following: 1. In the dse.ldif file, locate the entry for the Attribute Uniqueness Plug-in, cn=attribute uniqueness,cn=plugins,cn=config. 2. Copy the entire entry. The entry ends in an empty line; copy the empty line, too. 3.
Chapter 18. Using the Attribute Uniqueness Plug-in (See Section 3, “Creating an Instance of the Attribute Uniqueness Plug-in”.) 3. In the right navigation window, double-click the plug-in entry to view. The Property Editor opens. It contains a list of all the attributes and values for the plug-in. 4.2. Configuring Attribute Uniqueness Plug-ins from the Directory Server Console The plug-in configuration can be updated from the Directory Server Console in several ways: • From the Property Editor. 1.
Configuring Attribute Uniqueness Plug-ins 4.3. Configuring Attribute Uniqueness Plug-ins from the Command-Line This section provides information about configuring the plug-in from the command line. • Section 4.3.1, “Turning the Plug-in On or Off” • Section 4.3.2, “Specifying a Suffix or Subtree” • Section 4.3.3, “Using the markerObjectClass and requiredObjectClass Keywords” 4.3.1. Turning the Plug-in On or Off 1.
Chapter 18. Using the Attribute Uniqueness Plug-in nsslapd-pluginarg2: ou=Engineering,dc=example,dc=com nsslapd-pluginarg3: ou=Sales,dc=example,dc=com This example LDIF statement modified the Attribute Uniqueness Plug-in to check the uniqueness of the mail attribute under the subtrees dc=example,dc=com, ou=Engineering,dc=example,dc=com, and ou=Sales,dc=example,dc=com. Use the ldapmodify command to import the LDIF file into the directory.
from the Command-Line dn: cn=mail uniqueness,cn=plugins,cn=config ... nsslapd-pluginEnabled: on nsslapd-pluginarg0: attribute=mail nsslapd-pluginarg1: markerObjectClass=ou nsslapd-pluginarg2: requiredObjectClass=person ... The markerObjectClass or requiredObjectClass keywords cannot be repeated by incrementing the counter in the nsslapd-pluginarg attribute suffix. These keywords can only be used once per Attribute Uniqueness Plug-in instance.
Chapter 18. Using the Attribute Uniqueness Plug-in dn: cn=mail uniqueness,cn=plugins,cn=config ... nsslapd-pluginEnabled: on nsslapd-pluginarg0: mail nsslapd-pluginarg1: l=Chicago,dc=example,dc=com nsslapd-pluginarg2: l=Boston,dc=example,dc=com ... NOTE The nsslapd-pluginarg0 attribute always contains the name of the attribute for which to ensure uniqueness. All other occurrences of the nsslapd-pluginarg, such as nsslapd-pluginarg1, contain DNs.
Multi-Master Replication Scenario Enabling the Attribute Uniqueness Plug-in on the consumer does not prevent Directory Server from operating correctly but is likely to cause a performance degradation. 6.2. Multi-Master Replication Scenario In a multi-master replication scenario, the masters act both as suppliers and consumers of the same replica.
514
Chapter 19. Synchronizing Red Hat Directory Server with Microsoft Active Directory The Windows Sync feature allows synchronization of adds, deletes, and changes in groups, users, and passwords between Red Hat Directory Server and Microsoft Active Directory. It provides an efficient and effective way to maintain consistent information across directories. 1.
Chapter 19. Synchronizing Red Hat Directory Server with Microsoft Active Directory Figure 19.1. Active Directory - Directory Server Synchronization Process • Password Sync Service. 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. This is done separately from the Windows Sync service to accommodate password encryption.
About Windows Sync • When creating the sync agreement, there is an option to synchronizing new Windows entries (nsDS7NewWinUserSync and nsDS7NewWinGroupSync) as they are created. If these attributes are set to on, then existing Windows users/groups are synchronized to the Directory Server, and users/groups as they are created are synchronized to the Directory Server. Within the Windows subtree, only entries with user or group object classes can be synchronized to Directory Server.
Chapter 19. Synchronizing Red Hat Directory Server with Microsoft Active Directory Figure 19.2. Multi-Master Directory Server - Windows Domain Synchronization Directory Server passwords are synchronized along with other entry attributes because plain-text passwords are retained in the Directory Server changelog. The Password Sync Service is needed to catch password changes made on Active Directory.
Step 2: Configure the Active Directory • Directory Server certificate, accessible by the sync services 2.2. Step 2: Configure the Active Directory Domain The Active Directory domain has to be properly configured for synchronization to work. 1. Set up the Windows domain. On Windows 2000, use the dcpromo tool. On Windows 2003, install the domain controller for Active Directory by clicking Add or Remove Programs and then Add/Remove Windows Components.
Chapter 19. Synchronizing Red Hat Directory Server with Microsoft Active Directory NOTE If the command-line tool returns an error message, then use the Web browser to access the CA and submit the certificate request. If IIS is running, then the CA URL is http://servername/certsrv. iv. Accept the certificate request. For example: certreq -accept cernew.cer v. Make sure that the server certificate is present on the Active Directory server.
Domain NOTE The user cited in the sync agreement (the supplier DN) exists on the Active Directory server. The user cited in the Password Sync configuration exists on Directory Server. 2.4. Step 4: Install and Configure the Password Sync Service Password Sync can be installed on any Windows machine to synchronize Windows passwords.
Chapter 19. Synchronizing Red Hat Directory Server with Microsoft Active Directory Figure 19.3. Setting up Password Sync Information Hit Next, then Finish to install Password Sync. 5. Reboot the Windows machine to start Password Sync. NOTE The Windows machine must be rebooted. Without the rebooting, PasswordHook.dll will not be enabled, and password synchronization will not function. Password Sync is installed in C:\Program Files\Red Hat Directory Password Synchronization.
Step 4: Install and Configure the Password nsldapssl32v50.dll libplc4.dll nsldappr32v50.dll nss3.dll libnspr4.dll ssl3.dll libplds4.dll softokn3.dll Next, set up certificates that Password Sync will use to access the Directory Server over SSL: NOTE SSL is required for Password Sync to send password to Directory Server. The service will not send the passwords except over SSL to protect the clear text password sent from the Active Directory machine to the Directory Server machine. 1. Download certutil.
Chapter 19. Synchronizing Red Hat Directory Server with Microsoft Active Directory 6. Give trusted peer status to the server. certutil.exe -d "C:\Program Files\Red Hat Directory Password Synchronization" -M -n Server-Cert -t "P,P,P" NOTE If any Active Directory user accounts exist when Password Sync is first installed, then the passwords for those user accounts cannot be synchronized until they are changed because Password Sync cannot decrypt a password once it has been hashed in Active Directory. 2.5.
Sync Service After setting up the changelog, then configure the database that will be synchronized as a replica. The replica role should be either a single-master or multi-master. 1. In the Directory Server Console, select the Configuration tab. 2. In the left-hand navigation tree, click the Replication folder, then click the name of the database to synchronize. By default, there are two databases, NetscapeRoot for directory configuration and userRoot for directory entries.
Chapter 19. Synchronizing Red Hat Directory Server with Microsoft Active Directory name of the synced suffix, such as dc=example,dc=com, is displayed. Figure 19.4. Setting up the Sync Agreement 6. In the middle of the screen are fields for the Windows domain information. Fill in the domain name and the domain controller. 7. Select the checkboxes for the Windows entries which are going to be synchronized.
Step 7: Begin Synchronization • Sync New Windows Users. When enabled, all user entries found in Windows that are subject to the agreement will automatically be created in the Directory Server. • Sync New Windows Groups. When enabled, all group entries found in Windows that are subject to the agreement will automatically be created in the Directory Server. 8.
Chapter 19. Synchronizing Red Hat Directory Server with Microsoft Active Directory • Section 3.5, “Manually Updating and Resynchronizing Entries” • Section 3.6, “Checking Synchronization Status” • Section 3.7, “Modifying the Sync Agreement” 3.1. Synchronizing Users If Windows users are synchronized when the sync agreement was created, all the existing Windows users are synchronized to the Directory Server after the first total update (when synchronization begins).
Synchronizing Users Figure 19.5. Setting User Attributes Additional ntUser attributes can be created either by using the Advanced button in the Console or by using ldapmodify; see Section 2.4.2, “Modifying Entries Using ldapmodify”. Table 19.1, “User Schema Mapped between Directory Server and Active Directory” shows the attributes that are mapped between the Directory Server and Windows servers, and Table 19.
Chapter 19. Synchronizing Red Hat Directory Server with Microsoft Active Directory 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 Table 19.2.
Deleting Entries Additionally, groups have the following two attributes: • ntUniqueId. This contains the value of the objectGUID attribute for the corresponding Windows entry. This attribute is set by the synchronization process and should not be set or modified manually. • ntGroupType. This is set automatically for Windows groups that are synchronized over, but this attribute must be set manually on Directory Server entries before they will be synched.
Chapter 19. Synchronizing Red Hat Directory Server with Microsoft Active Directory deleted if the deleted entry has the ntUserDeleteAccount or ntGroupDeleteAccount attribute set to true. NOTE When a Directory Server entry is synchronized over to Active Directory for the first time, Active Directory automatically assigns it a unique ID. At the next synchronization interval, the unique ID is sychronized back to the Directory Server entry and stored as the ntUniqueId attribute.
Checking Synchronization Status To perform an incremental update manually: 1. Go to the Configuration tab in the Console. 2. Right-click on the synchronization agreement icon, and select Send and Receive Updates from the drop down menu. During normal operations, all the updates made to entries in the Directory Server that need to be sent to Active Directory are collected the changelog and then replayed during an incremental update.
Chapter 19. Synchronizing Red Hat Directory Server with Microsoft Active Directory and shows whether Windows users and groups are synchronized. It also shows whether synchronization occurs over an SSL connection. 4. Schema Differences Although Active Directory supports the same basic X.500 object classes as Directory Server, there are a few incompatibilities of which administrators should be aware. 4.1.
Contraints on the initials attribute avoid conflicts, the street attribute should not be used in Active Directory. • Only one Directory Server street attribute value is synced to Active Directory. If the streetAddress attribute is changed in Active Directory and the new value does not already exist in Directory Server, then all street attribute values in Directory Server are replaced with the new, single Active Directory value. 4.4.
Chapter 19. Synchronizing Red Hat Directory Server with Microsoft Active Directory 3. Select Stop or Start, and hit okay. Changed passwords are captured even if Password Sync is not running. If Password Sync is restarted, the password changes are sent to Directory Server at the next synchronization. 5.3. Uninstalling Password Sync Service To uninstall the Password Sync service, do the following: 1. Open the Add/Remove Programs utility. 2. Select click remove to uninstall the Password Sync service. 3.
Troubleshooting To narrow down the source of the misconfiguration, try to establish an LDAPS connection to the Directory Server. If this connection attempt fails, check all values (port number, hostname, search base, and so forth) to see if any of these are the problem. If all else fails, reconfigure the Directory Server with a new certificate. If the LDAPS connection is successful, it is likely that the misconfiguration is on Active Directory. Examine the Windows event log file for error messages.
538
Appendix A. LDAP Data Interchange Format Red Hat Directory Server (Directory Server) uses the LDAP Data Interchange Format (LDIF) to describe a directory and directory entries in text format. LDIF is commonly used to build the initial directory database or to add large numbers of entries to the directory all at once. In addition, LDIF is also used to describe changes to directory entries. For this reason, most of Directory Server's command-line utilities rely on LDIF for either input or output.
Appendix A. LDAP Data Interchange Format Field Definition [id] Optional. A positive decimal number representing the entry ID. The database creation tools generate this ID automatically. Never add or edit this value yourself. dn: distinguished_name Specifies the distinguished name for the entry. objectClass: object_class Specifies an object class to use with this entry. The object class identifies the types of attributes, or schema, allowed and required for the entry.
Representing Binary Data In LDIF files, a line can be broken and continued (called folded) by indenting the continued portion of the line by exactly one space. For example, the following two statements are identical: dn: cn=Jake Lupinski,dc=example,dc=com dn: cn=Jake Lup inski, dc=exa mple,dc=com It is not required to break and continue LDIF lines. However, doing so may improve the readability of the LDIF file. The usual convention is that an LDIF file does not contain more than 78 columns of text. 3.
Appendix A. LDAP Data Interchange Format For example: jpegPhoto::encoded_data In addition to binary data, other values that must be base-64 encoded include the following: • Any value that begins with a colon (:) or a space. • Any value that contains non-ASCII data, including new lines. Use the ldif command-line utility with the -b parameter to convert binary data to LDIF format: ldif -b attribute_name attribute_name is the name of the attribute to which the binary data is supplied.
Specifying Organizational Unit Entries domain entry for the directory is probably named dc=ldap,dc=example,dc=com or simply dc=example,dc=com. The LDIF entry used to define a domain appears as follows: dn: distinguished_name objectClass: top objectClass: domain dc: domain_component_name list_of_optional_attributes ...
Appendix A. LDAP Data Interchange Format 4.2. Specifying Organizational Unit Entries Organizational unit entries are often used to represent major branch points, or subdirectories, in the directory tree. They correspond to major, reasonably static entities within the enterprise, such as a subtree that contains people or a subtree that contains groups.
Specifying Organizational Person Entries Table A.3. LDIF Elements in Organizational Unit Entries 4.3. Specifying Organizational Person Entries The majority of the entries in the directory represent organizational people.
Appendix A. LDAP Data Interchange Format LDIF Element Description objectClass: organizationalPerson Specifies the organizationalPerson object class. This object class specification should be included because some LDAP clients require it during search operations for an organizational person. objectClass: inetOrgPerson Specifies the inetOrgPerson object class.
Defining Directories Using LDIF example, if the database has the suffix dc=example,dc=com, the first entry in the directory must be dn: dc=example,dc=com. For information on suffixes, see the "Suffix" parameter described in the Directory Server Configuration, Command, and File Reference. 3. Make sure that an entry representing a branch point in the LDIF file is placed before the entries to create under that branch.
Appendix A. LDAP Data Interchange Format Server must be running before a subtree can be added using ldapmodify. See Section 2.4, “Adding and Modifying Entries Using ldapmodify”. 5.1.
Storing Information in Multiple Languages objectClass: organizationalPerson objectClass: inetOrgPerson cn: Robert Wong cn: Bob Wong sn: Wong givenName: Robert givenName: Bob mail: bwong@example.com userPassword: {sha}nn2msx761 telephoneNumber: 2881 roomNumber: 211 ou: Manufacturing ou: people dn: ou=Groups,dc=example,dc=com objectclass: top objectclass: organizationalUnit ou: groups description: Fictional example organizational unit 6.
Appendix A. LDAP Data Interchange Format employees to be able to view directory information in their native language. When adding directory entries, the directory administrator chooses to provide attribute values in both English and French. When adding a directory entry for a new employee, Babs Jensen, the administrator does the following: 1. The administrator creates a file, street.txt, with the French street address value: 1 rue de l'Université 2.
Appendix B. Finding Directory Entries Entries in the directory can be searched for and found using any LDAP client. Most clients provide some form of search interface so that the directory can be searched easily and entry information can be easily retrieved. NOTE Users cannot search the directory unless the appropriate access control has been set in the directory. For information on setting access control in the directory, see Chapter 6, Managing Access Control. 1.
Appendix B. Finding Directory Entries the tree, or right-click an entry, and select Search from the pop-up menu. Figure B.2. Searching for Entries TIP See the online help for information on using the search form. CAUTION Do not modify the contents of the o=NetscapeRoot suffix using the Directory tab unless instructed to do so by Red Hat technical support. 2. Using ldapsearch The ldapsearch command-line utility can locate and retrieve directory entries.
Using Special Characters Hat Enterprise Linux i386, in the /usr/lib64/mozldap directory on 64-bit versions of Red Hat Enterprise Linux and Solaris, and in the /opt/dirsrv/bin/mozldap/ directory on HP-UX. When running any LDAP command, make sure to use the MozLDAP utilities, otherwise the command will return errors. NOTE For most Linux systems, OpenLDAP tools are already installed in the /usr/bin/ directory. These OpenLDAP tools will not work for Directory Server operations.
Appendix B. Finding Directory Entries • optional_search_filter is an LDAP search filter as described in Section 3, “LDAP Search Filters”. Do not specify a separate search filter if search filters are specified in a file using the -f option. • optional_list_of_attributes is a list of attributes separated by a space. Specifying a list of attributes reduces the number of attributes returned in the search results. This list of attributes must appear after the search filter. For an example, see Section 2.4.
Commonly Used ldapsearch Options Option Description server. If specified, this value must be a DN recognized by the Directory Server, and it must also have the authority to search for the entries. For example, -D "uid=bjensen, dc=example,dc=com". -h Specifies the hostname or IP address of the machine on which the Directory Server is installed. For example, -h mozilla. If a host is not specified, ldapsearch uses the localhost.
Appendix B. Finding Directory Entries Option Description useful for sorting according to a matching rule, as with an international search. In general, it is faster to sort on the server rather than on the client. -z Sets the maximum number of entries to return in response to a search request. For example, -z 1000. Normally, regardless of the value specified here, ldapsearch never returns more entries than the number allowed by the server's nsslapd-sizelimit attribute.
ldapsearch Examples ldapsearch -h mozilla -b "dc=example,dc=com" -s sub "objectclass=*" "objectclass=*" is a search filter that matches any entry in the directory. Since every entry must have an object class, and the objectclass attribute is always indexed, this is a useful search filter to return every entry. 2.4.2. Specifying Search Filters on the Command Line A search filter can be specified directly on the command line as long as the filter is enclosed in quotation marks ("filter").
Appendix B. Finding Directory Entries ldapsearch -h mozilla "cn=babs jensen" In this example, the default scope of sub is used because the -s option was not used to specify the scope. 2.4.6. Displaying Subsets of Attributes The ldapsearch command returns all search results in LDIF format. By default, ldapsearch returns the entry's distinguished name and all of the attributes that a user is allowed to read.
LDAP Search Filters the search line. For example, the following ldapsearch command performs both searches but returns only the DN and the givenname and sn attributes of each entry: ldapsearch -h mozilla -f searchdb sn givenname 2.4.8. Specifying DNs That Contain Commas in Search Filters When a DN within a search filter contains a comma as part of its value, the comma must be escaped with a backslash (\). For example, to find everyone in the example.com Bolivia, S.A.
Appendix B. Finding Directory Entries 3.1. Search Filter Syntax The basic syntax of a search filter is: attribute operator value For example: buildingname>=alpha In this example, buildingname is the attribute, >= is the operator, and alpha is the value. Filters can also be defined that use different attributes combined together with Boolean operators. Search filters are described in detail in the following sections: • Section 3.1.1, “Using Attributes in Search Filters” • Section 3.1.
Search Filter Syntax Search Type Operator Description Equality = Returns entries containing attribute values that exactly match the specified value. For example, cn=Bob Johnson Substring =string* string Returns entries containing attributes containing the specified substring. For example, cn=Bob* cn=*Johnson cn=*John* cn=B*John. The asterisk (*) indicates zero (0) or more characters.
Appendix B. Finding Directory Entries Multiple search filter components can be combined using Boolean operators expressed in prefix notation as follows: (Boolean-operator(filter)(filter)(filter)...) Boolean-operator is any one of the Boolean operators listed in Table B.2, “Search Filter Boolean Operators”.
Searching an Internationalized Directory manager=* The following filter searches for entries containing the common name Ray Kultgen. This is also known as an equality search: cn=Ray Kultgen The following filter returns all entries that do not contain the common name Ray Kultgen: (!(cn=Ray Kultgen)) The following filter returns all entries that contain a description attribute that contains the substring X.500: description=*X.
Appendix B. Finding Directory Entries NOTE An LDAPv3 search is required to perform internationalized searches. Therefore, do not specify the -V2 option on the call for ldapsearch. This section focuses on the matching rule filter portion of the ldapsearch syntax. For more information on general ldapsearch syntax, see Section 3, “LDAP Search Filters”. For information on searching internationalized directories using the Users and Groups portion of the Red Hat Console, see the online help.
Matching Rule Filter Syntax • As the OID of the collation order for the locale on which to base the search. • As the language tag associated with the collation order on which to base the search. • As the OID of the collation order and a suffix that represents a relational operator. • As the language tag associated with the collation order and a suffix that represents a relational operator. The syntax for each of these options is discussed in the following sections: • Section 4.1.1.
Appendix B. Finding Directory Entries The relational operator is included in the value portion of the string, separated from the value by a single space. For example, to search the directory for all description attributes with a value of estudiante using the Spanish collation order, use the following filter: cn:es:== estudiante 4.1.1.3.
Supported Search Types When performing a substring search using a matching rule filter, use the asterisk (*) character as a wildcard to represent zero or more characters. For example, to search for an attribute value that starts with the letter l and ends with the letter n, enter a l*n in the value portion of the search filter. Similarly, to search for all attribute values beginning with the letter u, enter a value of u* in the value portion of the search filter.
Appendix B. Finding Directory Entries Search Type Operator Suffix Substring * .6 Table B.3. Search Types, Operators, and Suffixes 4.3. International Search Examples The following sections show examples of how to perform international searches on directory data. Each example gives all the possible matching rule filter formats so that you can become familiar with the formats and select the one that works best. 4.3.1.
International Search Examples Performing a locale-specific search using the equal to operator (=), or suffix (.3) searches for all attribute values that match the given attribute in a specific collation order. For example, to search for all businessCategory attributes with the value softwareprodukte in the German collation order, any of the following matching rule filters would work: businessCategory:2.16.840.1.113730.3.3.2.7.1:==softwareprodukte ... businessCategory:de:== softwareprodukte ...
Appendix B. Finding Directory Entries Performing an international substring search searches for all values that match the given pattern in the specified collation order. For example, to search for all user IDs that end in ming in the Chinese collation order, any of the following matching rule filters would work: uid:2.16.840.1.113730.3.3.2.49.1:=* *ming ... uid:zh:=* *ming ... uid:2.16.840.1.113730.3.3.2.49.1.6:=* *ming .. uid:zh.
Appendix C. LDAP URLs LDAP URLs identify the Red Hat Directory Server instance, similarly to the way site URLs identify a specific website or web page. There are three common times when the LDAP URL of the Directory Server instance is used: • The LDAP URL is used to identif the specific Directory Server instance when the Directory Server is accessed using a web-based client. • LDAP URLs are used to configure Directory Server referrals. • LDAP URLs are used to configure access control instructions.
Appendix C. LDAP URLs Component Description base_dn Distinguished name (DN) of an entry in the directory. This DN identifies the entry that is the starting point of the search. If no base DN is specified, the search starts at the root of the directory tree. attributes The attributes to be returned. To specify more than one attribute, use commas to separate the attributes; for example, cn,mail,telephoneNumber. If no attributes are specified in the URL, all attributes are returned.
Escaping Unsafe Characters no specific attributes are identified in the URL, all attributes are returned in the search. 2. Escaping Unsafe Characters Any unsafe characters in the URL need to be escaped, or substituted with a special sequence of characters. For example, a space is an unsafe character that must be represented as %20 within the URL. Thus, the distinguished name o=example.com corporation must be encoded as o=example.com%20corporation.
Appendix C. LDAP URLs The following LDAP URL specifies a base search for the entry with the distinguished name dc=example,dc=com. ldap://ldap.example.com/dc=example,dc=com • Because no port number is specified, the standard LDAP port number (389) is used. • Because no attributes are specified, the search returns all attributes. • Because no search scope is specified, the search is restricted to the base entry dc=example,dc=com.
Examples of LDAP URLs • Because no attributes are specified, the search returns all attributes. • Because the search scope is sub, the search encompasses the base entry dc=example,dc=com and entries at all levels under the base entry. Example 5. The following LDAP URL specifies a search for the object class for all entries one level under dc=example,dc=com: ldap://ldap.example.
576
Appendix D. Internationalization Red Hat Directory Server allows users to store, manage, and search for entries and their associated attributes in a number of different languages. An internationalized directory can be an invaluable corporate resource, providing employees and business partners with immediate access to the information they need in languages they understand. Directory Server supports all international charactersets by default because directory data is stored in UTF-8.
Appendix D. Internationalization represented. • Time/date format. The time and date format indicates the customary formatting for times and dates in the region. The time and date format indicates whether dates are customarily represented in the mm/dd/yy (month, day, year) or dd/mm/yy (day, month, year) format and specifies what the days of the week and month are in a given language. For example, the date January 10, 1996, is represented as 10.leden 1996 in Czechoslovakian and 10 janvier 1996 in French.
Supported Language Subtypes Locale Language Tag Collation Order Object Identifiers (OIDs) Chinese (Simplified) zh 2.16.840.1.113730.3.3.2.49.1 Chinese (Traditional) zh-TW 2.16.840.1.113730.3.3.2.50.1 Croatian hr 2.16.840.1.113730.3.3.2.22.1 Czechoslovakian cs 2.16.840.1.113730.3.3.2.5.1 Danish da 2.16.840.1.113730.3.3.2.6.1 English (US) en or en-US 2.16.840.1.113730.3.3.2.11.1 Estonian et 2.16.840.1.113730.3.3.2.16.1 Finnish fi 2.16.840.1.113730.3.3.2.17.1 French fr or fr-FR 2.
Appendix D. Internationalization 3. Supported Language Subtypes Language subtypes can be used by clients to determine specific values for which to search. For more information on using language subtypes, see Section 1.3.8, “Adding an Attribute Subtype”. Table D.2, “Supported Language Subtypes” lists the supported language subtypes for Directory Server.
Troubleshooting Matching Rules Language Tag Language sl Slovenian sq Albanian sr Serbian sv Swedish tr Turkish uk Ukrainian zh Chinese Table D.2. Supported Language Subtypes 4. Troubleshooting Matching Rules International collation order matching rules may not behave consistently. Some forms of matching-rule invocation do not work correctly, producing incorrect search results.
582
Glossary A access control instruction See ACI. ACI An instruction that grants or denies permissions to entries in the directory. See Also access control instruction. access control list See ACL. ACL The mechanism for controlling access to your directory. See Also access control list. 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.
Glossary value. attribute list A list of required and optional attributes for a given entry type or object class. authenticating directory server In pass-through authentication (PTA), the authenticating Directory Server is the Directory Server that contains the authentication credentials of the requesting client. The PTA-enabled host sends PTA requests it receives from clients to the host. authentication (1) Process of proving the identity of the client user to the Directory Server.
uses the HTTP protocol to communicate with the host server. browsing index Speeds up the display of entries in the Directory Server Console. Browsing indexes can be created on any branch point in the directory tree to improve display performance. See Also virtual list view index . C CA See Certificate Authority. cascading replication In a cascading replication scenario, one server, often called the hub supplier, acts both as a consumer and a supplier for a particular replica.
Glossary ciphertext Encrypted information that cannot be read by anyone without the proper key to decrypt the information. 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. client See LDAP client.
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. Instead, it points to data stored remotely. default index One of a set of default indexes created per database instance. Default indexes can be modified, although care should be taken before removing them, as certain plug-ins may depend on them. definition entry See CoS definition entry.
Glossary 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 www.yourdomain.domain might point to a real machine called realthing.yourdomain.domain where the server currently exists. DSGW See Directory Server Gateway. E entry A group of lines in the LDIF file that contains information about an object.
gateway See Directory Server Gateway. general access When granted, indicates that all authenticated users can access directory information. GSS-API Generic Security Services. The generic access protocol that is the native way for UNIX-based systems to access and authenticate Kerberos services; also supports session encryption. H hostname A name for a machine in the form machine.domain.dom, which is translated into an IP address. For example, www.example.
Glossary indirect CoS An indirect CoS identifies the template entry using the value of one of the target entry's attributes. international index Speeds up searches for information in international directories. International Standards Organization IP address See ISO. ISO International Standards Organization. Also Internet Protocol address. A set of numbers, separated by dots, that specifies the actual location of a machine on the Internet (for example, 198.93.93.10).
Access Protocol See LDAP. locale Identifies the collation order, character type, monetary format and time / date format used to present data for users of a specific region, culture, and/or custom. This includes information on how data of a given language is interpreted, stored, or collated. The locale also indicates which code page should be used to represent a given language. M managed object A standard value which the SNMP agent can access and send to the NMS.
Glossary directory tree. monetary format Specifies the monetary symbol used by specific region, whether the symbol goes before or after its value, and how monetary units are represented. multi-master replication An advanced replication scenario in which two servers each hold a copy of the same read-write replica. Each server maintains a changelog for the replica. Modifications made on one server are automatically replicated to the other server.
object class Defines an entry type in the directory by defining which attributes are contained in the entry. object identifier A string, usually of decimal numbers, that uniquely identifies a schema element, such as an object class or an attribute, in an object-oriented system. Object identifiers are assigned by ANSI, IETF or similar organizations. See Also OID. OID See object identifier.
Glossary 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. The proxy DN is the DN of an entry that has access permissions to the target on which the client-application is attempting to perform an operation.
process is called a referral. read-only replica A replica that refers all update operations to read-write replicas. A server can hold any number of read-only replicas. read-write replica A replica that contains a master copy of directory information and can be updated. A server can hold any number of read-write replicas. relative distinguished name See RDN. replica A database that participates in replication.
Glossary 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. Schema checking is on by default, and users will receive an error if they try to save an entry that does not conform to the schema.
See Also ns-slapd. SNMP Used to monitor and manage application processes running on the servers by exchanging data about network activity. Also Simple Network Management Protocol. SNMP master agent Software that exchanges information between the various subagents and the NMS. SNMP subagent Software that gathers information about the managed device and passes the information to the master agent. Also called a subagent.
Glossary T target In the context of access control, the target identifies the directory information to which a particular ACI applies. target entry The entries within the scope of a CoS. TCP/IP Transmission Control Protocol/Internet Protocol. The main network protocol for the Internet and for enterprise (company) networks. template entry See CoS template entry. time/date format Indicates the customary formatting for times and dates in a specific region.
X.500 standard The set of ISO/ITU-T documents outlining the recommended information model, object classes and attributes used by directory server implementation.
600
Index A access control ACI attribute, 169 ACI syntax, 173 allowing or denying access, 181 and replication, 241 and schema checking, 177 anonymous access, 187 bind rules, 184 access at specific time or day, 198 access based on value matching, 191 general access, 187 user and group access, 186 Boolean bind rules, 201 compatibility with earlier versions, 241 creating from console, 202 dynamic targets, 187 from specific domain, 197 from specific IP address, 196 logging information, 216 overview, 169 permissions
Index roledn keyword, 190 structure, 169 syntax, 173 targattrfilters keyword, 179 target, 173 target DN containing comma, 175 target DN containing comma, 234 target keywords, 174 target overview, 173 targetattr keyword, 176 targetfilter keyword, 178 userattr and parent, 194 userattr keyword, 191 using macro ACIs, 235 value-based, 179 viewing current, 210 wildcard in target, 176 wildcards, 188 ACI attribute default index for, 367 overview, 169 ACI placement, 170 ACI targets, 175 ACL.
pronunciation, 23 attribute type field (LDIF), 540 attribute uniqueness plug-in creating an instance of, 506 attribute uniqueness plug-in.
Index cascading chaining client ACIs, 98 configuration attributes, 99 configuring defaults, 95 configuring from command line, 97 configuring from console, 96 example, 100 local ACI evaluation, 98 loop detection, 99 overview, 93 proxy admin user ACI, 97 proxy authorization, 97 cascading replication initializing the replicas, 305 introduction, 274 setting up, 298 certificate mapping to a DN, 416 password, 410 certificate database password, 393 certificate-based authentication, 415 setting up, 416 chaining ca
commas, in DNs, 31, 175 using ldapsearch with, 559 compare right, 181 compatibility ACIs, 241 replication, 269 compound search filters, 561 configuration attributes account lockout, 258 cascading chaining, 99 password policy, 247 suffix, 52 connections monitoring, 441 viewing number of, 440 consumer initialization filesystem replica, 327 manual consumer creation, 326 online consumer creation, 324 consumer server, 268 continued lines in LDIF, 540 in LDIF update statements, 33 CoS definition entry attributes,
Index configuring from console, 96 overview, 93 chaining with SSL, 86 configuration, 75 configuration attributes, 81 configuration example, 81 configuring bind credentials, 78 configuring failover servers, 81 configuring LDAP URL, 80 configuring suffix, 78 creating from command line, 77 creating from console, 75 deleting, 87 maintaining remote server info, 86 overview, 69 database server parameters read-only, 446 database transaction logging described, 466 durable transactions, 468 log file location, 466 d
starting the Console, 7 suffixes, 47 supported languages, 578 Directory Server Console starting, 7 directory trees finding entries in, 552 disabling suffixes, 55 disk space access log and, 434 log files and, 438 distribution function, 59 dn field (LDIF), 540 dns keyword, 197 dse.ldif PTA plugin, 496 dse.
Index id2entry.
using OIDs, 565 internationalization character type, 577 collation order, 577 country code, 578 date format, 578 language tag, 578 locales and, 577 location of files, 578 matching rule filters, 564 modifying entries, 41 monetary format, 577 object identifiers and, 578 of LDIF files, 549 search filters and, 563 supported locales, 578 time format, 578 ip keyword, 196 J jpeg images, 541 K Kerberos, 421 configuring, 426 realms, 427 L language code in LDIF entries, 549 list of supported, 578 language subtype,
Index change type, 33 entry format, 539 organization, 542 organizational person, 545 organizational unit, 544 example, 548 internationalization and, 549 line continuation, 540 Server Console and, 26 specifying entries organization, 543 organizational person, 545 organizational unit, 544 update statements, 32 using to create directory, 546 LDIF entries binary data in, 541 creating, 542 organizational person, 545 organizational units, 544 organizations, 542 internationalization and, 549 LDIF files continued
manually rotating log files, 438 markerObjectClass keyword, 510 matchingRule format, 564 using language tag, 565 using language tag and suffix, 566 using OID, 565 using OID and suffix, 566 metaphone phonetic algorithm, 369 MIB Directory Server, 457 redhat-directory.
Index deleting, 360 editing, 361 editing in object class, 361 organization, specifying entries for, 542 organizational person, specifying entries for, 545 organizational unit, specifying entries for, 544 override CoS qualifier, 154 P parent access, 187 parent keyword, 187 parent object, 359 pass-through authentication (PTA).
disabling, 490 distinguished name syntax plug-in, 476 enabling, 490 generalized time syntax plug-in, 476 integer syntax plug-in, 477 internationalization plug-in, 477 ldbm database plug-in, 478 legacy replication plug-in, 478 multimaster replication plug-in, 479 NS-MTA-MD5 password storage plug-in, 481 octet string syntax plug-in, 479 postal address string syntax plug-in, 483 PTA plug-in, 483 reference, 471 referential integrity plug-in, 484 retro changelog plug-in, 485 roles plug-in, 486 SHA password stora
Index replica exporting to LDIF, 326 read-only, 267 read-write, 267 replicate_now.
creating from command line, 51 creating from console, 50 S SASL authentication, 200 configuring KDC server, 427 configuring authentication at startup, 429 configuring Kerberos, 426 identity mapping, 422 configuring form the Console, 424 configuring from the command-line, 426 default, 424 KDC server configuration example, 428 Kerberos realms, 427 mechanisms, 421 CRAM-MD5, 421 DIGEST-MD5, 421 GSS-API, 421 password change extended operation, 255 schema checking, 362 creating new attributes, 355 creating new o
Index Simple Authentication and Security Layer (SASL). See SASL authentication, 200 Simple Network Management Protocol. See SNMP, 453 Simple Sockets Layer.
-, in change operation, 33 ::, in LDIF statements, 541 <, in LDIF statements, 541 quotation marks, in ldapmodify commands, 31 synchronization agreement changing, 533 syntax ACI statements, 173 attribute value, 356 LDAP URLs, 571 ldapsearch, 553 LDIF update statements, 33 matching rule filter, 564 search filter, 560 system connections monitoring, 441 system indexes, 366 system resources monitoring, 440 T targattrfilters keyword, 179 target ACI syntax, 173 attribute values, 179 attributes, 176 keywords in AC
Index in matching rule filters, 566 WinSync, 515 about, 515 changing the sync agreement, 533 checking sync status, 533 configuring, 518 deleting entries, 531 groups, 530 logging levels, 536 manually updating, 532 Password Sync service, 521, 535 modifying, 535 setting up SSL, 523 starting and stopping, 535 uninstalling, 536 resurrecting deleted entries, 532 schema differences, 534 troubleshooting, 536 users, 528 using, 527 write performance, 388 write right, 181 618
