HP-UX Directory Server Administrator Guide HP-UX Directory Server Version 8.1 Abstract This document describes all the administration tasks you need to perform to maintain the HP-UX Directory Server.
© Copyright 2013, 2014 Hewlett-Packard Development Company, L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. The information contained herein is subject to change without notice.
Contents HP secure development lifecycle....................................................................18 1 Basic HP-UX Directory Server Usage...........................................................19 Overview..............................................................................................................................19 Directory Server file Locations...................................................................................................19 Starting and Stopping Servers....
Creating a new database link.............................................................................................53 Creating a new database link using the console................................................................53 Creating a database link from the command line..............................................................57 Providing suffix information........................................................................................58 Providing bind credentials...................
Adding an attribute to an entry.....................................................................................105 Adding very large attributes ........................................................................................108 Adding and removing attribute values............................................................................109 Adding an attribute subtype.........................................................................................109 Language subtype...................
Attribute uniqueness plug-in syntax examples.......................................................................144 Specifying one attribute and one subtree........................................................................144 Specifying one attribute and multiple subtrees.................................................................144 Replication and the attribute uniqueness plug-in...................................................................145 Simple replication scenario................
About CoS......................................................................................................................189 About the CoS definition entry......................................................................................189 About the CoS template entry.......................................................................................189 How a pointer CoS works............................................................................................
Defining permissions........................................................................................................241 Allowing or denying access..........................................................................................241 Assigning rights..........................................................................................................241 Rights required for LDAP operations...............................................................................242 Permissions syntax..
Granting write access to personal entries............................................................................275 ACI "Write example.com"............................................................................................275 ACI "Write Subscribers"...............................................................................................276 Restricting access to key roles............................................................................................277 ACI "Roles"............
Configuring the PTA plug-in...............................................................................................308 Configuring the servers to use a secure connection..........................................................308 Specifying the authenticating Directory Server.................................................................309 Specifying the pass-through subtree...............................................................................309 Configuring the optional parameters......
Configuring hubs from the command line............................................................................367 Configuring replication agreements from the command line...................................................368 Initializing consumers online from the command line.............................................................370 Making a replica updatable..................................................................................................371 Deleting the changelog.................
Step 8: Begin synchronization............................................................................................404 Synchronizing users..............................................................................................................405 User attributes synchronized between Directory Server and Active Directory.............................406 User schema differences between Directory Server and Active Directory..................................407 Values for cn attributes................
Viewing attributes and object classes..................................................................................432 Creating attributes...........................................................................................................434 Creating object classes.....................................................................................................436 Editing custom schema elements.........................................................................................
12 Managing SSL......................................................................................470 Introduction to SSL in the Directory Server................................................................................470 Enabling SSL: Summary of steps........................................................................................470 Command line functions for Start TLS..................................................................................471 Troubleshooting Start TLS...........
Viewing the access log................................................................................................511 Configuring the access log...........................................................................................511 Errors log........................................................................................................................512 Viewing the errors log..................................................................................................
HP authorized resellers.....................................................................................................544 Documentation feedback..................................................................................................544 Related information...............................................................................................................545 HP-UX Directory Server documentation set...........................................................................
Less-than example.......................................................................................................568 Less-than or equal-to example.......................................................................................568 Equality example........................................................................................................568 Greater-than or equal-to example..................................................................................568 Greater-than example......
HP secure development lifecycle Starting with HP-UX 11i v3 March 2013 update release, HP secure development lifecycle provides the ability to authenticate HP-UX software. Software delivered through this release has been digitally signed using HP's private key. You can now verify the authenticity of the software before installing the products, delivered through this release. To verify the software signatures in signed depot, the following products must be installed on your system: • B.11.31.
1 Basic HP-UX Directory Server Usage The HP-UX 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.
http://www.pathname.com/fhs/. The files and directories installed with Directory Server are listed in the tables below for each supported platform. In the file locations listed in the following tables, instance is the server instance name that was given during setup. By default, this is the leftmost component of the fully-qualified host and domain name. For example, if the host name is ldap.example.com, the instance name is ldap by default.
/opt/dirsrv/bin/hpds-idm-console 2. In the Tasks tab, click Start the Directory Server, Stop the Directory Server, or Restart the Directory Server. When the Directory Server is successfully started or stopped from the Directory Server Console, the server displays a message box stating that the server has either started or shut down.
When the login screen opens, you are prompted for the username, password, and Administration Server location. It is possible to send the Administration Server URL and port with the start script. For example: /opt/dirsrv/bin/hpds-idm-console -a http://localhost:9830 The a option is a convenience, particularly if you are logging into a Directory Server for the first time. On subsequent logins, the URL is saved.
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 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.
NOTE: Modifying the standard or secure port numbers for a Configuration Directory 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.
NOTE: Do not restart the Directory Server at this point. If you do, you will not be able to make the necessary changes to the Administration Server through the Console. 7. 8. Open the Administration Server Console. In the Configuration tab, select the Configuration DS tab. 9. In the LDAP Port field, type in the new LDAP port number for your Directory Server instance. 10. Check the Secure Connection box if this is a secure port.
12. Open the Configuration DS tab of the Administration Server Console and select Save. A dialog will appear, stating: The Directory Server setting has been modified. You must shut down and restart your Administration Server and all the servers in the Server Group for the changes to take effect. Click OK. 13. In the Tasks tab of the Administration Server Console, click Restart Admin Server. A dialog opens reading that the Administration Server has been successfully restarted. Click Close.
3. Fill in the instance information. • A unique name for the server. This name must have only alphanumeric characters, a dash (-), or an underscore (_). • A port number for LDAP communications. • The root suffix for the new Directory Server instance. • A DN for the Directory Manager. This user has total access to every entry in the directory, without normal usage constraints (such as search timeouts); this is described in “Configuring the Directory Manager” (page 28).
4. • The password for the Directory Manager. • The user ID with which to run the Directory Server daemon. Click OK. A status box appears to confirm that the operation was successful. To dismiss it, click OK. Configuring the Directory Manager The Directory Manager is the privileged database administrator, comparable to the root user in UNIX. Access control does not apply to the Directory Manager entry; likewise, limits on searches and other operations do not apply.
Enabling plug-ins Enabling plug-ins To enable and disable plug-ins over LDAP using the Directory Server Console: 1. In the Directory Server Console, select the Configuration tab. 2. Double-click the Plugins folder in the navigation tree. 3. Select the plug-in from the Plugins list. 4. To disable the plug-in, clear the Enabled checkbox. To enable the plug-in, check this checkbox. 5. 6. Click Save. Restart the Directory Server.
replace: nsslapd-pluginPrecedence nsslapd-pluginPrecedence: 1 30 Basic HP-UX Directory Server Usage
2 Configuring Directory Databases The topics include: • Overview • “Creating and Maintaining Suffixes” (page 31) • “Creating and Maintaining Suffixes” (page 31) • “Creating and Maintaining Databases” (page 39) • “Creating and Maintaining Database Links” (page 52) • “Using Referrals” (page 87) Overview of Directory Databases The directory is made up of databases, and the directory tree is distributed across the databases.
Creating suffixes Both root and sub suffixes can be created to organize the contents of the directory tree. A root suffixis 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. A directory might contain more than one root suffix. For example, an ISP might host several web sites, one for example.com and one for hp.com.
Figure 5 Directory tree with a sub suffix This section describes creating root and sub suffixes for the directory using either the Directory Server Console or the command line. • “Creating a new root suffix using the console” (page 33) • “Creating a new sub suffix using the console” (page 34) • “Creating root and sub suffixes from the command line” (page 36) Creating a new root suffix using the console 1. 2. In the Directory Server Console, select the Configuration tab.
4. Select the Create associated database automatically to create a database at the same time as the new root suffix, and enter a unique name for the new database in the Database name field, such as example2. The name can be a combination of alphanumeric characters, dashes (-), and underscores (_). No other characters are allowed. Deselect the checkbox to create a database for the new root suffix later. This option specifies a directory where the database will be created.
The Create new sub suffix dialog box is displayed. 3. Enter a unique suffix name in the New suffix field. The suffix must be named in line with dc naming conventions, such as ou=groups. The root suffix is automatically added to the name. For example, if 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.
Creating root and sub suffixes from the command line Use the ldapmodify command line utility to add new suffixes to the directory configuration file. The suffix configuration information is stored in the cn=mapping tree,cn=config entry. NOTE: Avoid creating entries under the cn=config entry in thedse.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.
NOTE: To maintain suffixes using the Directory Server Console, respect the same spacing used to name the root and sub suffixes in the command line. For example, if a root suffix is named ou=groups ,dc=example,dc=com, with two spaces after groups, any sub suffixes created under this root will need to specify two spaces after ou=groups, as well. The following table describes the attributes used to configure a suffix entry: Table 2 Suffix attributes Attribute name Value dn Defines the DN for the suffix.
Disabling a suffix Sometimes, a database may need taken down for maintenance, but the data the database contains are not replicated. Rather than returning a referral, disable the suffix responsible for the database. After a suffix is disabled, the contents of the database related to the suffix are invisible to client applications when they perform LDAP operations such as search, add, and modify. To disable a suffix: 1. In the Directory Server Console, select the Configuration tab. 2.
4. Select either Delete this suffix and all of its sub suffixes ro Delete this suffix only. Creating and Maintaining Databases After creating suffixes to organizing the directory data, create databases to contain that directory data. Databases are used to store directory data. Creating databases The directory tree can be distributed over multiple Directory Server databases. There are two ways to distribute data across multiple databases: • One database per suffix.
Three databases are added to store the data contained in separate suffixes. This division of the tree corresponds to three databases. Database one contains the data for ou=people plus the data for dc=example,dc=com, so that 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.
DB1 contains people with names from A to K, and DB2 contains people with names from L to Z. DB3 contains the ou=groups data, and DB4 contains the ou=contractors data. Custom distribution plug-in distributes data from a single suffix across multiple databases. Contact HP Professional Services for information on how to create distribution logic for Directory Server. Creating a new database for an existing suffix using the console 1. 2. 3. In the Directory Server Console, select the Configuration tab.
The Create database in field is automatically filled with the default database directory (/var/opt/dirsrv/slapd-instance_name/db) and the name of the new database. It is also possible to enter or browse for a different directory location. Creating a new database for a single suffix from the command line Use the ldapmodify command line utility to add a new database to the directory configuration file. This utility is located at /opt/dirsrv/bin directory.
NOTE: After entries have been distributed, they cannot be redistributed. The following restrictions apply: • The distribution function cannot be changed after 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.
Adding the custom distribution function to a suffix using the command line 1. Run ldapmodify. The ldapmodify tool is located in the /opt/dirsrv/bin directory. ldapmodify -D "cn=directory manager" -w secret -p 389 -h server.example.com 2.
5. Select the database is read-only checkbox. The change takes effect immediately. Before importing or restoring the database, ensure that the databases affected by the operation are not in read-only mode. To disable read-only mode, open the database up in the Directory Server Console again and uncheck the database is read-only checkbox. Making a database read-only from the command line To manually place a database into read-only mode: 1. Run ldapmodify.
3. 4. Select the Make Entire Server Read-Only checkbox. Click Save, then restart the server. Deleting a database Deleting a database deletes the configuration information and entries for that database only, not the physical database itself. 1. In the Directory Server Console, select the Configuration tab. 2. Expand the Data folder, then select the suffix. 3. Select the database to delete. 4. Right-click the database and select Delete from the pop-up menu.
5. Confirm that the database should be deleted in the Delete Database dialog box. Configuring transaction logs for frequent database updates When the server is going to be asked to perform frequent database updates (LDAP adds, modifies, replication), the database transaction log files should be configured to be on a different disk than the primary database files.
Database encryption The Directory Server offers a number of mechanisms to secure access to sensitive data, such as access control rules to prevent unauthorized users from reading certain entries or attributes within entries and SSL to protect data from eavesdropping and tampering on untrusted networks. However, if a copy of the server's database files should fall into the hands of an unauthorized person, they could potentially extract sensitive information from those files.
Encryption ciphers The encryption cipher is configurable on a per-attribute basis and must be selected by the administrator at the time encryption is enabled for an attribute. Configuration can be done through the Console or through the command line. The following ciphers are supported: • Advanced Encryption Standard (AES) • Triple Data Encryption Standard (3DES) All ciphers are used in Cipher Block Chaining mode.
NOTE: For existing attribute values to be encrypted, the information must be exported from the database, then re-imported. See “Exporting and importing an encrypted database” (page 52). 5. 50 Select which encryption cipher to use.
NOTE: The encryption cipher to use is set separately for each attribute, so attribute encryption is applied to each attribute one at a time. To remove encryption from attributes, select them from the list of encrypted attributes in the Attribute Encryption table, and click the Delete button, then click Save to apply the changes. Any deleted attributes have to be manually re-added after saving. Configuring database encryption using the command line 1.
For more information on database encryption configuration schema, see "Database Attributes under cn=attributeName,cn=encrypted attributes,cn=database_name,cn=ldbm database,cn=plugins,cn=config" in the HP-UX Directory Server configuration, command, and file reference. Exporting and importing an encrypted database Exporting and importing encrypted databases is similar to exporting and importing regular databases.
• “Tuning database link performance” (page 73) • “Configuring cascading chaining” (page 77) Creating a new database link The basic database link configuration requires four pieces of information: • Suffix information A suffix is created in the directory tree that is managed by the database link, not a regular database. This suffix corresponds to the suffix on the remote server that contains the data.
4. 5. 54 Fill in the database link name. The name can be a combination of alphanumeric characters, dashes (-), and underscores (_). No other characters, like spaces, are allowed. Set the radio button for the appropriate method for authentication.
There are four authentication methods: • Simple The server connects over the standard port with no encryption. The only required information is the bind DN and password for the user as whom the server connects to the remote server. • Server TLS/SSL Certificate This uses the local server's SSL certificate to authenticate to the remote server.
NOTE: When the database link and remote server are configured to communicate using SSL, this does not mean that the client application making the operation request must also communicate using SSL. The client can bind using a normal port. • SASL/DIGEST-MD5 This requires the standard port to connect to the server. Like simple authentication, this requires only the bind DN and password to authenticate.
NOTE: 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. 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.
database,cn=plugins,cn=config. For more information about configuration attributes, see the HP-UX Directory Server configuration, command, and file reference.
The database link on Server A binds to Server B using a special user as defined in the nsMultiplexorBindDN attribute and a user password as defined in the nsMultiplexorCredentials attribute. In this example, Server A uses the following bind credentials: nsMultiplexorBindDN: cn=proxy admin,cn=config nsMultiplexorCredentials: secret Server B must contain a user entry corresponding to the nsMultiplexorBindDN, and set the proxy authentication rights for this user.
Providing an LDAP URL On the server containing the database link, identify the remote server that the database link connects with using an LDAP URL. Unlike the standard LDAP URL format, the URL of the 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=configentry of the configuration file. nsFarmServerURL: ldap://example.
For example, to use a standard connection or TLS/SSL connection: nsUseStartTLS: off There are four different methods that the local server can use to authenticate to the farm server. • empty If there is no bind mechanism set, then the server performs simple authentication and requires the nsMultiplexorBindDn and nsMultiplexorCredentials attributes to give the bind information. • EXTERNAL This uses an SSL certificate to authenticate the farm server to the remote server.
Summary of database link configuration attributes The following table lists the attributes available for configuring a database link. Some of these attributes were discussed in the earlier sections. All instance attributes are defined in the cn=database_link, cn=chaining database,cn=plugins,cn=config entry. Values defined for a specific database link take precedence over the global attribute value.
1. Run ldapmodify to add a database link to Server A: ldapmodify -a -D "cn=directory manager" -w secret -p 389 -h server.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: c=africa,ou=people,dc=example,dc=com nsfarmserverurl: ldap://africa.example.
The second entry creates a new suffix, allowing the server to route requests made to the new database link. The cn attribute contains the same suffix specified in the nsslapd-suffix attribute of the database link. The nsslapd-backend attribute contains the name of the database link. The nsslapd-parent-suffix attribute specifies the parent of this new suffix, "ou=people,dc=example,dc=com". 3.
The following table lists component names, the potential side-effects of allowing them to chain internal operations, and the permissions they need in the ACI on the remote server: Table 4 Components allowed to chain Component name Description Permissions ACI plug-in This plug-in implements access control. Read, search, and compare Operations used to retrieve and update ACI attributes are not chained because it is not safe to mix local and remote ACI attributes.
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. For further information on the limitations surrounding ACIs and chaining, see “ACI limitations” (page 234).
6. Restart the server in order for the change to take effect. After allowing the component to chain, create an ACI in the suffix on the remote server to which the operation will be chained. For example, this creates an ACI for the Referential Integrity plug-in: aci: (targetattr "*")(target="ldap:///ou=customers,l=us,dc=example,dc=com") (version 3.
• Managed DSA Returns smart referrals as entries, rather than following the referral, so the smart referral itself can be changed or deleted. • Loop detection 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 “Detecting loops” (page 82).
6. Click Save. Chaining LDAP controls from the command line Alter the controls that the database link forwards by changing the nsTransmittedControls attribute of the cn=config,cn=chaining database, cn=plugins,cn=config entry. For example, to forward the virtual list view control, add the following to the database link entry in the configuration file: nsTransmittedControls: 2.16.840.1.113730.3.4.
4. Change the connection information. • The LDAP URL for the remote server. (Unlike the standard LDAP URL format, the URL of the remote server does not specify a suffix. It has the form ldap://hostname:port/.) • The bind DN and password used by the database link to bind to the remote server.
3. Fill in the new configuration parameters. NOTE: Changes made to the default settings of a database link are not applied retroactively. Only the database links created after changes are made to the default settings will reflect the changes. Deleting database links To delete a database link, right-click the database link, and select Delete from the pop-up menu. Confirm the delete when prompted. 1. In the Directory Server Console, select the Configuration tab. 2.
Database links and access control evaluation When a user binds to a server containing a database link, the database link sends the user's identity to the remote server. Access controls are always evaluated on the remote server. Every LDAP operation evaluated on the remote server uses the original identity of the client application passed via the proxied authorization control.
NOTE: Directory Server supports both IPv4 and IPv6 IP addresses. The following restrictions apply to the ACIs used with database links: • ACIs must be located with any groups they use. If the groups are dynamic, all users in the group must be located with the ACI and the group. If the group is static, it may refer to remote users. • ACIs must be located with any role definitions they use and with any users intended to have those roles.
2. 74 Click the Limits and Controls tab in the right navigation pane.
3. In the Connection Management section, make changes to any of the following fields: • Maximum TCP connection(s) The maximum number of TCP connections that the database link establishes with the remote server. The default value is 3 connections. • Bind timeout Amount of time, in seconds, before the database link's bind attempt times out. The default value is 15 seconds. • Maximum binds per connection Maximum number of outstanding bind operations per TCP connection.
for an unspecified time or closed after a specific period of time. It is faster to keep the connections open, but it uses more resources. For slow connections, it may be desirable to limit the connection time. A value of 0 indicates there is no limit. By default, the value is set to 0. Managing connections to the remote server from the command line Use ldapmodify to add connection attributes to the database link entry.
After the nsMaxResponseDelay period has been met, the database link pings the remote server. During the ping, the database link issues another LDAP request, a simple search request for an object that does not exist in the remote server. The duration of the ping is set using the nsMaxTestResponseDelay. If the remote server does not respond before the nsMaxTestResponseDelay period has passed, then an error is returned, and the connection is flagged as down.
• “Summary of cascading chaining configuration attributes” (page 83) • “Cascading chaining configuration example” (page 83) Overview of cascading chaining Cascading chaining occurs when more than one hop is required for the directory to process a client application's request. The client application sends a modify request to Server 1. Server one contains a database link that forwards the operation to Server 2, which contains another database link.
The root suffix dc=example,dc=com and 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.
2. 3. 80 Click the Limits and Controls tab in the right navigation pane. Select the Check local ACI checkbox to enable the evaluation of local ACIs on the intermediate database links involved in the cascading chain. Selecting this checkbox may require adding the appropriate local ACIs to the database link.
4. Enter the maximum number of times a database link can point to another database link in the Maximum hops field. By default, the maximum is ten hops. After ten hops, a loop is detected by the server, and an error is returned to the client application. Configuring cascading chaining from the command line To configure a cascade of database links through the command line: 1. Point one database link to the URL of the server containing the intermediate database link.
and pass a proxy authorization control allowing them more administrative privileges than appropriate. The proxy ACI prevents this security breach. a. Create a database, if one does not already exist, on the server containing the intermediate database link. This database will contain the admin user entry and the ACI. For information about creating a database, see “Creating databases” (page 39). b. Create an entry that corresponds to the administrative user in the database. c.
The number of hops allowed is defined using the nsHopLimit attribute. If not specified, the default value is 10. To use the control, add the following OID to the nsTransmittedControl attribute in the cn=config,cn=chaining database,cn=plugins,cn=config entry: nsTransmittedControl: 1.3.6.1.4.1.1466.29539.12 If the control is not present in the configuration file of each database link, loop detection will not be implemented.
• “Configuring Server One” (page 84) • “Configuring Server Two” (page 85) • “Configuring Server Three” (page 87) Configuring Server One 1. Run ldapmodify: ldapmodify -a -D "cn=directory manager" -w secret -p 389 -h server.example.com 2.
nsfarmserverurl: ldap://africa.example.com:389/ nsmultiplexorbinddn: cn=server1 proxy admin,cn=config nsmultiplexorcredentials: secret cn: DBLink1 nsCheckLocalACI:off dn: cn="c=africa,ou=people,dc=example,dc=com",cn=mapping tree,cn=config objectclass: nsMappingTree nsslapd-state: backend nsslapd-backend: DBLink1 nsslapd-parent-suffix: "ou=people,dc=example,dc=com" cn: c=africa,ou=people,dc=example,dc=com The first section creates the entry associated with DBLink1.
nsslapd-parent-suffix: "c=africa,ou=people,dc=example,dc=com" cn: l=Zanzibar,c=africa,ou=people,dc=example,dc=com Because database link DBLink2 is the intermediate database link in the cascading chaining configuration, set the nsCheckLocalACI attribute to on to allow the server to check whether it should allow the client and proxy administrative user access to the database link. 3. The database link on Server 2 must be configured to transmit the proxy authorization control and the loop detection control.
aci:(targetattr="*")(target="l=Zanzibar,c=africa,ou=people,dc=example,dc=com") (version 3.0; acl "Client authorization for database links"; allow (all) userdn = "ldap:///uid=*,c=us,ou=people,dc=example,dc=com";) This ACI allows clients that have a UID in c=us,ou=people,dc=example,dc=com on Server 1 to perform any type of operation on the l=Zanzibar,c=africa,ou=people,dc=example,dc=com suffix tree on server three.
Starting the server in referral mode Referrals are used to redirect client applications to another server while the current server is unavailable or when the client requests information that is not held on the current server. For example, starting Directory Server in referral mode while there are configuration changes being made to the Directory Server will refer all clients to another supplier while that server is unavailable. Starting the Directory Server in referral mode is done with the refer option.
Enter multiple referral URLs separated by spaces and in quotes: "ldap://dir1.example.com:389/dc=example,dc=com" "ldap://dir2.example.com/" For more information about LDAP URLs, see “LDAP URLs” (page 571). Setting a default referral from the command line The ldapmodify command can add a default referral to the cn=config entry in the directory's configuration file. For example, to add a new default referral from one Directory Server, dir1.example.com, to a server named dir2.example.
4. 90 Select the Enable Smart Referral option. (Unchecking the option removes all smart referrals from the entry and deletes the referral object class from the entry.
5. In the Enter a new Smart Referral field, enter a referral in the LDAP URL format, then click Add. The LDAP URL must be in the following format: ldap://hostname:portnumber/[optional_dn] optional_dn is the explicit DN for the server to return to the requesting client application.
To open a wizard to direct the process of adding a referral, click Construct. The Smart Referral List lists the referrals currently in place for the selected entry. The entire list of referrals is returned to client applications in response to a request with the Return Referrals for All Operations or Return Referrals for Update Operations options in the Suffix Settings tab, which is available under the Configuration tab.
7. Click OK. Creating smart referrals from the command line Use the ldapmodify command line utility to create smart referrals from the command line. To create a smart referral, create the relevant directory entry, and add the referral object class. This object class allows a single attribute, ref. The ref attribute must contain an LDAP URL.
objectclass: inetOrgPerson objectclass: referral cn: john doe sn: doe uid: jdoe ref: ldap://directory.europe.example.com/cn=john%20doe,ou=people, l=europe,dc=example,dc=com Use the -M option with ldapmodify when there is already a referral in the DN path. For information about the ldapmodify utility, see the HP-UX Directory Server configuration, command, and file reference. Creating suffix referrals The following procedure describes creating a referral in a suffix.
replicated across several servers. Enabling referrals for that Directory Server only for update requests means that when a client asks to update an entry, the client is referred to the server that owns the data, where the modification request can proceed. 4. Click the Referrals tab. Enter an LDAP URL in the Enter a new referral field, or click Construct to create an LDAP URL. For more information about the structure of LDAP URLs, see “LDAP URLs” (page 571). 5. Click Add to add the referral to the list.
The nsslapd-state attribute can also be set to referral on update. This means that the database is used for all operations except update requests. When a client application makes an update request to a suffix set to referral on update, the client receives a referral. For more information about the suffix configuration attributes, see Table 2 (page 37).
3 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; For more information on adding or modifying synchronized entries through Windows User Sync, see “Synchronizing Directory Server with Microsoft Active Directory” (page 392).
3. Fill in the new suffix and database information. 4. 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 the new suffixes without a corresponding entry. Choose the suffix corresponding to the entry to create. 5. In the New Object window, select the object class corresponding to the new entry. The object class must contain the attribute used to name the suffix. For example, if the entry corresponds to the suffix ou=people,dc=example,dc=com, then choose the organizationalUnit object class or another object class that allows the ou attribute. 6.
Table 9 Entry templates and corresponding object classes (continued) Template Object Class Organizational Unit organizationalUnit Role nsRoleDefinition Class of Service cosSuperDefinition Another type, Other allows any kind of entry to be created by allowing users to select the specific object classes and attributes to apply. 1. In the Directory Server Console, select the Directory tab. 2.
5. To display the full list of attributes available for the object class (entry type), click the Advanced button.
In the Property Editor, select any additional attributes, and fill in the attribute values. 6. Click OK to save the entry. The new entry is listed in the right pane. Modifying directory entries Modifying directory entries in Directory Server Console uses a dialog window called the Property Editor.
The Property Editor can be opened in several ways: • From the Directory tab, by right-clicking an entry, and selecting Advanced Properties from the pop-up menu. • From the Directory tab, by double-clicking an entry and clicking the Advanced button • From the Create... new entry forms, by clicking the Advanced button • From the New Object window, by clicking OK Adding or removing an object class to an entry To add an object class to an entry: 1.
The Add Object Class window opens. It shows a list of object classes that can be added to the entry. 3. Select the object class to add, and click OK.
To remove an object class from an entry, click the text box for the object class to remove, then click Delete Value. Adding an attribute to an entry Before you can add an attribute to an entry, the entry must contain an object class that either requires or allows the attribute. See “Adding or removing an object class to an entry” (page 103) and “Managing the Directory Schema” (page 428) for more information. To add an attribute to an entry: 1.
2. Click Add Attribute. 3. Select the attribute to add from the list, and click OK.
NOTE: If the attribute you want to add is not listed, add the object class containing the attribute first, then add the attribute. See “Adding or removing an object class to an entry” (page 103) for instructions on adding an object class. If you do not know which object class contains the attribute you need, look up the attribute in the HP-UX Directory Server schema reference, which lists the object classes that use that attribute. 4.
To remove the attribute and all its values from the entry, select Delete Attribute from the Edit menu. Adding very large attributes The configuration attribute nsslapd-maxbersize sets the maximum size limit for LDAP requests. The default configuration of Directory Server sets this attribute at 2 megabytes. LDAP add or modify operations will fail when attempting to add very large attributes that result in a request that is larger than 2 megabytes.
Adding and removing attribute values Multivalued attributes allow multiple value for one attribute to be added to an entry. 1. In the Directory tab of the Directory Server Console, right-click the entry to modify, and select Advanced from the pop-up menu. 2. Select the attribute to which to add a value, then click Add Value. 3. Type in the new attribute value. To remove an attribute value from an entry, click the text box of the attribute value to remove, and click Delete Value.
Language subtype Sometimes a user's name can be more accurately represented in characters of a language other than the default language. For example, a user, Noriko, has a name in Japanese and prefers that her name be represented by Japanese characters when possible. You can select Japanese as a language subtype for the givenname attribute so that other users can search for her name in Japanese as well as English.
cn;lang-ja:ja-value cn;lang-en-GB:value Binary subtype Assigning the binary subtype to an attribute indicates that the attribute value is binary, such as user certificates (usercertificate;binary). 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.
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. For example, you might want to ensure that it returns the expected information after you have made changes to access control information. With command line utilities, information can be provided directly from the command line or through an LDIF input file.
Creating a root entry from the command line The ldapmodify command line utility can be used to create a new root entry in a database. For example: ldapmodify -a -D "cn=directory manager" -w secret -p 389 -h server.example.com The ldapmodify utility binds to the server and prepares it to add an entry. The new root object can then be added, as follows: dn: Suffix_Name objectclass: newobjectclass The DN corresponds to the DN of the root or sub-suffix contained by the database.
NOTE: To create the root entry a database suffix (such as dc=example,dc=com) using ldapmodify, you must bind to the directory as the Directory Manager. Adding entries using ldapmodify Typically, to add the entries using ldapmodify, specify the DN and password to bind to the Directory Server, the port and host of the Directory Server, and the LDIF file to use. For example: ldapmodify -a -D "cn=directory manager" -w secret -p 389 -h server.example.com -f new.
• The host name is example.com. • The server uses port number 389. Table 11 (page 115) describes the ldapmodify options used in the example. Table 11 ldapmodify options used for modifying entries Option 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.
Table 12 ldapdelete options used for deleting entries Option 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. -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.
The USN is not entry specific. The USN counter tracks the USN globally for the entire database. Configuring the USN plug-in: USN plug-in is disabled by default. To track the entry changes by USNs, enable the USN plug-in as follows: ldapmodify -D "cn=directory manager" -w secret -p 389 -h server.example.com dn: cn=USN,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on After the changes, restart the server to apply the changes.
Example 1 Case 1: nsslapd-entryusn-import-initval: 123 ldif2db -n backend -i /path/to/ldif The entryusn value for the imported entries will be set to 123. ldapsearch -b "dc=example,dc=com" "(objectclass=*)" entryusn dn: dc=example,dc=com entryusn: 123 dn: ou=Accounting,dc=example,dc=com entryusn: 123 dn: ou=Product Development,dc=example,dc=com entryusn: 123 ... entryusn: 123 Example 2 Case 2: nsslapd-entryusn-import-initval: next The last entryusn value is 9.
Table 13 usn-tombstone-cleanup.pl Options: (continued) Options Description -n backend Backend instance in which USN tombstone entries are cleaned up (alternative to suffix). -w Specifies the password of the administrative user. With replication: entryusn attribute is local to the server. Thus, if an entry is added to Server A the entry is replicated to Server B, but the two entries have different entryusn value.
The server adds the creatorsName, createTimestamp, modifiersName, and modifyTimestamp attributes to every newly created or modified entry. 4. Open the Tasks tab, and click Restart Directory Server.
NOTE: The Directory Server must be restarted for the changes to take effect. LDIF Update Statements LDIF update statements define how ldapmodify changes the directory entry. In general, LDIF update statements contain the following information: • The DN of the entry to be modified. • 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 option.
dn: distinguished_name changetype: changetype_identifier change_operation_identifier: list_of_attributes change_operation_identifier: list_of_attributes A dash (-) must be used to denote the end of a change operation if subsequent change operations are specified.
cn: Sue Jacobs givenName: Sue sn: Jacobs ou: People ou: Marketing uid: sjacobs dn: ou=Groups,dc=example,dc=com changetype: add objectclass: top objectclass: organizationalUnit ou: Groups dn: cn=Administrators,ou=Groups,dc=example,dc=com 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.
dn: cn=Sue Jacobs,ou=Marketing,dc=example,dc=com changetype: modrdn newrdn: cn=Susan Jacobs deleteoldrdn: 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, then delete the old entry.
dn: cn=Barney Fife,ou=People,dc=example,dc=com changetype: modify add: telephonenumber telephonenumber: 555-1212 The following example adds two telephone numbers to the entry: dn: cn=Barney Fife,ou=People,dc=example,dc=com changetype: modify add: telephonenumber telephonenumber: 555-1212 telephonenumber: 555-6789 The following example adds two telephonenumber attributes and a manager attribute to the entry: dn: cn=Barney Fife,ou=People,dc=example,dc=com changetype: modify add: telephonenumber telephonenum
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 objectClass: inetOrgPerson cn: Bar
Deleting an entry using LDIF changetype: delete is the change type that deletes an entire entry from the directory. NOTE: You can only delete leaf entries. Therefore, when you delete an entry, make sure that no other entries exist under that entry in the directory tree. That is, you cannot delete an organizational unit entry unless you have first deleted all the entries that belong to the organizational unit.
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.
3. Check the Enable plugin checkbox to enable the plug-in; clear it to disable it.
4. 5. Fill in the correct path to the plug-in by default; plug-ins are located in /opt/dirsrv/lib/ plugins Restart the Directory Server to apply the changes. In the Tasks tab, select Restart the Directory Server.
Modifying the update interval By default, the server makes referential integrity updates immediately after a delete or a modrdn operation. To reduce the impact this operation has on your system, increase the amount of time between updates.
3. Restart the Directory Server to apply the changes. In the Tasks tab, select Restart the Directory Server. Modifying the attribute list By default, the Referential Integrity Plug-in is set up to check for and update the member, uniquemember, owner, and seeAlso attributes. You can add or delete attributes to be updated through the Directory Server Console, such as adding the nsroledn attribute if roles are being used.
3. Restart the Directory Server to apply the changes. In the Tasks tab, select Restart the Directory Server. NOTE: All attributes used in referential integrity must be indexed for presence and equality; not indexing those attributes results poor server performance for modify and delete operations. For more information about checking and creating indexes, see “Creating indexes” (page 455).
For multi-master replication, each supplier can be configured with a threshold, so that when it begins running out of numbers in its range, it can request additional ranges from other suppliers. Each supplier keeps a track of its current range in a separate configuration entry. The configuration entry is replicated to all the other suppliers, so each supplier can check that configuration to find a server to contact for a new range.
with that number, and the entry is within the scope and filter of the configured DNA Plug-in, then using the magic number automatically triggers the plug-in to generate a new value. For example: ldapmodify -a -D "cn=directory manager" -w secret -p 389 -h server.example.com dn: uid=jsmith, ou=people, dc=example,dc=com objectClass: top objectClass: person objectClass: posixAccount uid: jsmith cn: John Smith uidNumber: magic ....
dnatype: uidNumber dnafilter: (objectclass=posixAccount) dnascope: ou=people, dc=example,dc=com dnaNextValue: 1 If multiple suppliers are configured for distributed numeric assignments, then the entry must contain the required information to transfer ranges: • The maximum number that the server can assign; this sets the upward bound for the range, which is logically required when multiple servers are assigning numbers. This is set in the dnaMaxValue attribute.
Table 14 DNA entry attributes (continued) Plug-in attribute Description dnaNextRange Shows the next range of numbers that are available to be transferred. This attribute can be set automatically by the plug-in according to the threshold and shared configuration information; this can also be set manually for an administrator to specifically assign an additional range of values to a server.
dnaRangeRequestTimeout: 60 dnaMagicRegen: magic 4. Restart the server to load the new plug-in instance. /opt/dirsrv/slapd-instance_name/restart-slapd Editing the DNA plug-in in the console The 1. 2. 3. 138 Directory Server Console can be used to edit the DNA Plug-in instances. Click the Directory tab. Open the config folder, then expand the plugins folder. Click the Distributed Numeric Assignment plug-in folder. All the DNA Plug-in instances are listed in the main window.
4. 5. Highlight the DNA instance entry, and right-click on the Advanced link to open the property editor. Edit the DNA-related attributes. Enforcing Attribute Uniqueness Attribute uniqueness means that the Directory Server requires that all new or edited attributes always have unique values. Attribute uniqueness is enforced through a plug-in. A new instance of the Attribute Uniqueness Plug-in must be created for every attribute for which values must be unique.
uid=jdoe,ou=people,o=example_a,dc=example,dc=com is added, uniqueness needs to be enforced only in the o=example_a,dc=example,dc=com subtree. This is done by listing the DN of the subtree explicitly in the Attribute Uniqueness Plug-in configuration. • Specify an object class pertaining to an entry in the DN of the updated entry and perform the uniqueness check on all the entries beneath it. This option is useful in hosted environments.
nsslapd-pluginarg0: attribute=attribute_name nsslapd-pluginarg1: markerObjectClass=objectclass1 nsslapd-pluginarg2: requiredObjectClass=objectclass2 ... • Any value can be given to the cn attribute to name the plug-in. The name should be descriptive. • The cn attribute does not contain the name of the attribute, which is checked for uniqueness. • Only one attribute can be specified on which the uniqueness check will be performed.
1. Stop the Directory Server. Changes to the dse.ldif file are not saved if it is edited while the server is running. /opt/dirsrv/slapd-instance_name/stop-slapd 2. 3. 4. 5. In the dse.ldif file, locate the entry for the Attribute Uniqueness Plug-in, cn=attribute uniqueness,cn=plugins,cn=config. Copy the entire entry. The entry ends in an empty line; copy the empty line, too. Paste the copied Attribute Uniqueness Plug-in entry at the end of the file.
Specifying a suffix or subtree The suffix or subtrees that the plug-in checks to ensure attribute uniqueness are defined using the nsslapd-pluginarg attribute in the entry defining the plug-in. To specify the subtree or subtrees, use ldapmodify to send LDIF update statements, similar to this example: ldapmodify -D "cn=directory manager" -w secret -p 389 -h server.example.
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. NOTE: The nsslapd-pluginarg0 attribute always contains the name of the attribute for which to ensure uniqueness. Attribute uniqueness plug-in syntax examples This section contains examples of Attribute Uniqueness Plug-in syntax in the dse.ldif file.
Replication and the attribute uniqueness plug-in When using the Attribute Uniqueness Plug-ins on Directory Servers involved in a replication agreement, carefully consider how to configure the plug-in on each server. Consider the following cases: • Simple replication with one supplier and one or several consumers. • Complex replication with multiple masters. Attribute Uniqueness Plug-ins do not perform any checking on attribute values when an update is performed as part of a replication operation.
modified. With the subtree rename feature, entries in the primary db file have just the RDN and a special tree structured index file is created, called entryrdn.db4 for entry id look up. In the dse.ldif configuration file, the backend configuration entry cn=config,cn=ldbm database,cn=plugins,cn=config has a switch called nsslapd-subtree-rename-switch as follows: dn: cn=config,cn=ldbm database,cn=plugins,cn=config [...
Here newrdn - specifies the new RDN of the entry deleteoldrnd - specifies whether the old RDN has to be deleted or not. If it is 0 old RDN is retained and if non-zero the old RDN is deleted. Moving an Entry to a New Parent Moving an entry to a new parent requires setting two attributes: newrdn and newSuperior: ldapmodify -D "cn=directory manager" -w secret -p 389 -h server.example.
4 Populating Directory Databases Databases contain the directory data managed by the HP-UX Directory Server. Topics include: • “Importing data” (page 148) • “Exporting data” (page 155) • “Backing up and restoring data” (page 160) 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 the databases, including database links.
Importing a database from the console When performing an import operation from the Directory Server Console, an ldapmodify operation is executed to append data, as well as to modify and delete entries. The operation is performed on all the databases managed by the Directory Server and on remote databases to which the Directory Server has a configured database link. You must be logged in as the Directory Manager in order to perform an import. To import data from the Directory Server Console: 1.
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 that will contain the rejects.
Alternatively, 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. If the Console is running from a machine remote to the server containing the LDIF file, select one of the following options, then click OK: • From local machine Indicates that the LDIF file is located on the local machine. • From server machine Indicates that the LDIF file is located on a remote server. The default LDIF directory is /var/opt/dirsrv/slapd-instance_name/ldif.
By default, the script first saves then merges any existing o=NetscapeRoot configuration information with the o=NetscapeRoot configuration information in the files being imported. CAUTION: This script overwrites the data in the database whether the command is successful or not. To import LDIF: 1. Stop the server. For more information about the command to start and stop the HP-UX Directory Server, see“Starting and Stopping Servers” (page 20). /opt/dirsrv/slapd-instance_name/stop-slapd 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 whether the command is successful or not. 1. Run the ldif2db.pl script. /opt/dirsrv/slapd-instance_name/ldif2db.pl -D "cn=Directory Manager" -w secret \ -I /var/opt/dirsrv/slapd-instance_name/ldif/demo.
This task entry requires three attributes: • A unique name (cn) • The file name of the LDIF file to import (nsFilename) • The name of the database into which to import the file (nsInstance) It is also possible to supply the DNs of suffixes to include or exclude from the import, analogous to the -s and -x options, respectively, for the ldif2db and ldif2db.pl scripts. The entry is simply added using ldamodify, as described in “Adding and modifying entries using ldapmodify” (page 113).
Figure 6 Splitting a database contents into two databases The Directory Server Console or command line utilities can be used to export data. • “Exporting directory data to LDIF using the console” (page 156) • “Exporting a single database to LDIF using the console” (page 157) • “Exporting to LDIF from the command line” (page 159) CAUTION: Do not stop the server during an export operation.
Browse is not enabled if the Console is running on a remote server. When the Browse button is not enabled, the file is stored in the default directory, /var/opt/dirsrv/slapd-instance_name/ldif. (For a list of Directory Server file locations, see “Directory Server file Locations” (page 19).) 3. 4. If the Console is running on a machine remote to the server, two radio buttons are displayed beneath the LDIF File field.
Alternatively, select Export Database from the Object menu. 4. In the LDIF file field, enter the full path to the LDIF file, or click Browse. When the Browse button is not enabled, the file is stored in the default directory, /var/opt/dirsrv/slapd-instance_name/ldif.
Exporting to LDIF from the command line There are three methods for exporting data through the command line: • Using db2ldif This method runs the command-line utility; unlike the import script, ldif2db, this utility can be run while the server is running. • Using db2ldif.pl This Perl script behaves the same as the db2ldif command-line utility and takes the same options. • Creating a cn=tasks entry This method creates a temporary task entry that automatically launches an export operation.
Table 19 db2ldif options Option Description -n Specifies the name of the database from which the file is being exported. -s Specifies the suffix or suffixes to include in the export. If the suffix is a root suffix, such as dc=example,dc=com, then the -n option is not required. There can be multiple -s arguments. -a Defines the output file to which Directory Server exports the LDIF. This file must be an absolute path.
• “Restoring all databases” (page 163) • “Restoring a single database” (page 165) • “Restoring databases that include replicated entries” (page 165) • “Restoring the dse.ldif configuration file” (page 166) CAUTION: Do not stop the server during a backup or restore operation. Backing up all databases The following procedures describe backing up all the databases in the directory using the Directory Server Console and from the command line.
Backing up all databases from the command line Databases can be backed up from the command line using the db2bak command line script. This script works when the server is running or when the server is stopped. Configuration information cannot be backed up using this backup method. For information on backing up the configuration information, see “Backing up all databases from the command line” (page 162). To back up the directory from the command line using the db2bak script: 1.
Restoring all databases The following procedures describe restoring all the databases in the directory using the Directory Server Console and from the command line. NOTE: While restoring databases, the server must be running. However, the databases will be unavailable for processing operations during the restore. Restoring all databases from the console If the databases become corrupted, restore data from a previously generated backup using the Directory Server Console.
Restoring your database from the command line There are three ways to restore databases from the command line: • Using the bak2db command line script. This script requires the server to be shut down. • Using the bak2db.pl Perl script. This script works while the server is running. • Creating a temporary entry under cn=restore, cn=tasks, cn=config. This method can also be run while the server is running. Using the bak2db command line script To restore the directory from the command line: 1.
nsArchiveDir: /home/backups/ nsDatabaseType: ldbm database As soon as the task is completed, the entry is removed from the directory configuration. The HP-UX Directory Server configuration, command, and file reference has more information on the available attributes for running database restore tasks under the cn=tasks entries. Restoring a single database It is possible to restore a single database through the command line, but not in the Directory Server Console. To restore a single database: 1.
Restoring the dse.ldif configuration file The directory creates two backup copies of the dse.ldif file in the /etc/opt/dirsrv/slapd-instance_name directory. The dse.ldif.startOK file records a copy of the dse.ldif file at server start up. The dse.ldif.bak file contains a backup of the most recent changes to the dse.ldif file. Use the version with the most recent changes to restore the directory. To restore the dse.ldif configuration file: 1. Stop the server.
5 Organizing 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. HP-UX 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.
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. However, evaluating roles is more resource-intensive for the Directory Server than evaluating groups because the server does the work for the client application.
Managing roles using the console This section contains the following procedures for creating and modifying roles: • “Creating a managed role” (page 169) • “Creating a filtered role” (page 172) • “Creating a nested role” (page 175) • “Viewing and editing an entry's roles” (page 178) • “Modifying a role entry” (page 180) • “Making a role inactive or active” (page 182) • “Deleting a role” (page 184) When a role is created, determine whether a user can add themselves or remove themselves from the
Alternatively, right-click the entry and select New→Role. 170 4. Click General in the left pane. Type a name for the new role in the Role Name field. The role name is required. 5. 6. 7. Enter a description of the new role in the Description field. Click Members in the left pane. In the right pane, select Managed Role. Click Add to add new entries to the list of members.
8. In the Search drop-down list, select Users from the Search drop-down list, then click Search. Select one of the entries returned, and click OK. 9. After adding all the entries, click OK.
NOTE: The nsRoleDN attribute is an operational attribute and must be explicitly requested in the search command in the list of search attributes. For example: ldapsearch ... args ... “(uid=scarter)” \* nsRole nsRoleDN The Console will automatically show the nsRoleDN attribute. Creating a filtered role Entries are assigned to a filtered role depending whether the entry possesses a specific attribute defined in the role. The role definition specifies an LDAP filter for the target attributes.
5. 6. Enter a description of the new role in the Description field. Click Members in the left pane. A search dialog box appears briefly. 7. In the right pane, select Filtered Role.
8. Enter an LDAP filter in the text field, or click Construct to be guided through the construction of an LDAP filter. The Construct opens the standard LDAP URL construction dialog. Ignore the fields for LDAP Server Host, Port, Base DN, and Search (because the search scope cannot be set filtered role definitions). • Select the types of entries to filter from the For drop-down list. The entries can be users, groups, or both. • 174 Select an attribute from the Where drop-down list.
does not contain, is, or is not. Enter an attribute value in the text box. To add additional filters, click More. To remove unnecessary filters, click Fewer. • 9. Click OK. Click Test to try the filter. 10. Click OK. NOTE: The nsRoleDN attribute is an operational attribute and must be explicitly requested in the search command in the list of search attributes. For example: ldapsearch ... args ... “(uid=scarter)” \* nsRole nsRoleDN The Directory Server Console automatically shows the nsRoleDN attribute.
To create and add members to a nested role: 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. 4. 176 Alternatively, right-click the entry and select New→Role. Click General in the left pane. Type a name for the new role in the Role Name field. The role name is required.
5. 6. Click Members in the left pane. In the right pane, select Nested Role.
7. 8. Click Add to add roles to the list. The members of the nested role are members of other existing roles. Select a role from the Available roles list, and click OK. NOTE: The nsRoleDN attribute is an operational attribute and must be explicitly requested in the search command in the list of search attributes. For example: ldapsearch ... args ... “(uid=scarter)” \* nsRole nsRoleDN The Console will automatically show the nsRoleDN attribute.
4. Select the Managed Roles tab to display the managed roles to which this entry belongs. To add a new managed role, click Add, and select an available role from the Role Selector window. To edit a managed role associated with an entry, click Edit. The Edit Entry dialog box opens. Make any changes to the general information or members. 5. Select the Other Roles tab to view the filtered or nested roles to which this entry belongs.
Click Edit to make changes to any filtered or nested roles associated with the entry. Click OK. Modifying a role entry To edit an existing role: 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 are listed in the right pane with other entries. 3. Double-click the role.
4.
• General to change the role name and description. • Members to change the members of managed and nested roles or to change the filter of a filtered role. Making a role inactive or active 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: 1. In the Directory Server Console, select the Directory tab. 2.
3. Double-click the role, open the Account tab, and click the Inactivate button. Alternatively, select the role. Right-click the role and select Inactivate from the menu.
The role is inactivated. To see the inactivated entries, select Inactivation State from the View menu. Members of an inactivated role have a red slash through them. For example, T Morris is a member of the inactive Example Role. To reactivate a disabled role, re-open the role configuration or open the Object menu, and select Activate. All the members of the role are reenabled. Deleting a role Deleting a role deletes the role only, not its members. To delete a role: 1.
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 “Maintaining Referential Integrity” (page 127).
Table 20 Object classes and attributes for roles (continued) Role type Object classes Attributes nsNestedRoleDefinition Description (optional) The attributes nsRole and nsRoleDN are operational attributes. This means that they are not present in the schema of the entry and may be added to any entry, regardless of schema. This also means that these attributes must be explicitly requested in the search attributes list in search requests.
Example: filtered role definition This example creates a filtered role that is applied to all sales managers 1. Run ldapmodify: ldapmodify -D "cn=Directory Manager" -w secret -h host -p 389 2. Create the filtered role entry. The role entry has the nsFilteredRoleDefinition object class, which inherits from the LdapSubEntry, nsRoleDefinition, and nsComplexRoleDefinition object classes. The nsRoleFilter attribute sets a filter for o (organization) attributes that contain a value of sales managers.
Using roles securely Not every role is suitable for use in a security context. When creating a new role, consider how easily the role can be assigned to and removed from an entry. Sometimes it is appropriate for users to be able to add or remove themselves easily from a roles for some security situations. One potential security risk is inactivating user accounts by inactivating role.
About CoS Clients of the Directory Server read the attributes in a user's entry. With CoS, some attribute values may not be stored within the entry itself. Instead, these attribute values are generated by class of service logic as the entry is sent to the client application. Each CoS is comprised of two types of entry in the directory: • CoS definition entry The CoS definition entry identifies the type of CoS used. Like the role definition entry, it inherits from the LDAPsubentry object class.
The relative distinguished name (RDN) of the template entry is determined by one of the following: • The DN of the template entry alone. This type of template is associated with a pointer CoS definition. • The value of one of the target entry's attributes. The attribute used to provide the relative DN to the template entry is specified in the CoS definition entry using the cosIndirectSpecifier attribute. This type of template is associated with an indirect CoS definition.
Figure 8 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.
Figure 9 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. Searches for CoS-specified attributes CoS definitions provide values for attributes in entries.
attribute is indexed, as long as there is a local value for the entry. Other entries which possess the CoS but do not have a local value will still not be returned in the ldapsearch operation. Because of the potential issues with running LDAP search requests on CoS-defined attributes, take care when deciding which attributes to generate using a CoS.
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.
• Select Does not override target entry attribute to tell the directory to only return a generated value if there is no corresponding attribute value stored with the entry. • Select Overrides target entry attribute to make the value of the attribute generated by the CoS override the local value.
• By its DN To have the template entry identified by only its DN (a pointer CoS), enter the DN of the template in the Template DN field. Click Browse to locate the DN on the local server. This will be an exact DN, such as cn=CoS template,ou=People,dc=example,dc=com. • Using the value of one of the target entry's attribute To have the template entry identified by the value of one of the target entry's attributes (an indirect CoS), enter the attribute name in the Attribute Name field.
1. 2. In the Directory Server Console, select the Directory tab. Browse the tree in the left navigation pane, and select the parent entry that contains the class of service. The CoS appears in the right pane with other entries. 3. Right-click the CoS, and select New→Other. Alternatively, select the CoS in the right pane, click Object in the menu at the top, and select New→Other. 4. Select cosTemplate from the list of object classes.
NOTE: The LDAPsubentry object class can be added to a new template entry. Making the CoS template entry an instance of the LDAPsubentry object class allows ordinary searches to be performed unhindered by the configuration entries. However, if the template entry already exists and is used for something else (for example, if it is a user entry), the LDAPsubentry object class does not need to be added to the template entry. 5. Select the object classes attribute, and click Add Value.
6. Add the extensibleObject object class. This makes it possible to add any attribute available in the directory.
7. Click the Add Attribute button.
8. Add the cn attribute, and give it a value that corresponds to the attribute value in the target entry. For example, if the manager attribute is used to set the value for a classic CoS, give the cn a value of a manager's DN, such as uid=bparker,ou=people,dc=example,dc=com. Alternatively, set it to a role, such as cn=QA Role,dc=example,dc=com or a regular attribute value. For example, if the employeeType attribute is selected, it can be full time or temporary.
9. Click the Change button in the lower right corner to change the naming attribute. Use the cn of the entry as the naming attribute instead of cospriority.
10. 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. 11. 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. Templates that contain no cosPriority attribute are considered the lowest priority.
To edit the description or attributes generated on the target entry of an existing CoS, simply double-click the CoS entry listed in the Directory tab, and make the appropriate changes in the editor window. Deleting a CoS 1. 2. In the Directory Server Console, select the Directory tab. Browse the tree in the left navigation pane, and select the parent entry that contains the class of service. The CoS appears in the right pane with other entries. 3. Right-click the CoS, and select Delete.
Creating the CoS definition entry from the command line Each type of CoS requires a particular object class to be specified in the definition entry. All CoS definition object classes inherit from the LDAPsubentry object class and the cosSuperDefinition object class. A pointer CoS uses the cosPointerDefinition object class. This object class identifies the template entry using an entry DN value specified in the cosTemplateDn attribute, as shown in Example 3 “An example pointer CoS entry”.
There are four qualifiers: • default Only returns a generated value if there is no corresponding attribute value stored with the entry. • override Always returns the value generated by the CoS, even when there is a value stored with the entry. • operational Returns a generated attribute only if it is explicitly requested in the search. Operational attributes do not need to pass a schema check in order to be returned. When operational is used, it also overrides any existing attribute values.
For example, a CoS template entry that provides a value for the postalCode attribute follows: dn:cn=exampleUS,ou=data,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: cosTemplate postalCode: 44438 It is possible to create CoS templates that compete with each other to provide an attribute value. For example, there can be a multivalued cosSpecifier attribute in the CoS definition entry.
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. Example of an indirect CoS This indirect CoS uses the manager attribute of the target entry to identify the CoS template entry, which varies depending on the different values of the attribute. 1.
dn: cn=sales,cn=classicCoS,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: cosTemplate postalCode: 44438 dn: cn=marketing,cn=classicCoS,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: cosTemplate postalCode: 99111 The classic CoS definition entry applies to all entries under the dc=example,dc=com suffix. Depending upon the combination of the businessCategory attribute found in the entry and the cosTemplateDN, it can arrive at one of two templates.
objectclass: nsComplexRoleDefinition objectclass: nsFilteredRoleDefinition cn: ManagerRole nsRoleFilter: o=managers Description: filtered role for managers The classic CoS definition entry looks like: dn: cn=managerCOS,dc=example,dc=com objectclass: top objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDn: cn=managerCOS,dc=example,dc=com cosSpecifier: nsRole cosAttribute: mailboxquota override The cosTemplateDn attribute provides a value that, in combination with the attribute s
Figure 10 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 /opt/dirsrv/share/data directory. The HP-UX Directory Server deployment guide has more information on how to integrate views with the directory tree hierarchy.
4. Select nsview from the New Object menu, and click OK. 5. In the Property Editor window, click the Add Value button, and add the organization unit 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. Click the Add Attribute button, and add the nsviewfilter attribute.
8. Create a filter that reflects the views, such as .(l=Sunnyvale).
9. Click the Change button in the lower right corner to change the naming attribute. Use the ou of the entry as the naming attribute instead of description. 10. Click OK to close the attributes box, and click OK again to save the new view entry. The new view is immediately populated with any entries matching the search filter, and any new entries added to directory are automatically included in the view.
Deleting views from the Directory Server Console 1. 2. 3. 4. Select the Directory tab. Select the view to delete, such as ou=Sunnyvale,ou=LocationViews,dc=example,dc=com. To delete all the views, delete the entire sub suffix,ou=LocationViews,dc=example,dc=com. Right-click the entry, and select Delete from the drop-down menu. A dialog box appears to confirm the deletion of the entry. Click Yes. Creating views from the command line 1.
Managing static groups Static groups organize entries by specifying the same group value in the DN attribute of any number of users. 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.
3. Click General in the left pane. Type a name for the new group in the Group Name field (the name is required), and enter a description of the new group in the Description field. 4. Click Members in the left pane. In the right pane, select the Static Group tab. Click Add to add new members to the group. In the Search drop-down list, select what sort of entries to search for (users, groups, or both) then click Search. 5. 6. Select the members from the returned entries, and click OK.
7. Click Languages in the left pane to add language-specific information for the group.
8. Click OK to create the new group. It appears in the right pane. To edit a static group, double-click the group entry, and make the changes in the editor window. 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.
Alternatively, go to the Object menu, and select New→Group. 3. Click General in the left pane. Type a name for the new group in the Group Name field (the name is required), and enter a description of the new group in the Description field.
4. 5. Click Members in the left pane. In the right pane, select the Dynamic Group tab. Click Add to create a LDAP URL for querying the database. Enter an LDAP URL in the text field or select Construct to be guided through the construction of an LDAP URL. The results show the current entries (group members) that correspond to the filter.
6. Click Languages in the left pane to add language-specific information for the group. 7. Click OK. The new group appears in the right pane. To edit a dynamic group, double-click the group entry to open the editor window, and make whatever changes to the dynamic group. To view the changes to the group, 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. To work around the problem, create a VLV index for the users suffix with the filter (objectclass=person) and scope sub-tree.
objectClass: groupofurls cn: dynamic group description: Example dynamic group memberURL: ldap:///dc=example,dc=com??sub?(&(objectclass=person)(cn=*sen*)) Using the memberOf Attribute to manage group membership information The entries that belong to a group are defined, in some way, in the group entry itself. This makes it very easy to look at a group and see its members and to manage group membership centrally. However, there is no good way to find out what groups a single user belongs to.
Example 6 Default MemberOf plug-in entry dn: cn=MemberOf Plugin,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject cn: MemberOf Plugin nsslapd-pluginPath: libmemberof-plugin nsslapd-pluginInitfunc: memberof_postop_init nsslapd-pluginType: postoperation nsslapd-pluginEnabled: on nsslapd-plugin-depends-on-type: database memberofgroupattr: member memberofattr: memberOf nsslapd-pluginId: memberof nsslapd-pluginVersion: 8.1.
3. Make sure that the plug-in is enabled. This is disabled by default.
4. 5. Click the Advanced button to open the Advanced Properties Editor. The memberofgroupattr attribute sets the attribute in the group entry which the server uses to identify member entries. The memberofattr attribute sets the attribute, which the plug-in creates and manages on user entries. 6. 7. Save the changes. Restart the server to update the plug-in. For example, open the Tasks tab and click the Restart server task. Editing the MemberOf Plug-in from the command line 1.
/opt/dirsrv/slapd-instance_name/restart-slapd Synchronizing memberOf values The MemberOf Plug-in automatically manages the memberOf attribute on group member entries, based on the configuration in the group entry itself. However, the memberOf attribute can be edited on a user entry directly (which is improper) or new entries can be imported or replicated over to the server that have a memberOf attribute already set.
Support links between two attributes This feature provides the ability to link two attributes bidirectionally together across entries. The values of these attributes are DN pointers between the entries. When the LDAP client modifies one attribute in an entry, the corresponding attribute on a related entry is updated automatically. This is very similar to the way that the memberOf plug-in work with the member and memberOf attributes. Configuration The linked attributes plug-in is enabled by default.
added to the managedType attribute pointing back to the entry the client modified. If the entry being pointed to does not exist, the plug-in simply allows the operation to be performed. When a client updates the linkType attribute to remove a value, the managedType attribute value pointing back to the modified entry is also removed. If the entry or back-pointer value does not exist, the plug-in will simply allow the operation to be performed.
6 Managing Access Control HP-UX 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.
The permission and bind rule portions of the ACI are set as a pair, also called an access control rule (ACR). The specified permission is granted or denied depending on whether the accompanying rule is evaluated to be true. 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.
have an entry on the server, too. If the group is static, the members' entries can be located on remote servers. ◦ ACIs that depend on role definitions (roledn keyword) must be located on the same server as the role definition entry. Every entry that is intended to have the role must also be located on the same server. However, you can match values stored in the target entry with values stored in the entry of the bind user; for example, using the userattr keyword.
Creating ACIs manually You can create access control instructions manually using LDIF statements and add them to your directory tree using the ldapmodify utility, similar to the instructions in “LDIF Update Statements” (page 121). The following sections explain in detail how to create the LDIF statements. NOTE: LDIF ACI statements can be very complex. However, if you are setting access control for a large number of directory entries, using LDIF is the preferred because it is faster than using the Console.
(keyword = "expression") (keyword != "expression") • keyword indicates the type of target. • equal (=) indicates that the target is the object specified in the expression, and not equal (!=) indicates the target is not the object specified in the expression. • expression identifies the target. The quotation marks ("") around expression are required. What you use for expression is dependent upon the keyword that you supply. Table 23 (page 237) lists each keyword and the associated expressions.
NOTE: If the DN of the entry to which the access control rule applies contains a comma, escape the comma with a single backslash (\), such as (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.
(targetattr = "attribute1 || attribute2 ...|| attributen") attributeX is the name of the targeted attribute. For example, this targets the common name (cn) attribute: (targetattr = "cn") To target an entry's common name, surname, and UID attributes, use the following: (targetattr = "cn || sn || uid") The attributes specified in the targetattr keyword apply to the entry that the ACI is targeting and to all the entries below it.
NOTE: Although using LDAP filters can be useful when you are targeting entries and attributes that are spread across the directory, the results are sometimes unpredictable because filters do not directly name the object for which you are managing access. The set of entries targeted by a filtered ACI is likely to change as attributes are added or deleted.
ou=people,dc=example,dc=com, and there are not any organizational units (ou) defined below that node, you could specify an ACI that contains targetattr=ou. A safer method is to use the targetfilter keyword and to specify explicitly an attribute value that appears in the entry alone. For example, during the installation of the Directory Server, the following ACI is created: aci: (targetattr="*")(targetfilter=(o=NetscapeRoot))(version 3.
Rights are granted independently of one another. This means, for example, that a user who is granted add rights can create an entry but cannot delete it if delete rights have not been specifically granted. Therefore, when planning the access control policy for your directory, you must ensure that you grant rights in a way that makes sense for users. For example, it does not usually make sense to grant write permission without granting read and search permissions.
The permissions granted on individual attributes or entries can affect a broad range of actions; for example, there are several different permissions users must have to search the directory like the following ldapsearch operation: ldapsearch -h host -s base -b "uid=bkolics,dc=example,dc=com" objectclass=* mail The following ACI is used to determine whether user bkolics can be granted access: aci: (targetattr = "mail")(version 3.
Additionally, bind rules can be complex constructions that combine these criteria by using Boolean operators. See “Using Boolean bind rules” (page 255) for more information. Bind rule syntax Whether access is allowed or denied depends on whether an ACI's bind rule is evaluated to be true.
userdn =ldap:///self" Defines self access userdn =ldap:///parent" Defines access for the parent entry The userdn keyword can also be expressed as an LDAP filter: ldap:///suffix??scope?(filter) NOTE: If a DN contains a comma, the comma must be preceded by a backslash (\) escape character. 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.
Using a connector such as && is not allowed. For example, this is not an acceptable bind rule: groupdn="ldap:///dc=example,dc=com??sub?(ou=engineering) && ldap:///dc=example,dc=com??sub?(manager="uid=bjensen,ou=managers, dc=example,dc=com")" For more information about LDAP URLs, see “LDAP URLs” (page 571). Wildcards You can also specify a set of users by using the wildcard character (*).
Table 26 userdn keyword examples (continued) Scenario Example Description For example, if you want to grant read access to the entire tree to all authenticated users, you would create the following ACI on the dc=example,dc=com node: aci:(version 3.0; acl "all-read"; allow (read) userdn="ldap:///all";) Userdn keyword containing the anyone keyword userdn = "ldap:///anyone"; The bind rule is evaluated to be true for anyone; use this keyword to provide anonymous access to your directory.
However, it is not permissible to use ampersands (&) as part of the expressions, such as groupdn = "LDAPURI0 && LDAPURL1", or double quotes, such as userdn = "ldap:///cn=Ralph "the doc" Wellman".
This example is based on DN matching. However, you can match any attribute of the entry used in the bind with the targeted entry. For example, you could create an ACI that allowed any user whose favoriteDrink attribute is beer to read all the entries of other users that have the same value for favoriteDrink. Using the userattr keyword The userattr keyword can be used to specify which attribute values must match between the entry used to bind and the targeted entry.
(By default, owner is not an allowed entry in a user's entry. You would have to extend your schema to allow this attribute in a person object.) Example with ROLEDN bind type The following associates the userattr keyword with a bind based on a role DN: userattr = "exampleEmployeeReportsTo#ROLEDN" The bind rule is evaluated to be true if the bind DN belongs to the role specified in the exampleEmployeeReportsTo attribute of the targeted entry.
userattr = "parent[inheritance_level].attrName#attrValue • inheritance_level is a comma-separated list that indicates how many levels below the target inherits the ACI. You can include five levels (0, 1, 2, 3, 4) below the targeted entry; zero (0) indicates the targeted entry. • attribute is the attribute targeted by the userattr or groupattr keyword. • bindType can be one of USERDN, GROUPDN, or LDAPURL. For example: userattr = "parent[0,1].
dn: cn= Trojan Horse,ou=Human Resources,dc=example,dc=com objectclass: top ... cn: Trojan Horse manager: cn=Joe,ou=eng,dc=example,dc=com To avoid this type of security threat, the ACI evaluation process does not grant add permission at level 0, to the entry itself. You can, however, use the parent keyword to grant add rights below existing entries. You must specify the number of levels below the parent for add rights.
Instead, use a fully qualified name: dns = "legend.eng.example.com"; The dns keyword allows wildcards. For example: dns = "*.example.com"; 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.
timeofday < "1800"; • The bind rule is evaluated to be true if the client is accessing the directory at 8 a.m. or later. timeofday >= "0800"; • The bind rule is evaluated to be true if the client is accessing the directory at 6 p.m. or earlier. timeofday <= "1800"; • The bind rule is evaluated to be true if the client is accessing the directory on Sunday, Monday, or Tuesday.
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"; 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.
The Access Control Editor prevents creating more complex ACIs in visual editing mode, especially ACIs with any of these characteristics: • Deny access (“Permissions syntax” (page 243)). • Create value-based ACIs (“Targeting attributes” (page 238)). • Define parent access (“Parent access (parent keyword)” (page 245)). • Create ACIs that contain Boolean bind rules (“Using Boolean bind rules” (page 255)). • Create ACIs that use the roledn, userattr, authmethod keywords.
Figure 12 Access Control Editor window Creating a new ACI To create a new ACI in the Directory Server Console: 1. Open the Access Control Editor, as described in “Displaying the Access Control Editor” (page 256). If the view displayed is different from Figure 12 (page 257), 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. If you do not enter a name, the server uses unnamed ACI. 3.
a. b. c. 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 wildcards (an asterisk, *) to search for partial usernames. The search results are displayed in the list below. Highlight the entries you want in the search result list, and click the Add button to add them to the list of entries that have access permission. Click OK to dismiss the Add Users and Groups window.
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.
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.
You can specify a host name or an IP address. With an IP address, you can use an asterisk (*) as a wildcard. NOTE: Directory Server supports both IPv4 and IPv6 IP addresses. 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.
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. Editing an ACI To edit an ACI: 1.
1. In the Directory tab, right-click the top entry in the subtree, and choose Set Access Permissions from the pop-up menu. The Access Control Manager window opens with a list of ACIs belonging to the entry. 2. 3. In the Access Control Manager window, select the ACI to delete. Click Remove. The ACI is no longer listed in the Access Control Manager window. Viewing ACIs All the ACIs under a single suffix in the directory can be viewed from the command line by using the following ldapsearch command.
Rights shown with a get effective rights search Any get effective rights search, both when viewing an entry in the Directory Server Console and searching for it in the command line, shows the rights that User A has to User B's entry. There are two kinds of access rights that can be allowed to any entry. The first are upper-level rights, rights on the entry itself, which means that kinds of operations that the User A can perform on User B's entry as a whole.
• 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). • The GER_subject is the person whose rights are being checked. If the GER subject is left blank (dn:), then the rights of an anonymous user are returned. • An optional attributeList limits the get effective rights results to the specified attribute or object class.
Example 8 Checking personal rights (User A to User A) ldapsearch -p 389 -h localhost -D "uid=tmorris,ou=people,dc=example,dc=com" -w secret -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=tmorris,ou=people,dc=example,dc=com" "(objectClass=*)" dn: uid=tmorris, ou=People, dc=example,dc=com givenName: Ted sn: Morris ou: IT ou: People l: Santa Clara manager: uid=jsmith, ou=People, dc=example,dc=com roomNumber: 4117 mail: tmorris@example.
Example 10 The directory manager's checking the rights of one user over another (User A to User B) ldapsearch -p 389 -h localhost -D "cn=directory manager" -w secret -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=jsmith,ou=people,dc=example,dc=com" "(objectClass=*)" dn: uid=tmorris, ou=People, dc=example,dc=com ... snip ...
Using an asterisk (*) with the get effective rights search returns every attribute available for the entry, including attributes not set on the entry. For example: Example 12 Returning effective rights for non-existent attributes ldapsearch -D "cn=directory manager" -w secret12 -b "uid=scarter,ou=people,dc=example,dc=com" -J 1.3.6.1.4.1.42.2.27.9.5.
Example 13 Get effective rights results for specific attributes ldapsearch -D "cn=directory manager" -w secret12 -b "uid=scarter,ou=people,dc=example,dc=com" -J 1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=scarter,ou=people,dc=example,dc=com "(objectclass=*)" cn mail initials dn: uid=scarter, ou=People, dc=redbudcomputer,dc=local cn: Sam Carter mail: scarter@example.
Example 16 Get effective rights results for all attribute for an object class ldapsearch -D "cn=directory manager" -w secret12 -b "uid=scarter,ou=people,dc=example,dc=com" -J 1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=scarter,ou=people,dc=example,dc=com "(objectclass=*)" *@posixaccount ... snip ...
objectClass: top objectClass: organizationalUnit ou: Accounting Because the ACL does not include the dc=example,dc=com subtree, the get effective rights search shows that the user does not have any rights to the dc=example,dc=com entry: Example 18 Get effective rights results with no ACL Set (directory manager) ldapsearch -D "cn=directory manager" -w secret12 -b "dc=example,dc=com" -J 1.3.6.1.4.1.42.2.27.9.5.
The attribute-level effective rights (r, s, c, w, o) appear next to the attributes. The entry-level rights (v, a, d, n) appear under the full DN for the entry in the lower left-hand corner of the Property Editor. If you check the Show all allowed attributes checkbox, then the effective rights for those attributes appear next to the additional attributes, even though they do not have values.
Table 30 Returned result codes (continued) Code Description 52 Unavailable. 53 Unwilling to perform. 80 Other. Logging access control information To obtain information on access control in the errors log, you must set the appropriate log level. To set the errors log level from the Console: 1. In the Console, click the Directory tab, right-click the config node, and choose Properties from the pop-up menu. This displays the Property Editor for the cn=config entry. 2. 3.
authentication, time and date restrictions, and specified location (“Granting conditional access to a group or role” (page 280)). • Deny individual subscribers access to the billing information in their own entries (“Denying access” (page 282)). • Grant anonymous access to the world to the individual subscribers subtree, except for subscribers who have specifically requested to be unlisted. (This part of the directory could be a consumer server outside of the firewall and be updated once a day.
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 that 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 “Setting a target using filtering” (page 283). From the Console, set this permission by doing the following: 1.
1. 2. 3. In the Directory tab, right-click the example-people entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager. Click New to display the Access Control Editor. In the Users/Groups tab, in the ACI name field, type Write example.com. In the list of users granted access permission: a. Select and remove All Users, then click Add. The Add Users and Groups dialog box opens. b. c. d. 4. 5.
a. Select and remove All Users, then click Add. The Add Users and Groups dialog box opens. b. c. d. 4. 5. Set the Search area to Special Rights, and select Self from the search results list. Click the Add button to list Self in the list of users who are granted access permission. Click OK to dismiss the Add Users and Groups dialog box. In the Rights tab, select the checkbox for write. Make sure the other checkboxes are clear.
1. 2. 3. In the Directory tab, right-click the example-people entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager. Click New to display the Access Control Editor. In the Users/Groups tab, in the ACI name field, type Roles. In the list of users granted access permission: a. Select and remove All Users, then click Add. The Add Users and Groups dialog box opens. b. c. d. 4. 5. 6. 7.
1. 2. 3. In the Directory tab, right-click the example-people entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager. Click New to display the Access Control Editor. In the Users/Groups tab, in the ACI name field, type HR. In the list of users granted access permission: a. Select and remove All Users, then click Add. The Add Users and Groups dialog box opens. b.
1. 2. 3. In the Directory tab, right-click the Social Committee entry under the example.com node in the left navigation tree, and choose Set Access Permissions from the pop-up menu to display the Access Control Manager. Click New to display the Access Control Editor. In the Users/Groups tab, in the ACI name field, type Create Group. 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. c. d. 4. 5. 6.
own data and implement their own access control rules while securing it against intruders. For this reason, HostedCompany1 and HostedCompany2 have full rights on their respective branches of the directory tree, provided the following conditions are fulfilled: • Connection authenticated using SSL • Access requested between 8 a.m. and 6 p.m.
7. In the Times tab, select the block time corresponding to Monday through Thursday and 8 a.m. to 6 p.m. A message appears below the table that specifies the selected time block. 8. To enforce SSL authentication from HostedCompany1 administrators, switch to manual editing by clicking the Edit Manually button.
5. In the Targets tab, click This Entry to display the ou=subscribers, dc=example,dc=com suffix in the Target directory entry field. In the attribute table, select the checkboxes for the connectionTime and accountBalance attributes. All other checkboxes should be clear; if it is made 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.
NOTE: Because search filters do not directly name the object for which you are managing access, it is easy to allow or deny access to the wrong objects unintentionally, especially as your directory becomes more complex. Additionally, filters can make it difficult to troubleshoot access control problems within your directory.
5. In the Targets tab, type dc=example,dc=com suffix in the Target directory entry field. In the attribute table, select the checkbox for the member attribute. 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. Click OK. The new ACI is added to the ones listed in the Access Control Manager window.
NOTE: There are some restrictions on binding with proxy authorization. You cannot use the Directory Manager's DN (root DN) as a proxy DN. Additionally, if Directory Server receives more than one proxied authentication control, an error is returned to the client application, and the bind attempt is unsuccessful. Advanced access control: Using macro ACIs In organizations that use repeating directory tree structures, it is possible to optimize the number of ACIs used in the directory by using macros.
Figure 13 Example directory tree for macro ACIs The following ACI is located on the dc=hostedCompany1,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=hostedCompany1,dc=example,dc=com";) The following ACI is located on the dc=subdomain1,dc=hostedCompany1, dc=example,dc=com node: aci: (targetattr="*")(targetfilter=(objectClass=nsManagedDomain)) (version 3.
In this example, the number of ACIs is reduced from four to one. The real benefit is a factor of how many repeating patterns you have down and across your directory tree. Macro ACI syntax Macro ACIs include the following types of expressions to replace a DN or part of a DN: • ($dn) • [$dn] • ($attr.
After the macro has been expanded, Directory Server evaluates the ACI following the normal process to determine whether access is granted. Macro matching for [$dn] The matching mechanism for [$dn] is slightly different than for ($dn). The DN of the targeted resource is examined several times, each time dropping the leftmost RDN component, until a match is found.
To evaluate the roledn part of the ACI, the server looks at the ou attribute stored in the targeted entry and uses the value of this attribute to expand the macro. Therefore, in the example, the roledn is expanded as follows: roledn = "ldap:///cn=DomainAdmins,ou=Engineering,dc=HostedCompany1,dc=example,dc=com" The Directory Server then evaluates the ACI according to the normal ACI evaluation algorithm.
7 Managing User Authentication When a user connects to the HP-UX 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. This chapter describes tasks for managing users, including configuring the password and account lockout policy for the directory, denying groups of users access to the directory, and limiting system resources available to users depending upon their bind DNs.
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.
10. If the Password expire after X days radio button is selected, specify how long before the password expires to send a warning to the user. In the Send Warning X Days Before Password Expires text enter the number of days before password expiration to send a warning. NOTE: It is not necessary to configure the Directory Server to send a warning to users.
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 32 Password policy attributes (continued) Attribute name Definition in a history. If a user attempts to reuse one of the passwords, the password will be rejected. When this attribute is set to off, any passwords stored in the history remain there. When this attribute is set back to on, users will not be able to reuse the passwords recorded in the history before the attribute was disabled. This attribute is off by default, meaning users can reuse old passwords.
Table 32 Password policy attributes (continued) Attribute name Definition passwordMin8bit This attribute sets the minimum number of 8-bit characters used in the password. The default number is 0, meaning none are required. passwordStorageScheme This attribute specifies the type of encryption used to store Directory Server passwords. HP-UX Directory Server supports the following encryption types: • SSHA (Salted Secure Hash Algorithm) This method is recommended as it is the most secure.
dn: cn="cn=nsPwPolicyEntry,ou=people,dc=example,dc=com", cn=nsPwPolicyContainer,ou=people,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: ldapsubentry objectclass: passwordpolicy • The CoS template entry (nsPwTemplateEntry) that has the pwdpolicysubentry value pointing to the above (nsPwPolicyEntry) entry.
NOTE: The nsslapd-pwpolicy-local attribute of the cn=config entry controls the type of password policy the server enforces. By default, this attribute is disabled (off). When the attribute is disabled, the server only checks for and enforces the global password policy; the subtree and user level password policies are ignored. When the ns-newpwpolicy.pl script runs, it first checks for the specified subtree and user entries and, if they exist, modifies them.
ldappasswd -h hostname -p secure_port -Z -P /path/to/cert8.db -D bindDN -w bindPassword [-a oldPassword] -s newPassworduser Table 33 ldappasswd options Option Description -h Gives the host name of the Directory Server. -p Gives the port number of the Directory Server. Because SSL is required for password change operations, this is usually give the TLS/SSL port of the Directory Server. With the -ZZ or -ZZZ for Start TLS, this can be the standard port. -Z Requires SSL for the connection.
Configuring the account lockout policy using the console To set up or modify the account lockout policy for the Directory Server: 1. Select the Configuration tab 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.
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.
See “Synchronizing Directory Server with Microsoft Active Directory” (page 392) for more information on synchronizing Directory Server and Windows users and passwords. Inactivating users and roles A single user account or set of accounts can be temporarily inactivated. After an account is inactivated, a user cannot bind to the directory. The authentication operation will fail. Users and roles are inactivated using the operational attribute nsAccountLock.
Option Name Description -p Port used by the server. -h Name of the server on which the directory resides. -I DN of the user account or role to inactivate. For more information about running the ns-inactivate.pl script, see HP-UX Directory Server configuration, command, and file reference. 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.
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 Specifies how many entries can be examined for a search operation. • Size limit Specifies the maximum number of entries the server returns to a client application in response to a search operation.
Attribute Description nsTimeLimit Specifies the maximum time the server spends processing a search operation. Giving this attribute a value of -1 indicates that there is no time limit. nsIdleTimeout Specifies the time a connection to the server can be idle before the connection is dropped. The value is given in seconds. Giving this attribute a value of -1 indicates that there is no limit.
PTA is required in this case because the admin user entry is stored under o=NetscapeRoot suffix in the configuration directory. Therefore, attempts to bind to the user directory as admin would normally fail. PTA allows the user directory to transmit the credentials to the configuration directory, which verifies them. The user directory then allows the admin user to bind.
bind requests to the authenticating directory) using the required PTA syntax. There are only two attributes in this entry that are significant: • nsslapd-pluginEnabled, which sets whether the plug-in is enabled or disabled. The value for this attribute can be on or off. • nsslapd-pluginarg0, which points to the configuration directory.
Table 35 PTA plug-in parameters (continued) Variable Definition should be enforced. See “Configuring the optional parameters” (page 309) for more information. ldver Optional. The version of the LDAP protocol used to connect to the authenticating directory. Directory Server supports LDAP version 2 and 3. The default is version 3, and HP strongly recommends against using LDAPv2, which is old and will be deprecated. See “Configuring the optional parameters” (page 309) for more information.
Specifying the authenticating Directory Server The authenticating directory contains the bind credentials for the entry with which the client is attempting to bind. The PTA directory passes the bind request to the host defines as the authenticating directory. To specify the authenticating Directory Server, replace authDS in the LDAP URL of the PTA directory with the authenticating directory's host name, as described in Table 35 (page 307). 1. Use ldapmodify edit the PTA Plug-in entry.
ldap|ldaps://authDS/subtree maxconns, maxops, timeout, ldver, connlifetime, startTLS • The maximum number of connections the PTA Directory Server can open simultaneously to the authenticating directory, represented by maxconns in the PTA syntax. The default value is 3. • The maximum number of bind requests the PTA Directory Server can send simultaneously to the authenticating Directory Server within a single connection. In the PTA syntax, this parameter is maxops. The default is value is 5.
PTA plug-in syntax examples This section contains the following examples of PTA Plug-in syntax in the dse.
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,1 ... 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.
Figure 14 Autobind connection path The special autobind users are entries beneath a special autobind suffix (outside the regular user subtree). The entries underneath are identified by their user and group ID numbers: gidNumber=gid+uidNumberuid, autobindsuffix If autobind is not enabled but LDAPI is, then Unix users are anonymously bound to the Directory Server, unless they provide other bind credentials.
Configuring autobind Configuring autobind alone allows anonymous access to the Directory Server. It is possible to enable mapping Unix users to entries and also to map root to Directory Manager. 1. Run ldapmodify to update the Directory Server configuration. ldapmodify -D "cn=directory manager" -w secret -p 389 -h server.example.com dn: cn=config changetype: modify 2. Enable autobind. replace: nsslapd-ldapiautobind nsslapd-ldapiautobind: on 3.
Configuring the account inactivity policy The account policy plug-in and its policies must be configured using the command line. Configuring the plug-in for the first time requires the following steps: 1. Using ldapmodify command line utility, enable the plug-in by setting the nsslapd-pluginEnabled attribute to on. The plug-in performs inactivity enforcement and last login time tracking only when it is enabled.
Provisioning account inactivity policies The account policy plug-in records the last login time in the lastLoginTime attribute. However, by default, an account that has never been logged into does not have a lastLoginTime attribute. For newly created accounts, you have two options for providing this attribute: • Provision a lastLoginTime attribute when you add the account entry. • Rely on the plug-in's alternate timestamp mechanism, using the createTimestamp attribute, which is present in all entries.
A new config switch nsslapd-allow-anonymous-access in cn=config is introduced that allows restriction to all anonymous access. When this switch is set to off, anonymous and unauthenticated BINDs are disabled completely. Disabling anonymous BINDs: 1. Set nsslapd-allow-anonymous-access to off in cn=config ldapmodify -D "cn=directory manager" -w secret -h server.example.com -p 389 dn: cn=config changetype: modify replace: nsslapd-allow-anonymous-access nsslapd-allow-anonymous-access: off 2.
8 Managing Replication Replication is the mechanism by which directory data is automatically copied from one HP-UX 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.
What directory units are replicated The smallest unit of the directory that can be replicated is a database. This means that one can replicate an entire database but not a subtree within a database. Therefore, when creating the directory tree, consider any replication plans as part of determining how to distribute information. Replication also requires that one database correspond to one suffix.
• When a replica is configured as a consumer or hub (a replica that receives updates from 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.
The Retro Changelog Plug-in can be used for a Directory Server supplier to maintain a 4.x-style changelog. This is sometimes necessary for legacy applications that have a dependency on the Directory Server 4.x changelog format because they read information from the changelog. For more information on the Retro Changelog Plug-in, see “Using the Retro changelog plug-in” (page 382).
Figure 15 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 “Configuring single-master replication” (page 327).
Figure 16 Multi-master replication (two masters) Figure 17 (page 324) shows a sample of multi-master replication scenario with four supplier servers and eight consumer servers. In this sample setup, each supplier server is configured with ten replication agreements to feed data to two other supplier servers and all eight consumer servers.
Figure 17 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.
Figure 18 Cascading replication For information on setting up cascading replication, see “Configuring cascading replication” (page 349). NOTE: Multi-master and cascading replication can be combined. For example, in the multi-master scenario illustrated in Figure 16 (page 323), Server C and Server D could be hub servers that would replicate to any number of consumer servers.
The supplier bind DN must meet the following criteria: • It must be unique. • It must be created on the consumer server (or hub) and not on the supplier server. • It must correspond to an actual entry on the consumer server. • It must be created on every server that receives updates from another server. • It must not be part of the replicated database for security reasons. • It must be defined in the replication agreement on the supplier server.
Configuring single-master replication To set up single-master replication such as the configuration shown in Figure 15 (page 322), between supplier Server A, which holds a read-write replica, and the two consumers Server B and Server C, which each hold a read-only replica, there are two major steps: • “Configuring the read-write replica on the supplier server” (page 327) • “Configuring the read-only replica on the consumer” (page 328) • “Create the replication agreement” (page 330) Configuring the rea
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. c. d. Check the Enable Replica checkbox. In the Replica Role section, select the Single Master radio button. In the Common Settings section, specify a Replica ID, which is an integer between 1 and 65534, inclusive.
d. e. In the Replica Role section, select the Dedicated Consumer radio button. In the Common Settings section, specify a purge delay in the Purge delay field. This option indicates how often the state information stored for 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. The supplier bind DN appears in the Current Supplier DNs list.
The supplier bind DN should be the entry created in step 2. The supplier bind DN is a privileged user because it is not subject to access control. 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.
• 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.
NOTE: If attribute encryption is enabled, a secure connection must be used for the encrypted attributes to be replicated. 4. Select the connection type. There are three options: • Use LDAP This sets either a standard, unencrypted connection or allows SASL encryption, because Directory Server supports SASL over standard LDAP but not SSL. • Use TLS/SSL This uses a secure connection over the server's secure LDAPS port, such as 636.
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. 7. Set the schedule for when replication runs. By default, replication runs continually.
Click Next. 8. 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 “Initializing consumers” (page 372).
NOTE: Replication does not begin until the consumer is initialized. Click Next. 9. The final screen shows the settings for the replication agreement, as it will be included in the dse.ldif file. Click 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. 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.
Directory Server supports 4-way multi-master replication.
f. Set the changelog parameters for the number and age of the log files. Clear the unlimited checkboxes to specify different values. g. 2. Click Save. Create the entry for the supplier bind DN on the consumer server if it does not exist. This is the special entry that the other suppliers will use to bind to this supplier, as in other supplier-consumer relationships. This is described in “Creating the supplier bind DN entry” (page 325).
c. d. e. Check the Enable Replica checkbox. In the Replica Role section, select the Multiple Master radio button. In the Common Settings section, specify a Replica ID, which is an integer between 1 and 65534, inclusive. The replica ID must be unique for a given suffix, different from any other ID used for read-write replicas on this server and on other servers. f. In the Common Settings section, specify a purge delay in the Purge delay field.
NOTE: There can be multiple supplier bind DNs per consumer but only one supplier DN per replication agreement. h. Specify the URL for any supplier servers to which to refer updates, such as the other suppliers in the multi-master replication set. Only specify the URL for the supplier server. For clients to bind using SSL, specify a URL beginning with ldaps://. i. Click Save. Configuring the read-only replicas on the consumer servers First, configure every consumer. 1.
c. d. e. Check the Enable Replica checkbox. In the Replica Role section, select the Dedicated Consumer radio button. In the Common Settings section, specify a purge delay in the Purge delay field. This option indicates how often the state information stored for 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.
• 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.
NOTE: If attribute encryption is enabled, a secure connection is required for the encrypted attributes to be replicated. 4. Select the connection type. There are three options: • Use LDAP This sets either a standard, unecrypted connection or allows SASL encryption, because Directory Server supports SASL over standard LDAP but not SSL. • Use TLS/SSL This uses a secure connection over the server's secure LDAPS port, such as 636.
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. 8. Set the schedule for when replication runs. By default, replication runs continually.
Click Next. 9. 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.
initializing consumers, see “Initializing consumers” (page 372). For multi-master replication, consider the following: • Ensure one supplier has the complete set of data to replicate to the other suppliers. Use this one supplier to initialize the replica on all other suppliers in the multi-master replication set. • Initialize the replicas on the consumer servers from any of the multi-master suppliers. • Do not try to reinitialize the servers when the replication agreements are set up.
NOTE: Replication will not begin until the consumer is initialized. Click Next. 10. The final screen shows the settings for the replication agreement, as it will be included in the dse.ldif file. Click Done to save the agreement. The replication agreement is set up.
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.
nsds5ReplicaBusyWaitTime. The longer interval gives waiting suppliers a better chance to gain consumer access before the previous supplier can re-access the consumer. • If either attribute is specified but not both, nsds5ReplicaSessionPauseTime is set automatically to 1 second more than nsds5ReplicaBusyWaitTime.
d. Check the Enable Changelog checkbox. This activates all the fields in the pane below that were previously grayed out. e. f. Specify a changelog by clicking the Use default button, or click the Browse button to display a file selector. Set the changelog parameters for the number and age of the log files. Clear the unlimited checkboxes to specify different values. g. 2. Click Save. Specify the replication settings required for a read-write replica. a.
Configuring the read-only replica on the consumer server 1. 2. 3. Create the database for the read-only replica if it does not exist. See “Creating suffixes” (page 32) for instructions on creating suffixes. Create the entry for the supplier bind DN on the consumer server if it does not exist. The supplier bind DN is the special entry that the supplier will use to bind to the consumer. This is described in “Creating the supplier bind DN entry” (page 325).
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.
d. Check the Enable Changelog checkbox. This activates all the fields in the pane below that were previously grayed out. e. f. Specify a changelog by clicking the Use default button, or click the Browse button to display a file selector. Set the changelog parameters for the number and age of the log files. Clear the unlimited checkboxes to specify different values. g. 4. Click Save. Specify the required hub replica settings. a. In the Directory Server Console, select the Configuration tab. b.
The Replica Settings tab for that database opens in the right-hand side of the window. c. Check the Enable Replica checkbox.
d. e. In the Replica Role section, select the Hub radio button. In the Common Settings section, specify a purge delay in the Purge delay field. This option sets how often the state information stored for 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. The supplier bind DN appears in the Current Supplier DNs list. The supplier bind DN should be the entry created in step 2. The supplier bind DN is a privileged user because it is not subject to access control in the replicated database.
1. In the navigation tree of the Configuration tab, right-click the database to replicate, and select New Replication Agreement. Alternatively, highlight the database, and select New Replication Agreement from the Object menu to start the Replication Agreement Wizard. 2. 3. In the first screen, fill in a name and description for the replication agreement, and clickNext. In the Source and Destination screen, fill in the URL for the consumer and the supplier bind DN and password on that consumer.
• 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.
NOTE: If attribute encryption is enabled, a secure connection must be used for the encrypted attributes to be replicated. 4. Select the connection type. There are three options: • Use LDAP This sets either a standard, unecrypted connection or allows SASL encryption, because Directory Server supports SASL over standard LDAP but not SSL. • Use TLS/SSL This uses a secure connection over the server's secure LDAPS port, such as 636.
8. Set the schedule for when replication runs. By default, replication runs continually.
Click Next. 9. 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.
initializing consumers, see “Initializing consumers” (page 372). For cascading replication, consider the following: • Create the supplier-hub replication agreement on the supplier first, and initialize the hub from the supplier. • Create the hub-consumer replication agreements on the hub, and initialize the consumers from the hub. NOTE: Replication will not begin until the consumer is initialized.
Click Next. 10. The final screen shows the settings for the replication agreement, as it will be included in the dse.ldif file. Click Done to save the agreement. 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.
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. The process follows the same order as setting up replication through the Directory Server Console: 1. Create the supplier bind DN on every consumer, hub, and multi-master supplier (“Creating the supplier bind DN entry” (page 325)). 2.
nsds5ReplicaPurgeDelay: 604800 nsds5ReplicaBindDN: cn=replication manager,cn=config • nsds5replicaroot sets the subtree (suffix) that is being replicated. • nsds5replicatype sets what kind of replica this database is. For either a single master or a multi-master supplier, this value must be 3. • nsds5replicaid sets the replica ID. The value must be unique among all suppliers and the valid range is 1 to 65534. For hub and consumer replicas, the only valid value is 65535.
Table 37 Replica attributes (continued) Object class or attribute Description Values 3 for both single and multi-master suppliers (read-write replicas) nsds5flags: number Sets whether the replica writes to the changelog. 0 means the replica does not write to the changelog; this is the default for consumers. 1 means the relics writes to the changelog; this is the default for hubs and suppliers.
nsds5ReplicaBindDN: cn=replication manager,cn=config nsds5flags: 0 The replica entry attributes are described in Table 37 (page 365). These attributes are described in more detail in the HP-UX Directory Server configuration, command, and file reference. Configuring hubs from the command line Hubs are intermediate read-only replicas that receive updates from suppliers and pass them on to other consumers. These are part of the cascading replication scenario, described in “Cascading replication” (page 324).
The replica entry attributes are described in Table 37 (page 365). These attributes are described in more detail in the HP-UX Directory Server configuration, command, and file reference. Configuring replication agreements from the command line When setting up replication agreements, first set them up between all suppliers, then between the suppliers and the hubs, and last between the hub and the consumers.
Table 38 Replication agreement attributes (continued) Object class or attribute Description Values To use Start TLS, which initiates a secure connection over a standard port, use the standard port, 389, with the nsds5ReplicaTransportInfo attribute to TLS. nsds5replicatransportinfo: method To use TLS/SSL, set this parameter to SSL.
Table 38 Replication agreement attributes (continued) Object class or attribute Description Values nsds5replicabindcredentials: Only for simple authentication. Stores the hashed password used with the hash bind DN given for simple authentication. nsds5replicaroot: suffix Sets which subtree is replicated. A root suffix associated with a database, because the entire database is replicated. For example: dc=example,dc=com description: text A text description of the replication agreement.
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 after the consumer initialization is complete. 1. Find the DN of the replication agreement on the supplier server that is for the consumer to be initialized. For example: ldapsearch -h supplier1.example.
5. 6. Select the suffix, and, in the Replica Settings tab, change the replica role to a single master or multi-master, and assign a unique replica ID. Save the changes, and restart the server. Deleting the changelog The changelog is a record of all modifications on a given replica that the supplier uses to replay these modifications to replicas on consumer servers (or suppliers in the case of multi-master replication).
NOTE: Replication will not begin until the consumer is initialized. • “When to initialize a consumer” (page 373) • “Online consumer initialization using the console” (page 373) • “Initializing consumers online using the command line” (page 374) • “Manual consumer initialization using the command line” (page 374) • “Filesystem replica initialization” (page 375) When to initialize a consumer Consumer initialization involves copying data from the supplier server to the consumer server.
Online consumer initialization begins immediately. To check the status of the online consumer initialization, open the Summary tab in the Status box. If online consumer initialization is in progress, the status shows that a replica is being initialized. To update this window, right-click the replicated database icon in the navigation tree, and choose Refresh Replication Agreements. When online consumer initialization finishes, the status changes to reflect this.
1. 2. Create a replication agreement. Export the replica on the supplier server to an LDIF file. See “Exporting a replica to LDIF” (page 375). 3. Import the LDIF file with the supplier replica contents to the consumer server. See “Importing the LDIF file to the consumer server” (page 375).
This method of initializing consumers is especially useful in replication over wide-area networks or over networks with slow or unstable connections. For smaller databases, HP recommends using manual initialization or initialize consumers from the Console. NOTE: The destination server must have the same architecture and the same bit size as the supplier server for the initialization to succeed. Initializing the consumer replica from the backup files 1.
Even if the replication agreements are configured to keep the supplier and consumer servers always synchronized, it is not sufficient to bring back up-to-date a server that has been offline for over five minutes. The Always Keep in Sync option means that the server generates a replication operation for every update operation it processes. However, if this replication operation cannot be performed because the consumer is offline, the operation times out after 10 minutes.
Example 19 Replicate_Now script example #!/bin/sh SUP_HOST=supplier_hostname SUP_PORT=supplier_portnumber SUP_MGRDN=supplier_directoryManager SUP_MGRPW=supplier_directoryManager_password MY_HOST=consumer_hostname MY_PORT=consumer_portnumber ldapsearch -1 -T -h ${SUP_HOST} -p ${SUP_PORT} -D "${SUP_MGRDN}" \ -w ${SUP_MGRPW} -b "cn=mapping tree, cn=config" \"(&(objectclass=nsds5replicationagreement)(nsDS5ReplicaHost=${MY_HOST}) \(nsDS5ReplicaPort=${MY_PORT}))" dn nsds5ReplicaUpdateSchedule > /tmp/$$ cat /tmp/$
Configuring Directory Server to replicate password policy attributes A special core configuration attribute controls whether password policy operational attributes are replicated. This is the passwordIsGlobalPolicy attribute, which is enabled in the consumer Directory Server configuration to allow the consumer to accept password policy operational attributes. By default, this attribute is set to off.
When the servers are configured to use SSL, configure an SSL connection for replication in the Replication Agreement Wizard. The Source and Destination sets how to bind between the supplier and the consumer, and this is where SSL is set. There are two ways to use SSL for replication: • Select SSL Client Authentication. With SSL client authentication, the supplier and consumer servers use certificates to authenticate to each other. • Select Simple Authentication.
ConfigFile = replagreement.ldif example replication agreement entry ... 3. Initialize the o=NetscapeRoot database on server2 from server1. Add the nsds5replicarefresh attribute to the replication agreement on server1. ldapmodify -D "cn=directory manager" -w secret -p 389 -h supplier1.example.com dn: cn=ExampleAgreement1,cn=replica,cn="o=NetscapeRoot",cn=mapping tree,cn=config changetype: modify replace: nsds5beginreplicarefresh nsds5beginreplicarefresh: start 4. Run register-ds-admin.
a. b. In the navigation tree, expand the Replication node, and select a replica that will receive updates from the legacy supplier. 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. It is not necessary to specify a supplier DN because the one specified in step 4 will be used. c. 7. 8. Click Save.
• “Searching and modifying the Retro changelog” (page 383) • “Retro changelog and the access control policy” (page 384) Enabling the Retro changelog plug-in The retro changelog plug-in configuration information is stored in the cn=Retro Changelog Plugin,cn=plugins,cn=config entry in dse.ldif. To enable the retro changelog plug-in from the command line: 1.
Retro changelog and the access control policy When the retro changelog is created, the following access control rules apply by default: • Read, search, and compare rights are granted to all authenticated users (userdn=anyone), not to be confused with anonymous access where userdn=all) to the retro changelog top entry cn=changelog. • Write and delete access are not granted, except implicitly to the Directory Manager.
Monitoring replication status from administration express Although the replication status report in the Directory Server Console shows many details, it does not show the progress of the replication. Additionally, because one report is generated per agreement, this lists all status reports for all different agreements. The repl-monitor.
Table Description Time Lag It shows the time difference between the supplier and the consumer's max CSNs for the changes originated from the supplier (identified in the Table Header). A consumer is synchronized with its supplier when its time lag is 0. Last Modify Time It is roughly the time when the consumer's max CSN was replayed. Supplier This column lists all the suppliers of the consumer.
Renaming an entry with a multivalued naming attribute To rename an entry that has a multivalued naming attribute: 1. Rename the entry using a new value for the naming attribute, and keep the old RDN. For example: ldapmodify -D "cn=directory manager" -w secret -p 389 -h server.example.com 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.
delete: dc dc: pubs delete: nsds5ReplConflict - NOTE: The unique identifier attribute nsuniqueid cannot be deleted. 3. Rename the entry with the intended attribute-value pair. For example: ldapmodify -D "cn=directory manager" -w secret -p 389 -h server.example.com dn: cn=TempValue,dc=example,dc=com changetype: modrdn newrdn: dc=NewValue deleteoldrdn: 1 Setting the value of the deleteoldrdn attribute to 1 deletes the temporary attribute-value pair cn=TempValue.
access";allow (read, search, compare)(userdn = "ldap:///anyone");) add: aci aci: (target="ldap:///dc=example,dc=com")(targetattr!="userPassword") (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.
Table 42 Replication errors (continued) Error/symptom Reason Impact Remedy the M1's Console or M1 or M2's errors log). Also, M2 should not initialize M1 back. Warning: data for replica's was reloaded, and it no longer matches the data in the changelog. Recreating the changelog file. This could affect replication with replica's consumers, in which case the consumers should be reinitialized. This message may appear only when a supplier is restarted.
Table 42 Replication errors (continued) Error/symptom Reason Impact Remedy Where 1d means 1 day. Other valid time units are s for seconds, m for minutes, h for hours, and w for weeks. A value of 0 turns off the purge. With changelog purge turned on, a purge thread that wakes up every five minutes will remove a change if its age is greater than the value of nsslapd-changelogmaxage and if it has been replayed to all the direct consumers of this supplier (supplier or hub).
9 Synchronizing Directory Server with Microsoft Active Directory Windows Sync carries over changes in a directory — adds, deletes, and changes in groups, users, and passwords — between Directory Server and Microsoft Active Directory. This makes it much more efficient and effective to maintain consistent information across directories.
The Password Sync Service must be installed on every Active Directory domain controller. Figure 19 Active Directory - Directory Server synchronization process Synchronization is configured and controlled by one or more synchronization agreements, which establishes synchronization between sync peers, the directory servers being synchronized. These are similar in purpose to replication agreements and contain a similar set of information, including the host name and port number for Active Directory.
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. • On the Directory Server, only entries with the ntUser or ntGroup object classes and attributes can be synchronized.
NOTE: To synchronize passwords (which is the only way for users to be active on both Directory Server and Active Directory), synchronization must be configured to run over TLS/SSL. Therefore, this configuration section assumes that TLS/SSL must also be configured. Configuring synchronization over TLS/SSL is also similar to configuring replication over TLS/SSL. Both sync peers must be configured to trust each other for encrypted sessions (all password operations are performed over TLS/SSL).
d. e. Select the Enable SSL for this Server checkbox, then select the certificate to use from the drop-down menu. Click Save. Restart the Directory Server. The Directory Server must be restarted from the command line. /opt/dirsrv/slapd-instance_name/restart-slapd example To restart the Directory Server without the password prompt, create a PIN file or use a hardware crypto device. See “Creating a password file for the Directory Server” (page 485) for information on how to create a PIN file.
For more information on the .inf request file, see the Microsoft documentation, such as http://technet.microsoft.com/en-us/library/cc783835.aspx. b. Generate the certificate request. certreq -new request.inf request.req c. Submit the request to the Active Directory CA. For example: certreq -submit request.req certnew.cer NOTE: If the command-line tool returns an error message, then use the Web browser to access the CA and submit the certificate request.
/opt/dirsrv/slapd-instance_name/stop-slapd 2. Add a new entry, such as cn=sync user,cn=config, with a password at the end of /etc/opt/dirsrv/slapd-instance_name/dse.ldif. For example: dn: cn=sync user,cn=config objectClass: inetorgperson objectClass: person objectClass: top cn: sync user sn: SU userPassword: secret passwordExpirationTime: 20380119031407Z 3. Restart the Directory Server.
Click 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 is not enabled, and password synchronization will not function. The first attempt to synchronize passwords, which happened when the Password Sync application is installed, will always fail because the SSL connection between the Directory Server and Active Directory sync peers.
Table 43 Installed Password Sync libraries (continued) Directory Library C:\Program Files\HP-UX Directory Password Synchronization key3.db C:\WINDOWS\system32 nssutil3.dll C:\Program Files\HP-UX Directory Password Synchronization nsldap32v60.dll C:\WINDOWS\system32 softtokn3.dll C:\Program Files\HP-UX Directory Password Synchronization nsldappr32v60.dll C:\WINDOWS\system32 smime3.dll C:\Program Files\HP-UX Directory Password Synchronization nsldapssl32v60.dll C:\WINDOWS\system32 freebl3.
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 after it has been hashed in Active Directory.
Then, create the supplier replica entry: ldapmodify -a -D "cn=directory manager" -w secret -p 389 -h server.example.
5. In the Windows Sync Server Info window, fill in the Active Directory information in the Windows Domain Information area. • The name of the Windows domain. • What kinds of entries to synchronize; users and groups are synchronized independently. When a type of entry is chosen, then all the entries of that type that are found in the Windows subtree are created in the Directory Server. • The Windows and Directory Server subtree information; this is automatically filled in.
6. Set the connection type. There are three options: • Use LDAP This sets either a standard, unencrypted connection. • Use TLS/SSL This uses a secure connection over the server's secure LDAPS port, such as 636. Both the Directory Server and the Windows server must be properly configured to run in TLS/SSL for this connection and must have installed each other's CA certificates in order to trust their server certificates.
1. 2. 3. 4. 5. Go to the Configuration tab in the Console. Open the Replication folder and expand the appropriate database. Select the sync agreement. Right-click on the agreement or open the Object menu. Select Initiate Full Re-synchronization. If synchronization stops for any reason, begin another total update (resynchronization) by selecting this from the sync agreement menu. Beginning a total update (resynchronization) will not delete or overwrite the databases.
attribute (even on an existing entry) signals to the syncrhonization plug-in to write the entry over to the Active Directory server. New users that are created on the Directory Server with the ntUser object class are synchronized to the Windows machine at the next regular update, which is a standard poll of entry.
Table 44 User schema mapped between Directory Server and Active Directory (continued) Directory Server Active Directory ntUserScriptPath scriptPath ntUserLastLogon lastLogon ntUserLastLogoff lastLogoff ntUserAcctExpires accountExpires ntUserCodePage codePage ntUserLogonHours logonHours ntUserMaxStorage maxStorage ntUserProfile profilePath ntUserParms userParameters ntUserWorkstations userWorkstations 1 The cn is treated differently than other synchronized attributes.
Values for cn attributes In Directory Server, the cn attribute can be multi-valued, while in Active Directory this attribute must have only a single value. When the Directory Server cn attribute is synchronized, then, only one value is sent to the Active Directory peer.
Configuring user sync in the console 1. 2. In the Directory Server Console, select the Directory tab. For an existing entry, right-click the entry, and click Properties to open the property editor for the entry. For a new entry, right-click the main entry in the left window to add the new entry, select User, then fill in the required entry attributes. 3. 4. On the left side of the Property Editor, click the NT User link. In the NT User tab, check the Enable NT Attributes checkbox. 5.
Three schema elements are required for synchronization: • The ntUser object class • The ntUserDomainID attribute, to give the Windows ID • The ntUserCreateNewAccount attribute, to signal to the synchronization plug-in to synchronize the Directory Server entry over to Active Directory For example: ldapmodify -D "cn=directory manager" -w secret -p 389 -h server.example.
3. 4. Open the Connection tab. Check the New Windows User Sync checkbox to enable users sync. To disable sync, uncheck the box. For new synchronization agreements, select the corresponding users sync checkbox in the sync agreement creation wizard. Configuring user sync in the command line The attribute to set Active Directory user sync is nsds7NewWinUserSyncEnabled and is set on the sync agreement.
cn=mapping tree, cn=config changetype: modify replace: nsds7NewWinUserSyncEnabled nsds7NewWinUserSyncEnabled: on To disable user synchronization, set nsds7NewWinUserSyncEnabled: off. Synchronizing groups Like user entries, groups are not automatically synchronized between Directory Server and Active Directory.
Some attributes define the same information, but the names of the attributes or their schema definitions are different. These attributes are mapped between Active Directory and Directory Server, so that attribute A in one server is treated as attribute B in the other. For synchronization, many of these attributes relate to Windows-specific information. Table 46 (page 413) shows the attributes that are mapped between the Directory Server and Windows servers.
5. Setting the ntGroup object class automatically adds the ntUserDomainId attribute. This attribute is required, so add a value. 6. To enable synchronization, click the Add Attribute button, and select the ntGroupCreateNewAccount attribute from the list. Then, set its value to on. This signals to the synchronization plug-in that the entry should be added to the Active Directory directory.
Configuring group sync in the command line To enable synchronization through the command line, add the required sync attributes to an entry or create an entry with those attributes. Three schema elements are required for synchronization: • The ntGroup object class. • The ntUserDomainID attribute, to give the Windows ID for the entry. • The ntGroupCreateNewAccount attribute, to signal to the synchronization plug-in to synchronize the Directory Server entry over to Active Directory.
3. 4. Open the Connection tab. Check the New Windows Group Sync checkbox to enable group synchronization. To disable synchronization, uncheck the box. For new synchronization agreements, select the corresponding group sync checkbox in the sync agreement creation wizard. Configuring group sync in the command line The attribute to set Active Directory group sync is nsds7NewWinGroupSyncEnabled and is set on the synchronization agreement.
cn=mapping tree, cn=config changetype: modify replace: nsds7NewWinGroupSyncEnabled nsds7NewWinGroupSyncEnabled: on To disable group synchronization, set nsds7NewWinGroupSyncEnabled: off. Deleting and resurrecting entries This section describes how enabling synchronization affects deleted entries on the synchonization peers and how resurrected entries are handled. Deleting entries All changes on an Active Directory peers are always synchronized back to the Directory Server.
Sending synchronization updates Synchronization occurs as frequently as is set in the winSyncInterval setting (for retrieving changes from the Active Directory domain) or nsds5replicaupdateschedule setting (for pushing changes from the Directory Server). By default, changes are retrieved from Active Directory every five minutes, and changes from the Directory Server are sent immediately. A sync update can be triggered manually.
Sending a total update (full synchronization) If there have been major changes to data, or synchronization attributes are added to pre-existing Directory Server entries, it is necessary to initiate a resynchronization. Resynchronization is a total update; the entire contents of synchronized subtrees are examined and, if necessary, updated. Resynchronization is done without using the changelog. This is similar to initializing or reinitializing a consumer in replication. 1.
add: nsDS5BeginReplicaRefresh nsDS5BeginReplicaRefresh: true This attribute is removed from the entry as soon as the update is complete. Checking synchronization status Check synchronization status in the Replication tab in the Status of the Console. Highlight the synchronization agreement to monitor, and the relevant information should appear in the right-hand pane. The Status area shows whether the last incremental and total updates were successful and when they occurred. 1.
Editing the sync agreement in the console Most of the information that can be edited in the Console is limited to connection information, including the protocol to use and the bind credentials. It is also possible to edit the synchronization agreement description. 1. In the Configuration tab, expand the Replication folder. 2. Expand the database being synchronized. All the synchronization agreements are listed below the database. Double-click the synchronized agreement to open it in the main window. 3.
There are three areas of information that can be edited. • The connection type (standard, TLS/SSL, and Start TLS). • The bind user, both DN and password. • Whether to synchronize new Directory Server users and new Directory Server groups automatically.
Creating a basic sync agreement The most basic synchronization agreement defines the Directory Server database and the Active Directory sync peer: • • For the Directory Server database: ◦ The replicated subtree in the directory (nsds7DirectoryReplicaSubtree) ◦ The Directory Server root DN (nsDS5ReplicaRoot) For the Active Directory domain: ◦ The replicated subtree in the Active Directory domain (nsds7WindowsReplicaSubtree) ◦ The Active Directory domain name (nsds7WindowsDomain) It also defines t
NOTE: The synchronization times cannot wrap around midnight, so the setting 2300-0100 is not valid. To change how frequently the Directory Server checks the Active Directory for changes to Active Directory entries, reset the winSyncInterval attribute. This attribute is set in seconds, so the default of 300 means that the Directory Server polls the Active Directory server every 300 seconds, or five minutes.
Table 48 Sync agreement attributes (continued) Object class or attribute Description To use Start TLS, which initiates a secure connection over a standard port, use the standard port, 389, with the nsds5ReplicaTransportInfo attribute to TLS. nsds5replicatransportinfo To use TLS/SSL, set this parameter to SSL. To use Start TLS, which initiates a secure connection over a standard port, set this parameter to TLS. To use simple authentication, set this parameter to LDAP.
NOTE: A synchronization agreement needs to be configured for both kinds of unidirectional synchronization. To only synchronize Directory Server entries, then do not set the Active Directory sync attributes in the sync agreement. Likewise, to only synchronize Active Directory over to Directory Server, do not add any sync attributes to Directory Server entries. Password sync service The Password Sync Service must be installed on every Active Directory domain controller.
1. 2. In the Console, click the Configuration tab, select Logs from the navigation menu on the right, and open the errors log. Scroll down to errors log level, and select Replication from the menu. Click save. For complete information on errors log levels, refer to HP-UX Directory Server configuration, command, and file reference. Error #1: The message box when creating the sync agreement indicates that it cannot connect to Active Directory.
10 Managing the Directory Schema HP-UX Directory Server comes with a standard schema that includes hundreds of object classes and attributes. While the standard object classes and attributes should meet the requirements of most deployments, it may be necessary to extend the schema for specific directory data. Extending the schema is done by creating new (custom) object classes and attributes.
Example 20 person object class schema entry objectClasses: ( 2.5.6.6 NAME 'person' DESC 'Standard LDAP objectclass' SUP top MUST ( sn $ cn ) MAY ( description $ seeAlso $ telephoneNumber $ userPassword ) X-ORIGIN 'RFC 2256' ) Every object class defines a number of required attributes and of allowed attributes.
2. 3. Server itself does not manage OIDs, but there are some best practices described in “Managing object identifiers” (page 431). Create the new attributes. Attribute definitions require a name, a syntax (the allowed format of the values), an OID, and a description of whether the attribute can only be used once per entry or multiple times. Create an object class to contain the new attributes. An object class lists the required attributes for that entry type and the allowed (permissible) attributes.
the changes do not show up in the changelog, these newly-loaded schema files are not replicated. In order to load those schema files on any other servers, the schema has to be copied over, then a local reload task has to be run. Managing object identifiers Each LDAP object class or attribute must be assigned a unique name and object identifier (OID). An OID is a dot-separated number that identifies the schema element to the server.
Table 49 LDAP attribute syntax (continued) Name OID Definition OctetString 1.3.6.1.4.1.1466.115.121.1.40 Indicates that values for this attribute are binary; this is the same as using the binary synatx. Postal Address 1.3.6.1.4.1.1466.115.121.1.41 Indicates that values for this attribute are encoded in the format postal-address =dstring* ("$"dstring). For example: 1234 Main St.$Raleigh, NC 12345$USA Each dstring component is encoded as a DirtectoryString value.
3. There are three tabs that display the schema elements loaded in Directory Server: Object Class, Attributes, and Matching Rules. The Attributes tab is broken into two sections for default and custom attributes. Both sections show the attribute name, OID, syntax, and whether the attribute is multi-valued. The Object Classes tab shows the list of object classes on the left.
Creating attributes NOTE: After adding new attributes to the schema, create a new object class to contain them, as described in “Creating object classes” (page 436). 1. 2. Select the Configuration tab. In the left navigation tree, select the Schema folder, then select the Attributes tab in the right pane.
3. Click Create. 4. Fill in the information for the new attribute. • The attribute name; this must be unique. • The OID; this is not required, but for compatibility and server performance, assigning a unique numeric OID is strongly recommended.
5. • The syntax; this is the allowed format for the attributes values. • Whether the attribute is multi-valued; by default, all attributes can be used more than once in an entry, but deselecting the checkbox means the attribute can be used only once. Click OK. Creating object classes A new object class must be created with a unique name, a parent object, and required and optional attributes. To create an object class: 1. In the Directory Server Console, select the Configuration tab. 2.
4. Fill in the information about the new object class.
• The name; this must be unique. • The OID; this is not required, but for compatibility and server performance, assigning a unique numeric OID is strongly recommended. • The superior object class for the entry. The default is top; selecting another object class means that the new object class inherits all the required and allowed attributes from the parent, in addition to its own defined attributes. • Required and allowed attributes.
Editing custom schema elements Only user-created attributes or object classes can be edited; standard schema elements cannot be edited. 1. In the Directory Server Console, select the Configuration tab. 2. In the left navigation tree, select the Schema folder. 3. 4. 5. Open the Object Classes or Attributes tab. Select the schema element to edit from the list. Only custom (user-defined) schema can be edited in the Directory Server Console. Click the Edit button at the bottom of the window.
6. Edit any of the schema information. Deleting schema Only user-created attributes or object classes can be deleted; standard schema elements cannot be deleted. 1. In the Directory Server Console, select the Configuration tab. 2. In the left navigation tree, select the Schema folder. 3. Open the Object Classes or Attributes tab.
4. 5. Select the schema element to delete from the list. Only custom (user-defined) schema can be deleted in the Directory Server Console. Click the Delete button at the bottom of the window. 6. Confirm the deletion. CAUTION: The server immediately deletes the schema element. There is no undo. Managing schema using ldapmodify As with the Directory Server Console, ldapmodify can be used to add, edit, and delete custom schema elements.
The object class definition contains several components: • An OID, usually a dot-separated number • A unique name, in the form NAME name • A description, in the form DESC description • The superior, or parent, object class for this object class, in the form SUP object_class; if there is no related parent, use SUP top • The word AUXILIARY, which gives the type of entry to which the object class applies; AUXILIARY means it can apply to any entry • A list of required attributes, preceded by the word
Creating custom schema files Schema files are simple LDIF files that define the cn=schema entry. Each attribute and object class is added as an attribute to that entry. Here are the requirements for creating a schema file: • The first line must be dn: cn=schema. • The schema file can include both attributes and object classes; alternatively, it can include only one or the other.
For example: objectclasses: ( 2.16.840.1133730.2.123 NAME 'examplePerson' DESC 'Ex\ ample Person Object Class' SUP inetorgPerson AUXILIARY MUST cn MAY (exampleDateOfBirth $ examplePreferredOS) ) Example 22 “Example schema file” shows a simplified schema file. Example 22 Example schema file dn: cn=schema attributetypes: ( 2.16.840.1133730.1.123 NAME 'dateofbirth' DESC 'For em\ ployee birthdays' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Example defined') objectclasses: ( 2.16.840.1133730.2.
Reloading schema using ldapmodify The schema-reload.pl script creates a special task entry in a Directory Server instance that reloads schema files; it is also possible to reload schema by creating the task entry directly. Task entries occur under the cn=tasks configuration entry in the dse.ldif file, so it is also possible to initiate a task by adding the entry using ldapmodify. As soon as the task is complete, the entry is removed from the directory.
[06/Jan/2009:17:52:04 -0500] schemareload - Schema validation passed. [06/Jan/2009:17:52:04 -0500] schemareload - Schema reload task finished. If there is a failure, then the log shows which step failed and why. [..] ... [..] [..] [..] schemareload - Schema reload task starts (schema dir: /bogus) schema - No schema files were found in the directory /bogus schema_reload - schema file validation failed schemareload - Schema validation failed.
4. Click Save. To turn schema checking on and off using LDAP commands, edit the value of the nsslapd-schemacheck attribute. For example: ldapmodify -h myserver -p 389 -D "cn=directory manager" -w secret dn: cn=config changetype: modify replace: nsslapd-schemacheck: on nsslapd-schemacheck: off For information, see the HP-UX Directory Server configuration, command, and file reference. Syntax Validation Checking The current version of directory server provides the capability to enforce syntax validation.
Validation is skipped for the following binary content: • Fax • OctetString • JPEG Configuration A new configuration attribute named nsslapd-syntaxcheck is added to the cn=config entry. The valid values for the entry are on and off. By default, the value is set to off. To enable syntax checking, use ldapmodify to set nsslapd-syntaxcheck to on. ldapmodify -D "cn=directory manager" -w secret \ -h server.example.
directory trees. For example, spaces between the RDN components is not allowed, but the practise of usage is allowed since they were allowed in the previous specification outlined in RFC 1779. A configuration attribute nsslapd-dn-validate-strict is provided to deal with the special circumstances around validation of the DN syntax. This configuration attribute ensures that the value strictly adheres to the rules defined in RFC 4514, section 3 if it is set to on.
11 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, then describes how to create, delete, and manage indexes.
search for telephonenumber= *555* returns all the entries in the directory with telephone numbers that contain 555. • International index speeds up searches for information in international directories. The process for creating an international index is similar to the process for creating regular indexes, except that it applies a matching rule by associating an object identifier (OID) with the attributes to be indexed.
Table 50 Default indexes (continued) Attribute Eq Pres Sub Purpose uid Improves Directory Server performance. unique member Improves Directory Server performance. This index is also used by the Referential Integrity Plug-in. See “Maintaining Referential Integrity” (page 127) for more information. Overview of system indexes System indexes cannot be deleted or modified. They are required by the directory to function properly. Table 51 (page 452) lists the system indexes included with the directory.
3. • If a search request contains multiple attributes, the directory consults multiple indexes, then combines the resulting lists of candidate entries. • If there is an index for the attribute, the directory takes the candidate matches from the index files in the form of a series of entry ID numbers. The directory uses the returned entry ID numbers to read the corresponding entries from the id2entry.db4 file.
Balancing the benefits of indexing 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).
8. 9. Create the appropriate telephone number substring index entries for 408 555 8834. Create the appropriate description substring index entries for Manufacturing lead for the Z238 line of widgets. A large number of substring entries are generated for this string. As this example shows, the number of actions required to create and maintain databases for a large directory can be resource-intensive.
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 white space. For a list of languages, their associated OIDs, and further information regarding collation orders, see “Internationalization” (page 574). 8. 9. Click Save.
dn: cn=sn,cn=index,cn=Example1,cn=ldbm database,cn=plugins,cn=config 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.
Table 55 (page 464) describes the db2index.pl options: Table 52 db2index.pl options Option Description -D Specifies the DN of the administrative user. -w Specifies the password of the administrative user. -n Specifies the name of the database being indexed. -t Specifies the name of the attribute contained by the index.
For more information on how to change the VLV search information or the access control rules that are set by default for VLV searches, see “Adding a browsing index entry” (page 459) and “Setting access control for VLV information” (page 461). Creating browsing indexes from the command line Creating a browsing index or virtual list view (VLV) index from the command line has these steps: 1. Using ldapmodify to add new browsing index entries or edit existing browsing index entries.
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. 3. • The vlvbase attribute value specifies the entry on which you want to create the browsing index; in this example, the ou=People,dc=example,dc=com entry (the browsing index identifier). • The vlvscope attribute is 1, indicating that the scope for the search you want to accelerate is 1.
Table 53 vlvindex options Option Description -n Name of the database containing the entries to index. -T Browsing index identifier to use to create browsing indexes. Using a cn=tasks entry to create a browsing index As an alternative to running the vlvindex script, it is possible to initiate an indexing task directly. NOTE: Running the indexing task is the same as running the vlvindex script.
To improve search performance, particularly for sites with many wildcard searches, the search string length for indexed searches can be changed. Directory Server has three attributes that allow you to change the minimum number of characters required for an indexed search: • The nsSubStrBegin attribute sets the required number of characters for an indexed search for the beginning of a search string, before the wildcard.
• “Deleting browsing indexes from the server console” (page 465) • “Deleting browsing indexes from the command line” (page 465) CAUTION: Do not delete system indexes because deleting them can significantly affect Directory Server performance. System indexes are located in the cn=index,cn=instance,cn=ldbm database,cn=plugins,cn=config entry and the cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config entry.
1. Run ldapdelete. ldapdelete -D "cn=Directory Manager" -w secret -h ExampleServer -p 389 "cn=sn,cn=index,cn=Example1,cn=ldbm database,cn=plugins,cn=config" For complete information on ldapdelete, see the HP-UX Directory Server configuration, command, and file reference. 2.
Deleting browsing indexes from the server console To delete a browsing index through the Directory Server Console: 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. Alternatively, select and right-click the entry of the index to delete in the navigation tree, then choose Delete Browsing Index from the pop-up menu. 3. 4.
The following table describes the ldapdelete options used in the example: Option 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. -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.
application's search request; “About indexes” (page 450) describes each kind of Directory Server index. The Directory Server secondary index structure greatly improves write and search operations. 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.
Because loading a long ID list from the database can significantly reduce search performance, the configuration parameter, nsslapd-idlistscanlimit, sets a limit on the number of IDs that are read before a key is considered to match the entire primary index. nsslapd-idlistscanlimit is analogous to the All IDs Threshold, but it only applies to the behavior of the server's search code, not the content of the database.
Table 56 Attribute name quick reference table Attribute primary name Attribute alias dn distinguishedName cn commonName sn surName c countryName l localityName st stateOrProvinceName street streetAddress o organization ou organizationalUnitName facsimileTelephoneNumber fax uid userId mail rfc822mailbox mobile mobileTelephoneNumber pager pagerTelephoneNumber co friendlyCountryName labeledUri labeledUri ttl timeToLive dc domainComponent authorCn documentAuthorCommonName
12 Managing SSL To provide secure communications over the network, HP-UX 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. 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 “Obtaining and installing server certificates” (page 472). 2. Turn on TLS/SSL in the directory. For information, see “Starting the server with TLS/SSL enabled” (page 481). 3. 4. Configure the Administration Server connect to an SSL-enabled Directory Server.
With the -ZZZ option, the following errors could occur, causing the Start TLS operation to fail: • If there is no certificate database. See “Obtaining and installing server certificates” (page 472) for information on using certificates. • If the certificate database does not have the certificate authority (CA) certificate. See “Obtaining and installing server certificates” (page 472) for information on using certificates. • The server does not support Start TLS as an extended operation.
Step 1: Generate a certificate request Generate a certificate request, and send it to a CA. The Directory Server Console has a tool, the Certificate Request Wizard, which generates a valid certificate request to submit to any certificate authority (CA). 1. In the Directory Server Console, select the Tasks tab, and click Manage Certificates. 2. Select the Server Certs tab, and click the Request button. 3. Click Next. 4. Enter the Requester Information in the blank text fields, then click Next.
• Server Name Enter the fully qualified host name 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.
The Next button is grayed out until a password is supplied. 7. 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 that will be submitted to the CA.
8. Click Done to dismiss the Certificate Request Wizard. After generating the certificate request, send it to the CA. 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. Copy the certificate request information from the clipboard or the saved file into the body of the message.
Step 3: Install the certificate 1. 2. 3. 4. 5. 6. In the Directory Server Console, select the Tasks tab, and click Manage Certificates. Select the Server Certs tab, and click Install. Give the certificate location or paste the certificate text in the text box, then click Next. • In this file. Enter the absolute path to the certificate in this field. • In the following encoded text block. Copy the text from the CA's email or from the created text file, and paste it in this field.
5. 6. Name the certificate, and click Next. Select the purpose of trusting this certificate authority; it is possible to select both options: • Accepting connections from clients (Client Authentication). The server checks that the client's certificate has been issued by a trusted certificate authority.
and it must be set as readonly for the Directory Server user and allow no access to anyone else (mode 0400). HP recommends that you have a secure backup of this file. 4. Set the environment variable for the shell to include the certutil directory path. For example: export PATH=/opt/dirsrv/bin/:$PATH The command varies depending on the shell. 5. Create the key and certificate databases databases. certutil -N -d . -f ./pwdfile 6. Generate the self-signed CA certificate.
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 “Creating a password file for the Directory Server” (page 485).
Table 57 certutil options (continued) Options Description -o The output file to which to save the certificate request. -I An input file containing a certificate. -f The path to a password file for the security databases password. Table 58 (page 481) has some common uses for the certutil command. Table 58 certutil examples Example Description certutil -L -d . Lists the certificates in the database. certutil -N -d . Creates new key (key3.db) and certificate (cert8.db) databases.
Enabling TLS/SSL only in the Directory Server 1. 2. Obtain and install CA and server certificates. Set the secure port for the server to use for TLS/SSL communications. The encrypted port number must not be the same port number used for normal LDAP communications. By default, the standard port number is 389, and the secure port is 636. a. Change the secure port number in the Configuration>Settings tab of the Directory Server Console. b. Restart the Directory Server. It restarts over the regular port. 3.
10. Click Save. 11. Restart the Directory Server. The Directory Server must be restarted from the command line. /opt/dirsrv/slapd-instance_name/restart-slapd 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.
NOTE: To use certificate-based authentication with replication, then configure the consumer server either to allow or to require client authentication. 10. To verify the authenticity of requests, select the Check hostname against name in certificate for outbound SSL connections option. The server does this verification by matching the host name against the value assigned to the common name (cn) attribute of the subject name in the being presented for authentication. By default, this feature is disabled.
Creating a password file for the Directory Server It is possible to store the certificate password in a password file. By placing the certificate database password in a file, the server can be started from the Directory Server Console and also restarted automatically when running unattended. 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.
/opt/dirsrv/sbin/restart-ds-admin For more information about the commands to start, stop, and restart the Directory Server, see “Starting and Stopping Servers” (page 20). Using external security devices A security module serves as a medium between the Directory Server and the SSL layer. The module stores the keys and certificates used for encryption and decryption. The standard that defines these modules is Public Key Cryptography Standard (PKCS) #11, so these modules are PKCS #11 modules.
• 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. The Mozilla site, http://www.mozilla.org/projects/security/pki/nss/nss-3.11/ nss-3.11-algorithms.html for definitions and explanations of the encryption algorithms. NOTE: Directory Server supports ciphers for TLSv1 (recommended) and SSLv3. SSLv2 support is deprecated and not enabled by default in Directory Server.
Table 60 SSLv3 ciphers (continued) Directory Server name Key exchange Encryption algorithm Symmetric key bit size Message authentication rsa_null_md5 RSA null (none) N/A MD5 fortezza fortezza fortezza 80 SHA fortezza_rc4_128_sha fortezza RC4 128 SHA fortezza_null fortezza null (none) N/A SHA Selecting the encryption cipher To select the ciphers for the Directory Server to use: 1. Make sure TLS/SSL is enabled for the server.
NOTE: A single configuration parameter, nsslapd-certdir, in cn=config in dse.ldif lists the directory containing the key, certificate, and security files. The directory name should be unique and specific to the server. For example, the /etc/opt/dirsrv/slapd-instance_name directory contains the key and certificate databases only for the Directory Server instance called instance_name.
Three things are required for the Directory Server to allow client authentication: • The server must have SSL turned on. See “Starting the server with TLS/SSL enabled” (page 481) for more information. • The Administration Server must trust the CA who issued the certificate to the client, as described in step 6 of “Step 4: Trust the certificate authority” (page 477). • The subject DN in the certificate must be mapped in the user DN through a mapping in the certmap.
a. b. Select the Directory tab, and navigate to the user entry. Double-click the user entry, and use the Property Editor to add the userCertificate attribute, with the binary subtype. When adding this attribute, instead of an editable field, the server provides a Set Value button. c. Click Set Value. A file selector opens. Use it to select the binary file created in step 3.
The first line of a mapping specifies the mapping's name as well as the DN for the issuer of the client certificate. The mapping can have any name, but the issuerDN must exactly match the issuer DN of the CA that issued the client certificate.
For example, if FilterComps is set to use the e and uid attribute keywords (FilterComps=e,uid), the server searches the directory for an entry whose values for e and uid match the user's information gathered from the client certificate. Email addresses and user IDs are good filters because they are usually unique entries in the directory. The filter needs to be specific enough to match one and only one entry in the directory.
Editing the certmap.conf file 1. 2. In a text editor, open /etc/opt/dirsrv/slapd-instance/certmap.conf If necessary, make changes to the default mapping. For example, change the value for DNComps or FilterComps. To comment out a line, insert a # before it. 3. If desired, create a mapping for a specific CA. The mapping should take the form certmap mappingName issuerDN.
Example 24 An additional mapping certmap default default:DNComps default:FilterComps certmap MyCA MyCA:DNComps MyCA:FilterComps MyCA:verifycert default e, uid ou=MySpecialTrust,o=MyOrg,c=US ou,o,c e on When the server gets a certificate from a CA other than MyCA, the server uses the default mapping, which starts at the top of the directory tree and searches for an entry matching the client's email address (e) and user ID (uid).
• 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. • Require client authentication With this option, the server requests authentication from the client.
Connecting to the Directory Server with certificate-based authentication The Directory Server can connect to another Directory Server instance for chaining or replication using certificate-based authentication, as configured in the database link or replication agreement. Users can connect to the Directory Server with certificate-based authentication when using LDAP tools such as ldapsearch.
4. 5. Click the Edit Trust button. Set the CA trust options. • Accepting connections from clients (Client Authentication) This option sets whether to accept client, or user, certificates issued by the CA. • Making connections to other servers (Server Authentication) This option sets whether to accept server certificates issued by the CA. • Click OK. Changing security device passwords Periodically change the settings for the security databases or devices. 1.
A new ACI keyword minssf allows you to set access control based on how secure the connection is. Consider the following example for ACI that requires a SSF of 56 for you to modify your password: aci: (targetattr="userPassword")(version 3.
13 Managing SASL HP-UX 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. The SASL framework allows different mechanisms to be used to authenticate a user to the server, depending on what mechanism is enabled in both client and server applications. SASL also creates a layer for encrypted (secure) sessions.
About SASL identity mapping When processing a SASL bind request, the server matches, or maps, the SASL authentication ID used to authenticate to the Directory Server with an LDAP entry stored within the server. When using Kerberos, the SASL user ID usually has the format userid@REALM, such as scarter@EXAMPLE.COM. This ID must be converted into the DN of the user's Directory Server entry, such as uid=scarter,ou=people,dc=example,dc=com.
dn: cn=example map,cn=mapping,cn=sasl,cn=config objectclass: top objectclass: nsSaslMapping cn: example map nsSaslMapRegexString: \(.*\) nsSaslMapBaseDNTemplate: ou=People,dc=example,dc=com nsSaslMapFilterTemplate: (cn=\1) This matches any user ID and map it an entry under the ou=People,dc=example,dc=com subtree that meets the filter cn=userId. Mappings can be confined to a single realm by specifying the realm in the nsSaslMapRegexString attribute.
TIP: SASL mappings can be added when an instance is created during a silent installation by specifying the mappings in an LDIF file and adding the LDIF file with the ConfigFile directive. Using silent installation is described in the HP-UX Directory Server installation guide. Default SASL mappings for Directory Server The Directory Server has pre-defined SASL mapping rules to handle some of the most common usage.
Authentication mechanisms for SASL in Directory Server Directory Server support the following SASL encryption mechanisms: • EXTERNAL EXTERNAL, as with TLS/SSL, performs certificate-based authentication. This method uses public keys for strong authentication. • CRAM-MD5 CRAM-MD5 is a simple challenge-response authentication method. It does not establish any security layer, unlike GSS-API. Both DIGEST-MD5 and GSS-API are much more secure, so both of those methods are recommended over CRAM-MD5.
NOTE: Kerberos realms are only supported for GSS-API authentication and encryption, not for DIGEST-MD5. Realms are used by the server to associate the DN of the client in the following form, which looks like an LDAP DN: uid=user_name/[server_instance],cn=realm,cn=mechanism,cn=auth For example, Mike Connors in the engineering realm of the European division of example.com uses the following association to access a server in the US realm: uid=mconnors/cn=Europe.example.
host-fqdn must be the fully-qualified host and domain name, which can be resolved by all LDAP and Kerberos clients through both DNS and reverse DNS lookups. A key with this identity must be stored in the server's keytab in order for Kerberos to work. Whatever server the Directory Server is authenticating to must have a SASL mapping that maps the Directory Server's principal (its user entry, usually something like ldap/server.example.com@EXAMPLE.COM) to a real entry DN in the receiving server.
• 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 This field gives the base DN to search to map entries, such as ou=People,dc=example,dc=com. This field corresponds to the nsSaslMapBaseDNTemplate value in the SASL mapping LDIF entry.
NOTE: When SASL maps are added over LDAP, they are not used by the server until it is restarted. Adding the SASL map with ldapmodify adds the mapping to the end of the list, regardless of its ASCII order. Configuring SASL authentication at Directory Server startup SASL GSS-API authentication has to be activated in Directory Server so that Kerberos tickets can be used for authentication.
14 Monitoring Server and Database Activity This chapter describes monitoring database and HP-UX Directory Server logs. For information on using SNMP to monitor the Directory Server, see “Monitoring Directory Server Using SNMP” (page 532).
6 Read and write 7 Read, write, and execute In the 3-digit number, the first digit represents the owner's permissions, the second digit represents the group's permissions, and the third digit represents everyone's permissions. When changing the default value, keep in mind that 000 will not allow access to the logs and that allowing write permissions to everyone can result in the logs being overwritten or deleted by anyone.
The log file deletion policy can be configured with the following parameters: • The maximum size of the combined archived logs When the maximum size is reached, the oldest archived log is automatically deleted. To avoid setting a maximum size, type -1 in this field. The default is 500 megabytes. This parameter is ignored if the maximum number of log files is set to 1.
4. 5. Enter the full path and file name for the directory to use for the access log in the Log File field. The default path is /var/opt/dirsrv/slapd-instance_name/log/access. Set the maximum number of logs, log size, and archive time period. For information on these parameters, see “Defining a log file rotation policy” (page 509). 6. Set the maximum size of combined archived logs, minimum amount of free disk space, and maximum age for a log file.
5. 6. Enter the full path and file name for the directory to use for the errors log in the Log File field. The default path is /var/opt/dirsrv/slapd-instance_name/log/errors directory. Set the maximum number of logs, log size, and time period when the file is archived. For information on these parameters, see “Defining a log file rotation policy” (page 509). 7. Set the maximum size of combined archived logs, minimum amount of free disk space, and maximum age for a log file.
3. To enable audit logging, select the Enable Logging checkbox. To disable audit logging, clear the checkbox. By default, audit logging is disabled. 4. 5. Enter the full path and file name for the directory to use for the audit log in the field provided. The default path is /var/opt/dirsrv/slapd-instance_name/log/audit. Set the maximum number of logs, log size, and time period when the file is archived. For information on these parameters, see “Defining a log file rotation policy” (page 509). 6.
The pipe script can monitor another process, such as the directory server. You will have to supply the PID of the process to the pipe script either directly, or by specifying the name of the file containing the PID. It is not necessary for a PID file to exist. The script checks the file for the PID till the timeout period. -s|--serverpidfile - name of file containing the server PID. -t|--servertimeout - number of seconds to wait for the PID file to exist and the PID to be running.
nsslapd-accesslog-logbuffering: off • nsslapd-accesslog - This parameter specifies the full path and filename of the named pipe. • nsslapd-accesslog-logbuffering - The script will do the buffering, so you can turn this parameter off. • nsslapd-accesslog-maxlogsperdir, nsslapd-accesslog-logexpirationtime, nsslapd-accesslog-logrotationtime - These parameters control log rotation. If using a pipe, you can disable the log rotation, so that the server does not rotate the log pipe.
kill "$errpid" > /dev/null 2>&1 fi fi # only keep the last 1000 lines of the error log python /opt/dirsrv/bin/ds-logpipe.py /var/opt/dirsrv/slapd-instance_name/log/errors.pipe -m 1000 -u nobody \ -s $RUN_DIR/slapd-instance_namev.pid \ -i $errpidfile >> /var/opt/dirsrv/slapd-instance_name/log/errors 2>&1 & # sleep gives the script a chance to create the pipe, if necessary sleep 1 accpidfile=$RUN_DIR/dslogpipe-srv-acc.
value for that key is the command line argument value. If there is more than one argument with the same name, they are converted to a list of values. --plugin=/path/to/pluginname.py pluginname.arg1=foo pluginname.arg1=bar pluginname.arg2=baz In the plug-in, this is converted to a dict like this: {'arg1': ['foo', 'bar'], 'arg2': 'baz'} post function The post function is called when the log script is exiting.
2. Add the attribute nsslapd-inmemory-debug-enabled: on under cn=config in the /etc/opt/dirsrv/slapd-< slapd-instance_name >/dse.ldif file: nsslapd-inmemory-debug-enabled: on 3.
3. Add the attribute nsslapd-inmemory-debug-enabled: on in /etc/opt/dirsrv/ slapd-/dse.ldif file, if it has not been added. For example: nsslapd-inmemory-debug-enabled: on 4. Start the server: /opt/dirsrv/slapd-instance_name/start-slapd Monitoring server activity The Directory Server's current activities can be monitored from either the Directory Server Console or the command line. It is also possible to monitor the activity of the caches for all the database.
Table 61 General information (server) Field Description Server Version Identifies the current server version. Configuration DN Identifies the distinguished name that must be used as a search base to obtain these results using the ldapsearch command line utility. This field should read cn=monitor. Data Version Provides identification information for the server's data. Usually the information shown here is only relevant if the server supplies replicas to consumer servers.
Table 62 Resource summary Resource Usage since startup Average per minute Connections The total number of connections to this server since server startup. Average number of connections per minute since server startup. Operations Initiated The total number of operations initiated since server startup. Operations include any client requests for server action, such as searches, adds, and modifies. Often, multiple operations are initiated for each connection.
Table 63 Current resource usage (continued) Resource Current total 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. In most cases, the latter value is determined by the operating system and is expressed as the number of file descriptors available to a task.
Table 65 Global database cache information Table header Description Hits The number of times the server could process a request by obtaining data from the cache rather than by going to the disk. Tries The total number of requests performed on the directory since server startup. Hit Ratio The ratio of cache tries to successful cache hits. The closer this number is to 100%, the better. Pages Read In The number of pages read from disk into the cache.
Table 66 Server monitoring attributes (continued) Attribute Description totalconnections Identifies the number of connections handled by the directory since it started. dtablesize Shows the number of file descriptors available to the directory. Each connection requires one file descriptor: one for every open index, one for log file management, and one for ns-slapd itself. Essentially, this value shows how many additional concurrent connections can be serviced by the directory.
3. Click Refresh to refresh the currently displayed information. For the directory to continuously update the displayed information, select the Continuous checkbox, then click Refresh. Table 67 General information (database) Field Description Database Identifies the type of database being monitored. Configuration DN Identifies the distinguished name that must be used as a search base to obtain these results using the ldapsearch command line utility.
Table 68 Summary information (continued) Performance metric Current total Maximum Entries in Cache attribute. See “Tuning database performance” (page 540) for information on changing this value using the Directory Server Console. Current Entry Cache Size (in Bytes) The total size of directory entries currently present in the entry cache. Maximum Entry Cache Size (in Bytes) The size of the entry cache maintained by the directory. This value is managed by the Maximum Cache Size setting.
Table 70 Database file-specific Performance metric Current total Cache Hits The number of times that a search result resulted in a cache hit on this specific file. That is, a client performs a search that requires data from this file, and the directory obtains the required data from the cache. Cache Misses The number of times that a search result failed to hit the cache on this specific file.
Table 71 Directory server monitoring attributes (continued) Attribute Description “Tuning database performance” (page 540) for information on changing this value using the Directory Server Console. dbcachehits The number of times the server could process a request by obtaining data from the cache rather than by going to the disk. dbcachetries The total number of requests performed on the directory since server startup. dbcachehitratio The ratio of cache tries to successful cache hits.
Table 72 Database link monitoring attributes (continued) Attribute Name Description 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. nsAbandonCount The number of abandon operations received. nsBindCount The number of bind request received. nsUnbindCount The number of unbinds received.
dn: cn=config changetype: modify replace:nsslapd-counters nsslapd-counters: off Enabling and disabling 64-bit integers for counters 531
15 Monitoring Directory Server Using SNMP The server and database activity monitoring log setup described in “Monitoring Server and Database Activity” (page 509) 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 that can be used to monitor a wide range of devices in real time. Directory Server can be monitored with SNMP through an AgentX subagent.
Configuring the master agent To use the subagent, you must have a master agent that supports AgentX. A common agent is Net-SNMP master agent, which may be available through your operating system vendor or can be downloaded from the Net-SNMP website: http://www.net-snmp.org. The SNMP subagent included with Directory Server uses the AgentX protocol to communicate with the SNMP master agent running on your system. You must make sure that you enable AgentX support on your master agent.
server slapd-phonebook server slapd-example server slapd-directory Starting the subagent After your master agent is running and you have created your subagent configuration file, start the subagent. To start your subagent, run the ldap-agent program, specifying the absolute path to the subagent configuration file as an argument. For example: ldap-agent /etc/opt/dirsrv/config/ldap-agent.
There are two traps supported by the subagent: • Directory ServerDown This trap is generated whenever the subagent detects the Directory Server is potentially not running. This trap will be sent with the Directory Server instance description, version, physical location, and contact information, which are detailed in the dsEntityDescr, dsEntityVers, dsEntityLocation, and dsEntityContact variables.
NOTE: All the Directory Server attributes monitored by SNMP use 64-bit integers for the counters, even on 32-bit systems. Enabling 64-bit integers for counters are configured with the nsslapd-counters configuration attribute, as described in “Enabling and disabling 64-bit integers for counters” (page 530). The counters that use 64-bit integers are not configurable; the 64-bit integers are either enabled for all the allowed counters or disabled for all allowed counters.
Table 73 Operations table: managed objects and descriptions (continued) Managed object Description dsSecurityErrors The number of operations forwarded to this directory that did not meet security requirements. dsErrors The number of requests that could not be serviced due to errors (other than security or referral errors). Errors include name errors, update errors, attribute errors, and service errors. Partially serviced requests will not be counted as an error.
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 76 (page 538) describes the managed objects stored in the Interaction Table of the hpds-directory.mib file.
16 Tuning Directory Server Performance This chapter describes the tools provided with HP-UX Directory Server to help optimize performance. It also provides tips to improve the performance of the directory.
Tuning database performance This section is divided into the following parts that describe methods for tuning database performance: • “Optimizing search performance” (page 540) • “Tuning transaction logging” (page 541) • “Changing the location of the database transaction log” (page 541) • “Changing the database checkpoint interval” (page 542) • “Disabling durable transactions” (page 542) • “Specifying transaction batching” (page 542) Optimizing search performance Improve server performance on se
1. Select the LDBM Plug-in Settings tab in the right pane. This tab contains the database attributes for all databases stored on this server. 2. 3. 4. In the Maximum Cache Size field, enter a value corresponding to the amount of memory to make available for all databases. In the Look-Through Limit field, enter the maximum number of entries for the server to check in response to a search request.
1. Stop the Directory Server. /opt/dirsrv/slapd-instance_name/stop-slapd 2. 3. In the dse.ldif file, locate the entry for the nsslapd-db-logdirectory attribute, cn=config,cn=ldbm database,cn=plugins,cn=config. Provide the full path to the log directory in the attribute. Start Directory Server.
To specify or modify transaction batching while the server is running, use the ldapmodify command line utility to add the nsslapd-db-transaction-batch-val attribute to the cn=config,cn=ldbm database,cn=plugins,cn=config entry. For more information on the syntax and values of the nsslapd-db-transaction-batch-val attribute, see HP-UX Directory Server configuration, command, and file reference. For instructions on using ldapmodify, see “Adding and modifying entries using ldapmodify” (page 113).
17 Support and Other Resources Contacting HP Information to collect before contacting HP Be sure to have the following information available before you call contact HP: • Software product name • Hardware product model number • Operating system type and version • Applicable error message • Third-party hardware or software • Technical support registration number (if applicable) How to contact HP technical support Use the following methods to contact HP technical support: • In the United States, s
Related information HP-UX Directory Server documentation set • HP-UX Directory Server release notes The release notes contain important information on new features, fixed bugs, known issues and workarounds, and other important information for this specific version of the HP-UX Directory Server. • HP-UX Directory Server administrator guide This guide contains information and procedures you need to perform to maintain your Directory Server.
HP-UX documentation set For the latest information about the HP-UX operating system, including current release notes, complete product documentation, technical notes, and white papers, see the HP-UX Operating Environments documentation sites for the version of HP-UX you use: • HP-UX 11i v3 Operating Environments: http://docs.hp.com/en/oshpux11iv3.html • HP-UX 11i v2 Operating Environments: http://docs.hp.com/en/oshpux11iv2.
CAUTION An alert that calls attention to important information that, if not understood or followed, results in data loss, data corruption, or damage to hardware or software. IMPORTANT An alert that calls attention to essential information. NOTE An alert that contains additional or supplementary information. TIP An alert that provides helpful information.
A LDAP data Interchange Format HP-UX 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.
Table 77 LDIF fields (continued) Field Definition 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. See “Managing the Directory Schema” (page 428) for information on customizing the schema. attribute_type Specifies a descriptive attribute to use with the entry. The attribute should be defined either in the schema.
Base-64 encoding Binary data can be converted to base-64, which can be used in LDIF files, for a variety of data, from images to SSL certificates. Base 64-encoded data are identified by using the :: symbol. 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.
Table 78 LDIF elements in domain entries LDIF element Description dn: distinguished_name Required. Specifies the distinguished name for the entry. objectClass: top Required. Specifies the top object class. objectClass: domain Specifies the domain object class. This line defines the entry as a domain or domain component. dc: domain_component Attribute that specifies the domain's name.
Specifying organizational person entries The majority of the entries in the directory represent organizational people.
To create a directory using LDIF: 1. Create an ASCII file containing the entries to add in LDIF format. Make sure each entry is separated from the next by an empty line. Use just one line between entries, and make sure the first line of the file is not be blank, or else the ldapmodify utility will exit. For more information, see “Specifying directory entries Using LDIF” (page 550). 2. Begin each file with the topmost, or root, entry in the database.
dn: ou=People,dc=example,dc=com objectclass: top objectclass: organizationalUnit ou: People description: Fictional example organizational unit tel: 555-5559 dn: cn=June Rossi,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: June Rossi sn: Rossi givenName: June mail: rossi@example.
information in multiple languages so that users in different locales can view directory information in their own language. When information in the directory is represented in multiple languages, the server associates language tags with attribute values. When a new entry is added, the attribute values used in the RDN (relative distinguished name, the naming attribute) must be provided without any language codes. Multiple languages can be stored for a single attribute.
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 “Managing Access Control” (page 233).
Figure 22 Searching for entries CAUTION: Do not modify the contents of the o=NetscapeRoot suffix using the Directory tab unless instructed to do so by HP technical support. TIP: For information on using the search form, click Help. Using ldapsearch The ldapsearch command line utility can locate and retrieve directory entries. This tool is located at the /opt/dirsrv/bin directory.
interpolation if there are shell variables. Refer to the operating system documentation for more information. ldapsearch command-line format The ldapsearch command must use the following format: ldapsearch [optional_options] [optional_search_filter] [optional_list_of_attributes] • optional_options is a series of command line options. These must be specified before the search filter, if any are used. • optional_search_filter is an LDAP search filter as described in “LDAP search filters” (page 561).
Option Description -s Specifies the scope of the search. The scope can be one of the following: base searches only the entry specified in the -b option or defined by the LDAP_BASEDN environment variable. one searches only the immediate children of the entry specified in the -b option. Only the children are searched; the actual entry specified in the -b option is not searched.
Searching the root DSE entry The root DSE is a special entry that contains a list of all the suffixes supported by the local Directory Server. This entry can be searched by supplying a search base of "", a search scope of base, and a filter of "objectclass=*". For example: ldapsearch -h mozilla -b "" -s base "objectclass=*" Searching the schema entry Directory Server stores all directory server schema in the special cn=schema entry.
The set of attributes returned here can be limited by specifying the attribute names at the end of 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 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 (\).
• buildingName for the name of the building in which the person resides. • l for the physical location of the person. For a listing of the attributes associated with types of entries, see the HP-UX Directory Server schema reference. Using operators in search filters The operators that can be used in search filters are listed in Table 81 (page 562). In addition to these search filters, special filters can be specified to work with a preferred language collation order.
Boolean expressions are evaluated in the following order: • Innermost to outermost parenthetical expressions first. • All expressions from left to right. Search filter examples The following filter searches for entries containing one or more values for the manager attribute. This is also known as a presence search: manager=* The following filter searches for entries containing the common name Ray Kultgen.
to update the cache with any new, modified, or deleted entries that were changed while it was disconnected. • An attacker could open a large number of persistent searches to launch a denial of service attack. • A persistent search requires leaving open a TCP connection between the Directory Server and client. This should only be done if the server is configured to allow a lot of client connections and has a way to close idle connections.
The search, if the changesOnly setting is false (0), will return every matching entry in the directory, as with a normal ldapsearch. Then, as entries are modified, the persistent search returns the newly updated entry with, optionally, the type of operation which updated it (changeType). version: 1 dn: uid=scarter,ou=People, dc=example, dc=com persistentSearch-changetype: modify title: manager mail: scarter@example.
Matching rule formats The matching rule portion of a search filter can be represented in any several ways, and which one should be used is a matter of preference: • 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.
Using a language tag and suffix for the matching rule As an alternative to using a relational operator-value pair, append a suffix that represents a specific operator to the language tag in the matching rule portion of the filter. Combine the language tag and suffix as follows: attr: language-tag+suffix:=value For example, to search for all surnames that come at or after La Salle in the French collation order, use the following filter: sn:fr.
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. Less-than example Performing a locale-specific search using the less-than operator (<), or suffix (.1) searches for all attribute values that come before the given attribute in a specific collation order.
... locality:fr.4:=Québec Greater-than example Performing a locale-specific search using the greater-than operator (>), or suffix (.5) searches for all attribute values that come at or before the given attribute in a specific collation order. For example, to search for all mail hosts that come after host schranka4 in the Czechoslovakian collation order, any of the following matching rule filters would work: mailHost:2.16.840.1.113730.3.3.2.5.1:=> schranka4 ... mailHost:cs:=> schranka4 ... mailHost:2.16.
Example 28 Usage example: ldapsearch -D "cn=Directory Manager" -w secret \ -b " cn=Account,ou=Groups,dc=example,dc=com" \ -E 'deref=member:telephonenumber, cn' "(objectclass=*)" The above command fetches the telephonenumber and cn for every member of the group cn=Account in a single search operation. This feature is supported only with the OpenLDAP client.
C LDAP URLs LDAP URLs identify the HP-UX Directory Server instance, similarly to the way site URLs identify a specific web site 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 identify the specific Directory Server instance when the Directory Server is accessed using a web-based client such as Administration Express. • LDAP URLs are used to configure Directory Server referrals.
Table 84 LDAP URL components (continued) Component Description If no scope is specified, the server performs a base search. filter Search filter to apply to entries within the specified scope of the search. If no filter is specified, the server uses the filter (objectClass=*). The attributes, scope, and filter components are identified by their positions in the URL. Even if no attributes are specified, the question marks still must be included to delimit that field.
• Because no search scope is specified, the search is restricted to the base entry dc=example,dc=com. • Because no filter is specified, the directory uses the default filter (objectclass=*). Example 2 The following LDAP URL retrieves the postalAddress attribute of the entry with the DN dc=example,dc=com: ldap://ldap.example.com/dc=example,dc=com?postalAddress • Because no search scope is specified, the search is restricted to the base entry dc=example,dc=com.
D Internationalization HP-UX 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 character sets by default because directory data is stored in UTF-8.
Because a locale describes cultural, customary, and regional differences in addition to mechanical language differences, the directory data can both be translated into the specific languages understood by users as well as be presented in a way that users in a given region expect. Identifying supported locales When performing directory operations that require that a locale be specified, such as a search operation, use a language tag or a collation order object identifier (OID).
Table 85 Supported locales (continued) Locale Language tag Collation order object identifiers (OIDs) Korean ko 2.16.840.1.113730.3.3.2.29.1 Latvian, Lettish lv 2.16.840.1.113730.3.3.2.31.1 Lithuanian lt 2.16.840.1.113730.3.3.2.30.1 Macedonian mk 2.16.840.1.113730.3.3.2.32.1 Norwegian no 2.16.840.1.113730.3.3.2.35.1 Polish pl 2.16.840.1.113730.3.3.2.38.1 Romanian ro 2.16.840.1.113730.3.3.2.39.1 Russian ru 2.16.840.1.113730.3.3.2.40.1 Serbian (Cyrillic) sr 2.16.840.1.113730.3.3.2.
Table 86 Supported language subtypes (continued) Language tag Language Language tag Language fr French sr Serbian ga Irish sv Swedish gl Galician tr Turkish hr Croatian uk Ukrainian hu Hungarian zh Chinese id Indonesian 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.
Glossary A access control instruction See ACI. access control list See This used to be othertermed ACL (phil-after-Dean)ACL. access rights In the context of access control, specify the level of access granted or denied. Access rights are related to the type of operation that can be performed on the directory. The following rights can be granted or denied: read, write, add, delete, search, compare, selfwrite, proxy, and all.
branch entry An entry that represents the top of a subtree in the directory. browser Software, such as Mozilla Firefox, used to request and view World Wide Web material stored as HTML files. The browser uses the HTTP protocol to communicate with the host server. browsing index 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 .
D daemon A background process on a UNIX machine that is responsible for a particular system task. Daemon processes do not need human intervention to continue functioning. DAP Directory Access Protocol. The ISO X.500 standard protocol that provides client access to the directory. 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.
filtered role Allows you to assign entries to the role depending upon the attribute contained by each entry. You do this by specifying an LDAP filter. Entries that match the filter are said to possess the role. G 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.
LDAP URL Provides the means of locating Directory Servers using DNS then completing the query via LDAP. A sample LDAP URL is ldap://ldap.example.com. LDAPv3 Version 3 of the LDAP protocol, upon which Directory Server bases its schema format. LDBM database A high-performance, disk-based database consisting of a set of large files that contain all the data assigned to it. The primary data store in Directory Server. LDIF LDAP Data Interchange Format.
network management application Network Management Station component that graphically displays information about SNMP managed devices, such as which device is up or down and which and how many error messages were received. network management station See NMS. NIS Network Information Service. A system of programs and data files that UNIX machines use to collect, collate, and share specific information about machines, users, file systems, and network parameters throughout a network of computers.
PTA directory server In pass-through authentication (PTA), the PTA Directory Server is the server that sends (passes through) bind requests it receives to the authenticating directory server. PTA LDAP URL In pass-through authentication, the URL that defines the authenticating directory server, pass-through subtree(s), and optional parameters. R RAM Random access memory. The physical semiconductor-based memory in a computer. Information stored in RAM is lost when the computer is shut down.
Secure Sockets Layer See SSL. self access When granted, indicates that users have access to their own entries if the bind DN matches the targeted entry. Server Console Java-based application that allows you to perform administrative management of your Directory Server from a GUI. server daemon The server daemon is a process that, after it runs, listens for and accepts requests from clients. Server Selector Interface that allows you select and configure servers using a browser.
system index Cannot be deleted or modified as it is essential to Directory Server operations. 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.
Index A access control ACI attribute, 233 ACI syntax, 236 allowing or denying access, 241 and replication, 290 and schema checking, 238 anonymous access, 245 bind rules, 243 access at specific time or day, 253 access based on value matching, 248 general access, 245 user and group access, 244 Boolean bind rules, 255 compatibility with earlier versions, 290 creating from console, 255 dynamic targets, 245 from specific domain, 252 from specific IP address, 252 logging information, 273 overview, 233 permissions
viewing current, 263 wildcard in target, 238 wildcards, 246 ACI attribute default index for, 452 overview, 233 ACI placement, 234 ACI targets, 237 ACL, 233 activating accounts from command line, 303 from console, 303 Active Directory schema differences between Directory Server, 407, 413 add right, 241 adding directory entries, 114 Administration Server starting and stopping, 21 algorithm metaphone phonetic algorithm, 453 search, 452 All IDs Threshold, 467 all keyword, 245 allowing access, 241 anonymous acce
B backing up data, 160 all, 161 cn=tasks, 162 db2bak, 162 dse.ldif, 162 bak2db script, 164 bak2db.
overview, 486 selecting, 486 cl-dump.
backup files, 161 backup from console, 161 creating from command line, 42 creating from console, 41 creating multiple, 42 creating using LDIF, 552 deleting, 46 export, 155 cn=tasks, 160 db2ldif, 159 db2ldif.pl, 159 encrypted database, 52 export from console, 156 import, 148 cn=tasks, 154 encrypted database, 52 ldif2db, 152 ldif2db.
data, 148 databases, 31 deleting entries, 111 file locations, 19 importing data, 148 international character sets, 574 login, 22 managing entries, 97 MIB, 535 modifying entries, 102 monitoring, 509 monitoring from command line, 524 monitoring with SNMP, 532 overview, 19 performance counters, 520 64-bit, 520, 525, 536 64-bit integers, 530 reloading schema, 444 cn=schema reload task, 445 schema-reload.
extending the directory schema, 428 F failover servers for database links, 60 feedback email address for documentation, 544 File locations, 19 files access log, 511 database backup, 161 EOF marker, 112 errors log, 512 id2entry.db4, 452 Filesystem Hierarchy Standard, 19 filesystem replica initialization, 375 filtered role creating, 172 example, 187 finding attributes, 561 entries, 557 fixup-memberof.
greater than or equal to, 568 less than, 568 less than or equal to, 568 matching rule filter syntax, 565 substring, 569 using OIDs, 566 internationalization character type, 574 collation order, 574 country code, 575 date format, 574 language tag, 575 locales and, 574 location of files, 575 matching rule filters, 565 modifying entries, 127 monetary format, 574 object identifiers and, 575 of LDIF files, 554 search filters and, 565 supported locales, 575 time format, 574 ip keyword, 252 J jpeg images, 549 K
organizational units, 551 organizations, 550 internationalization and, 554 LDIF files continued lines, 549 creating directory using, 552 creating multiple entries, 113 example, 553 importing from Server Console, 113 internationalization and, 554 LDIF format, 548 LDIF update statements, 121 adding attributes, 124 adding entries, 122 continued lines, 122 deleting attribute values, 126 deleting attributes, 126 deleting entries, 127 modifying attribute values, 125 modifying entries, 124 syntax, 121 ldif utility
N naming conflicts in replication, 386 nested role creating, 175 example, 187 nsds5ReplicaBusyWaitTime, 348 nsds5ReplicaSessionPauseTime, 348 nsRole, 168 nsslapd-db-checkpoint-interval, 542 nsslapd-db-durable-transactions, 542 nsslapd-db-logdirectory, 542 nsslapd-idlistscanlimit, 453 nsslapd-lookthroughlimit attribute role in searching algorithm, 453 nsslapd-maxbersize, 108 nsslapd-schemacheck attribute, 447 nsslapd-sizelimit attribute role in searching algorithm, 453 nsslapd-timelimit attribute role in sea
PDUs, 532 performance counters, 525 64-bit database attributes, 530 server attributes, 530 configuring 64-bit, 520, 525, 536 configuring 64-bit integers, 530 monitoring the server with, 520 Named Pipe Log Script, 514 performance tuning database, 540 server, 539 permissions ACI syntax, 236 allowing or denying access, 241 assigning rights, 241 overview, 241 precedence rule, 234 plug-ins disabling, 29 distributed number assignment, 133 configuring, 137, 138 overview, 133 syntax, 135, 136 enabling, 29 pointer C
replication manager entry, 319 single-master, 327 solving conflicts, 386 supplier bind DN, 320 supplier server, 319 supplier-initiated, 319 troubleshooting, 389 unit of, 319 using cl-dump.pl script, 389 using repl-monitor.
turning on or off, 446 turning on or off in the command line, 447 schema-reload.pl, 444 scripts cl-dump.pl, 389 repl-monitor.
international example, 569 subtree level password policy, 291 subtypes of attributes, 109 suffix and associated database, 31 configuration attributes, 37 creating, 97 creating from command line, 36 creating root suffix, 33 creating sub suffix, 34 custom distribution function, 43 custom distribution logic, 43 disabling, 38 in Directory Server, 31 using referrals, 94 on update only, 94 with multiple databases, 42 suffix referrals creating, 94 creating from command line, 95 creating from console, 94 supplier b
configuring, 394 deleting entries, 417 groups, 412 logging levels, 426 manually updating, 418 Password Sync service, 398, 426 modifying, 426 setting up SSL, 400 starting and stopping, 426 uninstalling, 426 resurrecting deleted entries, 417 schema differences, 407, 413 troubleshooting, 426 users, 405 write performance, 467 write right, 241 601
