3 Managing Network Address Information

3.2.1 Understanding the Directory Information Tree

Directory servers store information in a hierarchical namespace structure called a directory information tree (DIT). Each node in the tree is called an entry. Oracle Net Services uses both the tree structure and specific entries in the tree. DITs are commonly aligned with an existing domain structure such as a Domain Name System (DNS) structure or a geographic and organization structure.

Figure 3-2 shows a DIT structured according to DNS domain components.

Figure 3-2 DNS Domain Component DIT

Description of "Figure 3-2 DNS Domain Component DIT"

Figure 3-3 shows a DIT structured according to country, organization, and organizational units. This structure is commonly referred to as an X.500 DIT.

Figure 3-3 X.500 DIT

Description of "Figure 3-3 X.500 DIT"

For example, consider Figure 3-4. The cn=sales and cn=db1 entries represent a net service name and a database service, respectively. Additional entries under cn=sales and cn=db1 contain the connect descriptor information. These entries are not represented in the graphic. The cn=sales and cn=db1 entries enable clients to connect to the database using connect strings CONNECT username@sales and CONNECT username@db1.

Figure 3-4 Database Service and Net Service Entries in a DIT

Description of "Figure 3-4 Database Service and Net Service Entries in a DIT"

Each entry is uniquely identified by a distinguished name (DN). The DN indicates exactly where the entry resides in the directory server hierarchy. The DN for db1 is dn:cn=db1,cn=OracleContext,dc=jp,dc=example,dc=com. The DN for sales is dn:cn=sales,cn=OracleContext,dc=jp,dc=example,dc=com. The format of a DN places the lowest component of the DIT to the left, then moves progressively up the DIT.

Each DN is made up of a sequence of relative distinguished names (RDNs). The RDN consists of an attribute, such as cn, and a value, such as db1 or sales. The RDN for db1 is cn=db1, and the RDN for sales is cn=sales. The attribute and its value uniquely identify the entry.

3.2.1.1 Fully-qualified Names for Domain Component Namespaces

For domain component namespaces, the default directory entry defined for the client must be in one of the following formats:

dc[,dc][...]

ou,dc[,dc][...]

In the preceding syntax, [dc] represents an optional domain component and [...] represents additional domain component entries.

The fully-qualified name used in the connect identifier by the client must be in one of the following formats:

cn.dc[.dc][...]

cn[.ou]@dc[.dc][...]

In the preceding syntax, [cn] represents the Oracle Net entry.

Example 3-1 Using a Fully-qualified Name with an Organizational Unit

Consider a directory server that contains an entry for database object sales with a DN of cn=sales,cn=OracleContext,dc=jp,dc=example,dc=com. In this example, the client requires a connect identifier of sales.jp.example.com.

Consider a similar entry that contains database object sales with a DN of cn=sales,cn=OracleContext,ou=mktg,dc=jp,dc=example,dc=com.

Because domain components must be separated from organization units, the client must use the format cn.ou@dc.dc.dc. The client requires the connect identifier to be sales.mktg@jp.example.com.

Figure 3-5 illustrates the preceding example.

Figure 3-5 Fully-qualified Name for Domain Component Namespaces

Description of "Figure 3-5 Fully-qualified Name for Domain Component Namespaces"

3.2.1.2 Fully-qualified Names for X.500 Namespaces

For X.500 namespaces, the default directory entry defined for the client must be in one of the following formats:

[ou],o

[ou],o,c

In the preceding formats, [ou] represents an optional organizational unit name.

The fully-qualified name the client uses as the connect identifier must be in one of the following formats:

cn[.ou].o

cn[.ou].o.c

In the preceding formats, [cn] represents the Oracle Net entry.

For example, if the directory contains database object sales with a DN of cn=sales,cn=OracleContext,ou=mktg,o=example,c=jp, then the client requires a connect identifier of sales.mktg.example.jp. Figure 3-6 illustrates this example.

Figure 3-6 Fully-qualified Name for X.500 Namespaces

Description of "Figure 3-6 Fully-qualified Name for X.500 Namespaces"

3.2.1.3 Using an Entry's Relative Name

If a client is configured with a default realm Oracle Context, then an entry can be identified by its relative name, and the service can be referred to by its common name. A relative name can be used if the entry is in the same Oracle Context that was configured to be the default Oracle Context for the client's Oracle home.

Consider a directory server that contains an entry for a database called sales with a DN of dn:cn=sales,cn=OracleContext,o=example,c=us, as shown in Figure 3-7. If the client is configured with a default realm Oracle Context of cn=OracleContext,o=example,c=us, then the connect identifier can simply be sales.

Figure 3-7 Relative Naming

Description of "Figure 3-7 Relative Naming"

Note:

The JDBC OCI Driver supports both relative and full-qualified naming. The JDBC Thin Driver supports fully-qualified naming only when the complete DN is used.

See Also:

• Oracle Internet Directory Administrator's Guide for additional information about how clients locate a directory

• Oracle Database JDBC Developer's Guide and Reference for additional information about JDBC drivers

3.2.2 Understanding Oracle Context

In Figure 3-8, the entries db1 and sales reside under cn=OracleContext. This entry is a special RDN called an Oracle Context. The entries under Oracle Context support various directory-enabled features, including directory naming.

Figure 3-8 Oracle Context in the DIT

Description of "Figure 3-8 Oracle Context in the DIT"

During directory configuration, you set the default Oracle Context. Clients use this Oracle Context as the default location to look up connect identifiers in the directory server. With Oracle Internet Directory, an Oracle Context located at the root of the DIT, with DN of dn:cn=OracleContext, points to a default Oracle Context in an identity management realm. An identity management realm is a collection of identities governed by the same administrative policies. This Oracle Context is referred to as a realm Oracle Context. Unless configured to use another Oracle Context, clients use this realm-specific Oracle Context.

The default Oracle Context affects the connect string. For example, if a client must access the db1 and sales entry frequently, then a reasonable default Oracle Context would be dc=jp,dc=example,dc=com. If a client directory entry does not match the directory entry where a service is located, then the client must specify an entry's fully-qualified name in the connect string, as described in "Client Connections Using Directory Naming".

3.2.3 Understanding Net Service Alias Entries

Directory naming enables you to create net service alias entries in addition to database service and net service name entries. A net service alias is an alternative name for a net service name or database service. A net service alias entry does not have connect descriptor information. Instead, it references the location of the entry for which it is an alias. When a client requests a directory lookup of a net service alias, the directory determines that the entry is a net service alias and completes the lookup as if it is the referenced entry. For example, in Figure 3-9, a net service alias of db1alias is created for a database service of db1. When db1alias is used to connect to a database service, as in CONNECT username@db1alias, it will actually resolve to and use the connect descriptor information for db1.

Figure 3-9 Net Service Alias db1alias in a Directory Server

Description of "Figure 3-9 Net Service Alias db1alias in a Directory Server"

There are several uses for using net service aliases. As shown in Figure 3-9, a net service alias can be useful as a way for clients to refer to a net service name by another name. Another use is to have a net service alias in one Oracle Context for a database service or net service name in a different Oracle Context. This enables a database service or net service name to be defined once in the directory server, but referred to by clients that use other Oracle Contexts.

In Figure 3-10, database service db1 resides in dc=jp,dc=example,dc=com. A net service alias named db1 is created in dc=us,dc=example,dc=com. This enables clients in both Japan and the United States to use the connect string CONNECT username@db1 as opposed to clients in the Unites States needing to specify CONNECT username@db1.jp.example.com.

Figure 3-10 Net Service Alias db1 in a Directory Server

Description of "Figure 3-10 Net Service Alias db1 in a Directory Server"

3.2.4 Who Can Add or Modify Entries in the Directory Server

Database Configuration Assistant creates database service entries during or after installation. You can then use Oracle Enterprise Manager or Oracle Net Manager to modify the Oracle Net attributes of the database service entries. You can also use these tools to create net service name and net service alias entries.

To use these configuration tools, a DIT structure containing a root Oracle Context and identity management realm must exist. The directory administrator creates this structure with Oracle Internet Directory Configuration Assistant. For some deployments, the directory administrator may need to create additional Oracle Contexts. Additional Oracle Contexts are usually used to subdivide large sites, or separate a production environment from a test environment.

Certain tools are used by certain groups, and you must be a member of the group to use the tools, as shown in the following:

• To create a database service entry with Database Configuration Assistant:

  • OracleDBCreators group (cn=OracleDBCreators,cn=OracleContext...)

  • OracleContextAdmins group (cn=OracleContextAdmins,cn=Groups,cn=OracleContext...)

• To create net service names or net service aliases with Oracle Net Manager:

  • OracleNetAdmins group (cn=OracleNetAdmins,cn=OracleContext...)

  • OracleContextAdmins group

The OracleContextAdmins group is a super-user group for Oracle Context. Members of the OracleContextAdmins group can add all supported types of entries to Oracle Context.

The directory user that created Oracle Context is automatically added to these groups. Other users can be added to these groups by the directory administrator.

3.2.5 Client Connections Using Directory Naming

Most clients need to perform name lookups in the directory server. To perform a lookup, the directory server must allow anonymous authentication. Directory servers usually do this by default.

To look up entries, a client must be able to find the directory server in which that entry resides. Clients locate a directory server in one of two ways:

• Dynamically using DNS. In this case, the directory server location information is stored and managed in a central domain name server. The client, at request processing time, retrieves this information from DNS.

• Statically in the directory server usage file, ldap.ora, created by Oracle Internet Directory Configuration Assistant and stored on the client host.

After a directory is found, clients are directed to the realm Oracle Context from the root Oracle Context.

Clients make connections to a database using connect identifiers in the same way they might use other naming methods. A connect identifier can be a database service, net service name, or net service alias. These can be referred to by their common names, or they can require additional directory location information. The default Oracle Context determines how the connect identifier must be specified, either by the entry's relative name or its fully-qualified name.

3.2.6 Considerations When Using Directory Servers

The following considerations should be reviewed when using directory servers:

• Performance Considerations

• Security Considerations

• Object Classes

dn: cn=sales,cn=oraclecontext,dc=example,dc=com
replace: orclentrylevelaci
orclentrylevelaci: access to attr=(*)
 by dn="cn=user1" (noread,nosearch,nowrite,nocompare)

3.2.7 Limitations of Directory Naming Support with Microsoft Active Directory

In addition to Oracle Internet Directory, directory naming support is also provided with Microsoft Active Directory with the following limitations:

• Clients running Microsoft Windows operating system can use Microsoft Active Directory to resolve net services names, even when the database is running on an operating system that is not Microsoft Windows.

• Oracle Database can use Microsoft Active Directory for name resolution for outbound network connections, such as database links or Oracle Data Guard, only if the database is running on a Microsoft Windows platform.

• Configuration of net services names can only be done using Oracle Net Manager running from a Microsoft Windows platform.

• Client computers and the database server must run on Microsoft Windows operating systems to access or create entries in Microsoft Active Directory.

• The following features are not supported by Microsoft Active Directory:

  • Multiple Oracle Contexts

    Microsoft Active Directory can support only one Oracle Context.

  • Net service aliases

    You cannot create net service aliases in Microsoft Active Directory. However, you can create net service names.

  • Automatic client discovery of directory servers for clients

    You must statically configure directory server usage on the clients. The Oracle Internet Directory Configuration will not provide directory server usage for Microsoft Active Directory. You must use Oracle Net Configuration Assistant.