Skip Headers
Oracle Internet Directory Administrator's Guide
10g (10.1.4.0.1)

Part Number B15991-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

7 Oracle Directory Server Administration

This chapter explains how to manage an Oracle directory server by using Oracle Directory Manager and command-line tools.

This chapter contains these topics:

7.1 Managing Server Configuration Set Entries

When you start an Oracle directory server by using the object class, that start message refers to a configuration set entry containing server parameters. You can add, modify, and delete configuration set entries by using either Oracle Directory Manager or the appropriate command-line tool.

This section contains these topics:

7.1.1 Preliminary Considerations for Managing Configuration Set Entries

The configuration set entry configset0 is the default, and is used as the template for all new configuration set entries. Although you can change values in the default configuration set, all of your changes are then carried over to every new configuration set entry that you create.

To change values that should not be in effect for every server instance, it is better to create new configuration set entries. Note that this applies to the Oracle directory server and Oracle directory integration server instances only. The Oracle replication directory server supports only one configuration set.

You may want to establish a separate instance of a directory server with different values. If you do not want those values to be exercised by all users, then set up a new configuration set entry and run a separate server instance pointing to that configuration set entry for groups with special needs.

Figure 7-1 shows three separate directory server instances, each with a different value.

Figure 7-1 Directory Entry Hierarchy Showing Multiple Configuration Set Entries

This illustration is described in the text.

Figure 7-1 shows:

  • An Oracle directory server (cn=odsldap) with:

    • One instance listening on the default port and using configset0 with SSL disabled

    • A second instance listening on the SSL port and using configset1 with SSL enabled

  • A replication server instance (cn=odsrepld) using configset0


    Note:

    You can run multiple instances if the directory server is on the same computer. For example, you can run one instance in SSL mode and another in non-SSL mode.


    See Also:


7.1.2 Managing Server Configuration Set Entries by Using Oracle Directory Manager

You can use Oracle Directory Manager to view, add, modify, and delete configuration set entries.


Note:

You cannot change the parameters for an active instance directly. Instead, you must change the parameters in a configuration set entry and save it. After the configuration set entry is saved, use the OID Control Utility restart command to stop current Oracle directory server instances and restart them.

You can change a configuration set entry and start fresh instances that use the new parameters. The changes do not affect the older instances that are still running, however, unless they are restarted.

For information on restarting directory server instances, see "Oracle Internet Directory Server Administration Tools" in Oracle Identity Management User Reference.


This section contains the following topics:

7.1.2.1 Viewing Configuration Set Entries by Using Oracle Directory Manager

To view configuration set entries:

  1. In the navigator pane, expand Oracle Internet Directory Servers, then directory server instance, then Server Management.

  2. Select Directory Server, Replication Server, or Integration Server. The parameters of the active instance appear in the right pane.

  3. In the right pane, select an instance, then choose View Properties. A Server Process dialog box appears.

    You can see all the parameters for the instance by selecting the tabs across the top of the dialog box. However, you cannot change these parameters in this dialog box. To change them, you must change the configuration set entry on which they are based.

7.1.2.2 Adding Configuration Set Entries by Using Oracle Directory Manager

The first time you add a configuration set entry, you can:

  • Use the default configuration set as a template for the new configuration set entry, then copy from it to make subsequent configuration sets.

  • Add a configuration set entry without copying from an existing one.

7.1.2.2.1 Adding a Configuration Set Entry by Copying from the Default Configuration Set Entry

To add configuration set entries by copying the default configuration set entry:

  1. In the navigator pane, expand Oracle Internet Directory Servers, then directory server instance, then Server Management, then Directory Server.

  2. Select Default Configuration Set.

  3. On the toolbar, choose Create Like. The Configuration Sets dialog box displays the General tab page.

  4. In the General tab page, fill in the fields. These are described in Table A-40.

  5. Select the SSL Settings tab and fill in the fields. These are described in Table A-41.

  6. Choose Apply.

  7. Restart the server instance for the command to take effect.


    See Also:


7.1.2.2.2 Adding a Configuration Set Entry Without Copying from an Existing One

To create a new configuration set entry without copying from a previous configuration set entry:

  1. In the navigator pane, expand Oracle Internet Directory Servers, then directory server instance, then Server Management, then Directory Server.

  2. Select Default Configuration Set.

  3. On the toolbar, choose Create. A Configuration Sets dialog box displays the General tab page.

  4. In the General tab page, fill in the fields. These are described in Table A-40.

  5. Select the SSL Settings tab and fill in the fields. These are described in Table A-41 .

  6. Choose OK.

7.1.2.3 Modifying Configuration Set Entries by Using Oracle Directory Manager

To modify configuration set entries:

  1. In the navigator pane, expand each of the following objects in succession: Oracle Internet Directory Servers, directory server instance, Server Management, Directory Server.

  2. Select the configuration set entry you want to modify. The configuration set appears in the group of tab pages in the right pane.

  3. In the General tab page, modify the fields. These are described in Table A-40. To save the changes, choose Apply.

  4. Select the SSL Settings tab and modify the fields. These are described in Table A-41. To save the changes, choose Apply.

  5. Restart the server instance for the command to take effect.


    See Also:

    • The oidctl command-line tool reference in Oracle Identity Management User Reference

    • Oracle Advanced Security Administrator's Guide for instructions on using the Oracle Wallet Manager to set the location of the Oracle Wallet and the Oracle Wallet password.


7.1.2.4 Deleting Configuration Set Entries by Using Oracle Directory Manager

To delete configuration set entries:

  1. In the navigator pane, expand each of the following objects in succession: Server Management, Directory Server.

  2. Select the configuration set entry you want to delete.

  3. On the toolbar, choose Delete.

  4. Restart the server instance for the command to take effect.


    See Also:

    The oidctl command-line tool reference in Oracle Identity Management User Reference

7.1.3 Managing Server Configuration Set Entries by Using Command-Line Tools

Although changing configuration set entries by using Oracle Directory Manager is desirable, it can sometimes be more convenient to use the available command-line tools—for example, when you want to make the same set of changes across multiple Oracle directory servers.

When you add or modify configuration set entries by using the command-line tools, the input file for adding a new configuration set entry must be written in LDIF. It must contain only the attributes and values that differ from the installed defaults. The directory server uses the attribute values that you establish in the new configuration set entry to override its own existing values for these attributes.


See Also:

"LDIF File Formatting Rules and Examples" in Oracle Identity Management User Reference for information on LDIF

This section contains the following topics:

7.1.3.1 Adding Configuration Set Entries by Using ldapadd

If you are adding a new Oracle directory server instance, then you can either use an existing configuration set entry, or add a new one for the new instance.

To add a new configuration set entry, create an input file, and then load the input file with ldapadd. Follow these steps:

  1. Create the input file in a text editor.

    Input files must use LDIF format. When you create the input file, you need to define or include only those attributes that differ from the current values in that configuration set entry.

    In this example, the parameter configset2 is the RDN, or local name, of the new entry and the wallet location is: /HOME/test/wallet.

    dn:cn=configset2, cn=osdldapd, cn=subconfigsubentry cn:configset2
    objectclass:orclConfigSet
    objectclass:orclLDAPSubConfig
    objectclass:top
    orclsslauthentication:1
    orclsslenable:1
    orclsslport:5000
    orclsslversion:3 orclsslwalleturl:file:/HOME/test/wallet
    
    
  2. Run ldapadd with an input file.

    At the system prompt, type the command to add the input file.

    ldapadd [options] -f LDIF_file_name 
    

    See Also:


7.1.3.2 Modifying and Deleting Configuration Set Entries by Using ldapmodify

To modify or delete an existing configuration set entry, create an input file containing only the attributes that you want to change, and then load the input file with the ldapmodify command. Follow these steps:

  1. Create the input file.

    When you create the input file, define or include only those attributes that differ from the installed defaults.

    Input files must have LDIF format.

    In the next example, the parameter cn=configset2,cn=osdldapd,cn=subconfigsubentry is the DN, or local name, of an existing configuration set entry. This example shows how to modify the ORCLSSLPORT parameter to 7000.

    dn:cn=configset2,cn=osdldapd,cn=subconfigsubentry changetype: modify replace: orclsslport orclsslport: 7000
    

  1. Run ldapmodify referencing the input file.

    Type the command to reference the input file at the system prompt.

    ldapmodify [options] -f LDIF_file_name
    

    See Also:


7.2 Setting System Operational Attributes

An operational attribute—as opposed to an application attribute—pertains to the operation of the directory itself. Some operational information is specified by the directory to control the server—for example, the time stamp for an entry. Other operational information, such as access information, is defined by administrators and is used by the directory program in its processing. You must have super user privileges to set system operational attributes.

This section contains these topics:

7.2.1 Setting System Operational Attributes by Using Oracle Directory Manager

You can view and set some of the operational attributes for each Oracle directory server to which you are connected by using Oracle Directory Manager. To do this, in the navigator pane, expand Oracle Internet Directory Servers, then select a directory server. System operational attributes appear in the right pane.

Table A-42 describes the fields displayed in Oracle Directory Manager for system operational attributes.

7.2.2 Setting System Operational Attributes by Using ldapmodify

To modify system operational attributes, use ldapmodify. The "Oracle Identity Management LDAP Attribute Reference" in Oracle Identity Management User Reference describes the modifiable system operational attributes.


See Also:

The ldapmodify command-line tool reference in Oracle Identity Management User Reference for a more detailed discussion of ldapmodify, and a list of its options

7.3 Managing Naming Contexts

To enable users to search for specific naming contexts, you can publish those naming contexts. This section contains these topics:

To publish a naming context, you specify the topmost entry of each naming context as a value of the namingContexts attribute in the root DSE. For example, suppose you have a DIT with three major naming contexts, the topmost entries of which are c=uk, c=us, and c=de. If these entries are specified as values in the namingContexts attribute, then a user, by specifying the appropriate filter, can find information about them by searching the root DSE. The user can then focus the search—for example, by concentrating on the c=de naming context in particular.

You can use either Oracle Directory Manager or ldapmodify to publish a naming context. The namingContexts attribute is multi-valued, so you can specify multiple naming contexts.

To search for published naming contexts, perform a base search on the root DSE with objectClass =* specified as a search filter. The retrieved information includes those entries specified in the namingContexts attribute.

Before you publish a naming context, be sure that:

7.3.1 Publishing Naming Contexts by Using Oracle Directory Manager

  1. In the navigator pane, expand Oracle Internet Directory Servers and select the directory server on which you want to specify a naming context. The corresponding tab pages for that directory server appear in the right pane.

  2. In the System Operational Attributes tab page, in the Naming Contexts field, enter the topmost DN of the naming context you want to publish. You can also choose Browse to open a search window.

  3. Choose Apply.

7.3.2 Publishing Naming Contexts by Using ldapmodify

The following sample LDIF file specifies the entry c=uk as a naming context.

dn:
changetype: modify
add: namingcontexts
namingcontexts: c=uk

7.4 Managing Super Users, Guest Users, and Proxy Users

This section contains these topics:

7.4.1 About Super Users, Guest, Users, and Proxy Users

Table 7-1 defines super users, guest users, and proxy users.

You can use either Oracle Directory Manager or ldapmodify to administer the user names and passwords for each of these users.

Table 7-1 Definitions of Super User, Guest User, and Proxy User

Type of User Definition

Super user

A special directory administrator with full access to directory information. The default user name of the super user is orcladmin; the default password is welcome.

Note: Oracle recommends that you change the password immediately after installation.

Guest user

One who is not an anonymous user, and, at the same time, does not have a specific user entry. The default user name for a guest user is guest; the default password is guest.

Proxy user

A user typically in an environment with a middle tier such as a firewall, an application such as Oracle Delegated Administration Services, or a RADIUS server. The default user name for a proxy user is proxy; the default password is proxy.

See Also: "Indirect Authentication" for more information about proxy users



See Also:

Chapter 18, "Directory Access Control" for information on how to set access rights


Note:

You can log on to the Oracle Directory Manager without giving a user name or password. If you do this, you have the privileges specified for an anonymous user. Anonymous users should have very limited privileges.

7.4.2 Managing Super Users, Guest Users, and Proxy Users by Using Oracle Directory Manager


Note:

The passwords for super users, guest users, and proxy users are encrypted by default. You cannot modify them to send them in the clear.

To set a user name or password for a super user, a guest user, or a proxy user by using Oracle Directory Manager:

  1. In the navigator pane, expand Oracle Internet Directory Servers, then select a directory server. The group of tab pages for that server appear in the right pane.

  2. Select the System Passwords tab. This page displays the current user names and passwords for each type of user. Note that passwords are not displayed in the password fields.

  3. Edit the appropriate field in the System Passwords tab page as described in Table A-43. To save your changes, choose Apply.

7.4.3 Managing Super Users, Guest Users, and Proxy Users by Using ldapmodify

To set or modify a user name or password for a super user, a guest user, or a proxy user, use ldapmodify to modify the appropriate attribute.

Table 7-2 Names, Passwords, and Attributes for Super, Guest, and Proxy Users

User Name Password Attribute

Super user name

orclsupassword

orclsuname

Guest user name

orclgupassword

orclguname

Proxy user name

orclprpassword

orclprname


For example, to change the password of the super user to superuserpassword, use ldapmodify to modify the DSE by using an LDIF file containing the following:

dn: 
changetype:modify
replace:orclsupassword
orclsupassword:superuserpassword

See Also:

The ldapmodify command-line tool reference in Oracle Identity Management User Reference for ldapmodify syntax and usage notes.

7.5 Managing Anonymous Binds

The Oracle Directory Server can be configured to allow or disallow anonymous bind. This behavior is controlled by the orclAnonymousBindsFlag attribute of the root DSE entry. Table 7-3 lists the allowed values for orclAnonymousBindsFlag and the resulting directory server behavior.

Table 7-3 Orclanonymousbindflag Value and Directory Server Behavior

orclAnonymousBindsFlag Value Directory Server Behavior

0

Disallows anonymous bind

1

Allows anonymous bind (default)

2

Allows anonymous bind but allows only search operations on root DSE entry for anonymous users


By default, the directory server allows anonymous bind. That is, the orclAnonymousBindsFlag attribute is set to 1.

The following example shows how to disable anonymous bind using the ldapmodify command-line tool:

ldapmodify -h hostname -p port -D cn=orcladmin -w super_user_pwd <<EOF 
dn:
changetype: modify
replace: orclanonymousbindsflag
orclanonymousbindsflag: 0
EOF

7.6 Viewing Active Server Instance Information

To view information about any active directory server instance—including type, instance number, debug level, host name, and configuration parameters—use Oracle Directory Manager. To do this:

  1. In the navigator pane, expand Oracle Internet Directory Servers and select a directory server. The group of tab pages for that directory server instance appear in the right pane.

  2. Select the Server Management tab. This displays basic information—namely, type, instance number, debug level, and host name—for all active directory server instances.

  3. To see configuration parameters for a particular directory server instance, select the directory server instance, then choose View Properties. The Server Process dialog box displays configuration parameters for the directory server instance you selected. Note that you cannot change configuration parameters in this dialog box. To change them, you must change the configuration set entry on which they are based.


    See Also:

    "Managing Server Configuration Set Entries by Using Oracle Directory Manager" for instructions on changing configuration set entries

7.7 Closing Idle LDAP Connections

You can specify the number of minutes that LDAP connections remain idle before closing. To do this, you set a value for the orclLDAPconnTimeout attribute described in "Oracle Identity Management LDAP Attribute Reference" in Oracle Identity Management User Reference.

As of 10g (10.1.4.0.1), you can only set this for users who are not configured for operation statistics tracking as described in "Capabilities of Oracle Internet Directory Server Manageability".


Note:

The Oracle Internet Directory server processes idle connection timeout at an interval equal to the configured connection timeout value. This minimizes performance overhead. As a result, sometimes dropping of a connection may take longer than the pre configured connection timeout value. It is guaranteed to take no more time than twice this value.

7.8 Changing the Password to the Oracle Internet Directory Database Server

The Oracle Internet Directory uses a password when connecting to its own designated Oracle database. The default for this password when you install Oracle Internet Directory is the same as that for the Oracle Application Server administrator. You can change this password by using the OID Database Password Utility.


See Also:

The oidpasswd command-line tool reference in Oracle Identity Management User Reference

7.9 Dereferencing Alias Entries

Because entries sometimes have distinguished names that are fairly long and cumbersome, Oracle Internet Directory makes it easier to administer them by using alias objects. When someone looks up—that is, references—an object by using an alias, the alias is dereferenced, and what is returned is the object to which the alias points. For example, the alias, Server1, can be dereferenced so that it points to the fully qualified DN—namely, dc=server1,dc=us,dc=myCompnay,dc=com. This feature also enables you to devise structures that are not strictly hierarchical.

This section provides examples of how to add, search for, and modify alias entries, and it includes a list of messages. It contains these topics:

7.9.1 About Alias Entries

An alias entry uses the object class alias to distinguish it from object entries in a directory. The definition of that object class is as follows:

(2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName)

An alias entry also contains the aliasedObjectName attribute that, in turn, contains the DN of the object to which it is pointing. The definition of that attribute is as follows:

(2.4.5.1 NAME 'aliasedObjectName" EQUALITY distinguishedNmameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE)

Figure 7-2 and the accompanying text provides an example of alias entry dereferencing.

Figure 7-2 Alias Entries Example

This illustration is described in the text.

In Figure 7-2, ou=uk sales,ou=global sales,o=myCompany,c=us is an alias entry pointing to the ou=sales,o=myCompany,c=uk entry.

When anyone references ou=uk sales,ou=global sales,o=oracle,c=us, the directory server automatically reroutes them to the real entry, ou=sales,o=oracle,c=uk.

7.9.2 Examples: Using Alias Entry Dereferencing

This section contains these examples:

7.9.2.1 Example: Adding an Alias Entry

To add an alias entry, you create a normal entry in LDIF and an alias entry pointing to the real entry. Following the steps in this example produces the tree in Figure 7-3.

  1. Create a sample LDIF file, My_file.ldif, with the following entries:

    dn: c=us
    c: us
    objectclass: country
    
    dn: o=MyCompany, c=us
    o: MyCompany
    objectclass:organization
    
    dn: ou=Area1, c=us
    objectclass: alias
    aliasedObjectName: o=MyCompany, c=us
    
    dn: cn=John Doe, o=MyCompany, c=us
    cn: John Doe
    sn: Doe
    objectclass: person
    
    dn: cn=President, o=MyCompany, c=us
    objectclass: alias
    aliasedobjectname: cn=John Doe, o=MyCompany, c=us
    
    
  2. Add these entries to the directory by using the following command:

    ldapadd -p port -h host -f My_file.ldif
    
    

    Note:

    When you add an alias entry whose parent is an alias entry, the directory server returns an error.


    See Also:

    Entry Alias Dereferencing Messages for error messages

Figure 7-3 Resulting Tree when Creating the My_file.ldif

Description of Figure 7-3 follows
Description of "Figure 7-3 Resulting Tree when Creating the My_file.ldif"

In Figure 7-3, the letter A represents an alias entry, where:

  • ou=Area1 is an alias pointing to o=MyCompany

  • cn=President is an alias pointing to cn=John Doe

7.9.2.2 Examples: Searching the Directory with Alias Entries

In each search you specify, there are flags you can set. The search is performed based on the flag you specify.

The flags pertaining to alias dereferencing are -a never and -a find.

By default, the dereference flag in ldapsearch is -a never and thus the directory server does not perform any dereferencing for alias entries.


Note:

As of 10g (10.1.4.0.1), Oracle Internet Directory does not support the following options:
  • The ldapsearch options -a search and -a always.

  • The extensibleMatch feature described in RFC 2251.


7.9.2.2.1 Example: Searching the Base

A base search finds the top level of the alias entry you specify.

This example shows a base search of ou=Area1,c=us with a filter of "objectclass=*" with the dereferencing flag set to -a find.

ldapsearch -p port -h host -b "ou=Area1,c=us" -a find -s base "objectclass=*" 

The directory server, during the base search, looks up the base specified in the search request and returns it to the user. However, if the base is an alias entry and, as in the example, -a find is specified in the search request, then the directory server automatically dereferences the alias entry and returns the entry it points to. In this example, the search dereferences ou=Area1,c=us, which is an alias entry, and returns o=MyCompany,c=us.

7.9.2.2.2 Example: Searching One-Level

A one-level search finds only the child to the base level you specify.

This example shows a one-level search of "ou=Area1,c=us" with a filter of "objectclass=*" with the dereferencing flag set to -a find.

ldapsearch -p port -h host -b "ou=Area1,c=us" -a find -s one "objectclass=*"

The directory server performs the search in two steps.

  1. It searches for the base that is specified in the search request.

  2. When it locates the base, it looks up all one-level entries under this base and returns entries that match the filter criteria.

In the example, -a find is specified in the search request, and thus the directory server automatically dereferences while looking up the base (the first step), but does not dereference alias entries that are one level under the base. Therefore, the search dereferences ou=Area1,c=us, which is an alias entry, and then looks up one-level entries under o=MyCompany,c=us. One of the one-level entries is cn=President,o=MyCompany,c=us that is not dereferenced and is returned as is.

Thus, the search returns cn=President,o=MyCompany,c=us and cn=John Doe,o=MyCompany,c=us.

7.9.2.2.3 Example: Searching a Subtree

A subtree search finds the base, children, and grand children.

This example shows a subtree search of "ou=Area1,c=us" with a filter of "objectclass=*" with the dereferencing flag set to -a find.

ldapsearch -p port -h host -b "ou=Area1,c=us" -a find -s one "objectclass=*" 

The directory server performs the search in two steps.

  1. It searches for the base that is specified in the search request.

  2. When it locates the base, then it looks up all entries under this base and returns entries that match the filter criteria.

In the example, -a find is specified in the search request, and thus the directory server automatically dereferences while looking up the base (the first step), but does not dereference alias entries that are under the base. Therefore, the search dereferences ou=Area1,c=us, which is an alias entry, and then looks up entries under o=MyCompany,c=us. One of the entries is cn=President,o=MyCompany,c=us that is not dereferenced and is returned as is.

Thus, the search returns:

  • o=MyCompany,c=us

  • cn=john doe,o=MyCompany,c=us

  • cn=President,o=MyCompany,c=us

7.9.2.3 Example: Modifying Alias Entries

This example shows how to modify alias entries. It creates a sample LDIF file, My_file.ldif with following entries:

dn: cn=President, o=MyCompany, c=us
changetype : modify
replace: aliasedobjectname
aliasedobjectname: cn=XYZ, o=MyCompany, c=us

Modify the alias entry using the following command:

ldapmodify -p port -h host -f My_file.ldif

7.9.3 Success and Error Messages

Table 7-4 lists the messages related to alias entry dereferencing and the corresponding meaning for each message.

Table 7-4 Entry Alias Dereferencing Messages

Message Meaning

Alias Problem

Either of the following have occurred:

  • An alias was dereferenced, but it did not point to an entry in the DIT.

  • The user tries to add an alias entry whose parent is an alias.

Alias Dereferencing Problem

The user cannot dereference an alias because of access control issues.

No Such Object

The server cannot find the base DN specified in the search request.

Invalid DN Syntax

When adding or modifying an alias entry, if the value specified for aliasedObjectName has invalid DN syntax, then the directory server returns this error message to the client.

Success

The client operation successfully completes.

When the dereferenced target does exist but does not match the filter specified in the search request, the server returns a success message with no matched entry.

Insufficient Access Rights

The user does not have access to the dereferenced entry.


7.10 Locating Directory Servers in a Distributed Environment

To perform an operation on a particular entry, a client must be able to find the server in which that entry resides. In a distributed environment, information about the location of a server can be available in one of two ways:

This section discusses these two methods of locating server information. It contains these topics:

7.10.1 Static Directory Server Discovery by Using the Directory Server Usage File (ldap.ora)

Using this method, when a client seeks to perform an operation on a directory entry, it obtains directory server location information from the directory server usage file (ldap.ora) stored on the client host. This file contains configuration parameters that specify:

  • The type of directory server—for example, Oracle Internet Directory, Microsoft Active Directory, SunONE Directory Server, and so forth

  • The location of the directory server

  • The default directory entry that the client or server will use to look up or configure connect identifiers for connections to database services

The file ldap.ora resides in the file system of the LDAP client. The client looks for this file in the following file system directories, in order of precedence:

  1. The directory pointed to by the LDAP_ADMIN environment variable

  2. The directory ORACLE_HOME/ldap/admin (or, on Microsoft Windows, ORACLE_HOME\ldap\admin)

  3. The directory pointed to by the TNS_ADMIN environment variable

  4. The directory ORACLE_HOME/network/admin (or, on Microsoft Windows, ORACLE_HOME\network\admin)

If the file ldap.ora is present in more than one location, then the location having higher precedence is honored.

Using the static method to discover a directory server can increase management overhead. For example, because the ldap.ora file is stored on the client host, the administrator must update that file on every client whenever the host name or port number of a directory server is changed. To avoid this increased overhead, you can enable an application to discover directory servers dynamically by using the domain name system (DNS).

7.10.2 Dynamic Directory Server Discovery by Using the Domain Name System (DNS)

The domain name system (DNS) is a dynamic way of locating domain names and translating them into the actual addresses of computers. This translation process is handled by a central domain name server, which contains information about the locations of directory servers.

Once a network administrator has entered the necessary information about directory server locations in a domain name server, clients can retrieve that information from that server instead of from ldap.ora files.

For a client to locate a directory server by using DNS, the following steps must have been completed:

  • The network administrator must have entered a DNS Service Location Record (SRV) into the domain name server.

  • The client application must have been enabled to map distinguished names to domain names.

7.10.2.1 How a Client Locates a Directory Server by Using DNS

To find the directory server on which an entry resides, a client communicates with the domain name server. Specifically, it provides to the domain name server a domain name. The domain name specifies where the needed directory server is located.

To generate the domain name, the client extracts the domain component from the DN entered by the user. For example, in the DN cn=John Doe,ou=accounting,dc=example,dc=net, the domain component is dc=example,dc=net. That domain component represents the server on which the requested entry resides. The client then converts that domain name component to a domain name in a format recognized by the domain name server, namely, example.net.

Figure 7-4 and the accompanying text show the process of locating a directory server from the perspective of a client.

Figure 7-4 A Client Locating a Directory Server by Using DNS

This illustration is described in the text.
  1. A user wanting to perform an operation on a directory entry, enters into the client the distinguished name (DN) of that entry—for example, cn=John Doe,ou=accounting,dc=example,dc=net.

  2. To communicate with the domain name server, the client converts the domain component of the DN to a domain name. In the example used here, the client would convert the domain component of that DN—namely, dc=example,dc=net—to the domain name example.net.

  3. The client queries the domain name server for SRV resource records having the specified domain name.

  4. The domain name server returns the SRV resource records that match the specified domain name. These resource records contain the host name information of the directory server containing the requested entry. If the domain name server is not able to find any matching SRV resource records, then it returns an error message.

  5. The client parses the records. It extracts the directory host name information from these records and returns it to the user.


    See Also:



    Note:

    The domain name server either stores all the necessary SRV records locally, or obtains them from other domain name servers. If the domain name server cannot find the requested information, then it returns an error message. It does not return a referral to another domain name server.

7.10.2.2 Registering a Directory Server with the Domain Name System

Registering server location information for a directory server involves entering a DNS service location record (SRV) into the domain name server. The SRV record contains:

  • The DNS name of the server that provides the LDAP service

  • The corresponding port number

  • Parameters that enable the client to choose an appropriate server from multiple servers

The SRV resource record enables administrators to use several servers for a single domain, to move services from host to host easily, and to designate some hosts as primary servers for a service and others as backups.

The format of the SRV record can be either specific to Oracle Internet Directory servers or standard. For information about Oracle Internet Directory servers, the Oracle Internet Directory-specific format is preferred. When a client first queries a domain name server, it looks for SRV records that have the Oracle Internet Directory-specific format. If it does not find any with this format, then it queries for SRV records that have the standard format.

The Oracle Internet Directory-Specific Format for SRV Records

The Oracle Internet Directory-specific format is:

_Service._Proto._product.Domain TTL Class Type Priority Weight Port Target

Table 7-5 describes the arguments. The following is an example of an SRV record that uses the Oracle Internet Directory-specific format.

_ldap._tcp._oid.acme.com 0 IN SRV 0 1 389 ldap.acme.com

The Standard Format for SRV Records

The standard format is:

_Service._Proto.Domain TTL Class Type Priority Weight Port Target

Table 7-5 describes the arguments. The following is an example of an SRV record for a non-SSL-based directory server that uses the standard format.

_ldap._tcp.acme.com 0 IN SRV 0 1 389 ldap.acme.com

Table 7-5 Arguments in a Service Location Record (SRV)

Argument Description

Service

For a non-SSL-based server, the value for this argument is ldap. For an SSL-based server, the value is ldaps.

Proto

The value is always tcp.

Product

The value is always oid.

Domain

The domain name. It is usually obtained by converting the DN of the naming context mastered by the directory server into a domain name.

See Also: "How a Client Locates a Directory Server by Using DNS"

TTL

Time to live. This argument has the standard DNS meaning. It specifies how long the resource record may be cached before the source of the information is again consulted.

Class

This argument has the standard DNS meaning. SRV records occur in the IN class.

Type

For all SRV records, the value for this argument is SRV.

Priority

The priority of the directory server. A client must attempt to contact the target host with the lowest-numbered priority.

Weight

A server selection mechanism, this argument specifies a relative weight for entries with the same priority. If multiple SRVs have the same priority, then they are ordered according to the following protocol:

  1. To select a target to be contacted next, arrange in any order all SRV resource records that have not yet been ordered—but place all those with weight 0 at the beginning of the list.

  2. Compute the sum of the weights of those resource records, and with each resource record associate the running sum in the selected order.

  3. Choose a uniform random number between 0 and the sum computed (inclusive), and select the resource record whose running sum value is the first in the selected order that is greater than or equal to the random number selected. The target host specified in the selected SRV resource record is the next one to be contacted by the client.

  4. Remove this SRV resource record from the set of the unordered SRV resource records.

  5. Apply the described algorithm to the unordered SRV resource records to select the next target host.

  6. Continue the ordering process until there are no unordered SRV resource records.

  7. Repeat this process for each priority.

Port

The port on target host for the directory service.

Target

The domain name of the host on which the directory server is running.



Note:

If the directory server is moved to a different host or is run on different port, then the corresponding SRV resource record must be updated accordingly.