| Oracle® Database Net Services Administrator's Guide 10g Release 1 (10.1) Part Number B10775-01 |
|
|
View PDF |
| Oracle® Database Net Services Administrator's Guide 10g Release 1 (10.1) Part Number B10775-01 |
|
|
View PDF |
This chapter describes how configuration information for Oracle Net Services can be stored in localized configuration files or centralized in a directory server.
The topics covered include:
Configuration information can be stored in a localized configuration file or a centralized repository, as described in the Table 3-1.
Table 3-1 Oracle Net Configuration Models
| Network Configuration Model | Description |
|---|---|
| Localized management | Network address information stored in tnsnames.ora files on each computer in the network. |
| Centralized management | Network address information is stored in centralized directory services, including a LDAP-compliant directory server. |
Depending on the configuration model used, network computers can be configured with the files described in Table 3-2.
Table 3-2 Oracle Net Configuration Files
| Configuration File | Description |
|---|---|
cman.ora |
Located on the computer where Oracle Connection Manager runs, this configuration file includes:
Each Oracle Connection Manager configuration is encapsulated within a single NV string, which consists of the components just described. |
listener.ora |
Located on the database server, this configuration file for the listener may include:
|
sqlnet.ora |
Located on client and database server computer, this file may include:
|
tnsnames.ora |
Located primarily on the clients, this file contains net service names mapped to connect descriptors. This file is used for the local naming method. |
Configuration files are typically created in $ORACLE_HOME/network/admin on UNIX operating systems and ORACLE_HOME\network\admin on Windows operating systems. However, configuration files can be created in a variety of places, because Oracle Net searches for the configuration files in a variety of places.
The search order for sqlnet.ora is as follows:
The directory specified by the TNS_ADMIN environment variable
If the TNS_ADMIN environment variable is not defined as a variable on Windows, it may be in the registry.
The $ORACLE_HOME/network/admin directory on UNIX operating systems and the ORACLE_HOME\network\admin directory on Windows operating systems
The search order for cman.ora, listener.ora, and tnsnames.ora is as follows:
The directory specified by the TNS_ADMIN environment variable
If the TNS_ADMIN environment variable is not defined as a variable on Windows, it may be in the registry.
On UNIX operating systems, the global configuration directory
For example, on the Solaris Operating System, this directory is /var/opt/oracle.
The $ORACLE_HOME/network/admin directory on UNIX operating systems and the ORACLE_HOME\network\admin directory on Windows operating systems.
|
See Also: Oracle operating system-specific documentation |
Today, network information is stored in multiple systems and in multiple directory formats. With new requirements for Internet computing and new e-business technologies, a common repository infrastructure is needed as a foundation for management and configuration of all data and resources. This kind of infrastructure reduces the cost of managing and configuring resources in a network.
Support of Oracle Internet Directory provides a centralized vehicle for managing and configuring a distributed Oracle network. The directory server can replace clientside and serverside localized tnsnames.ora files.
This section contains these topics:
Oracle Net Services use a centralized directory server as one of the primary methods for storage of connect identifiers. Clients can use the connect identifiers in their connect string. The directory server resolves the connect identifier to a connect descriptor that is passed back to the client. This feature is called directory naming
Figure 3-1 shows a client resolving a connect identifier through a directory server.
The client contacts the directory server to resolve a connect identifier to a connect descriptor.
The directory server resolves the connect identifier and retrieves the connect descriptor for the client.
The client sends the connection request to the listener, using the connect descriptor.
|
Notes: Java Database Connectivity (JDBC) Drivers support directory naming. See the Oracle Database JDBC Developer's Guide and Reference for further information. |
Directory servers store information in a tree structure called a directory information tree (DIT). Each node in the tree is called an entry. Oracle Net Services makes use of both the tree structure and specific entries in the tree. For example, consider Figure 3-2.
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/password@sales and CONNECT username/password@db1.
Each entry is uniquely identified by a distinguished name (DN). The DN tells you exactly where the entry resides in the directory server's hierarchy. The DN for db1 is dn:cn=db1,cn=OracleContext,dc=jp,dc=acme,dc=com, and the DN for sales is dn:cn=sales,cn=OracleContext,dc=jp,dc=acme,dc=com. Note that 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), much the way a directory path contains a sequence of directories. In the entry for db1, the RDN is cn=db1. An entry is made up of a set of attributes. For example, in cn=db1, cn is one of the entry's attributes. The attribute, along with its value, uniquely identifies the entry.
Notice that db1 and sales reside under cn=OracleContext. This entry is a special RDN called an Oracle Context. The entries under the Oracle Context support various directory-enabled features, including directory naming.
During directory usage configuration, you establish a 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 an realm Oracle Context. Unless configured to use another Oracle Context, clients use this realm-specific Oracle Context as the default Oracle Context.
The default Oracle Context affects the connect string. For example, if a client needs to access the db1 and sales entry frequently, a reasonable default Oracle Context would be dc=jp,dc=acme,dc=com. cn=OracleContext does not have to be explicitly specified in the connect string. If a client's directory entry does not match the directory entry where the service is located, then the client must specify an entry's absolute name in the connect string, as described in "Client Connections Using Directory Naming ".
|
See Also: Oracle Internet Directory Administrator's Guide for further information about a identity management realm |
In addition to database service and net service name entries, directory naming enables you to create net service alias 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 only 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-3, 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/password@db1alias, it will actually resolve to and use the connect descriptor information for db1.
There are several uses for using net service aliases. As shown in Figure 3-3, 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-4, database service db1 resides in dc=jp,dc=acme,dc=com. A net service alias named db1 is created in dc=us,dc=acme,dc=com. This enables clients in both Japan and the United States to use the connect string CONNECT username/password@db1 as opposed to clients in the United States needing to specify CONNECT username/password@db1.jp.acme.com.
DITs are commonly structured using:
A Domain Name Space (DNS) structure
A geographical and organization structure
Other structures are also permitted, but Oracle Corporation provides support for these structures.
Figure 3-5 shows a DIT structured according to DNS domain components.
Figure 3-6 shows a DIT structured according to country, organization, and organizational units. This structure is commonly referred to as an X.500 DIT.
Database Configuration Assistant creates database service entries during or after some modes of 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.
Figure 3-7 shows how the tools interface with the directory server.
|
Note: Oracle Enterprise Manager is supported but not represented in this figure. |
Clients that can locate a directory, as described in "Client Connections Using Directory Naming ", can connect to a database using entries created by these configuration tools.
To use these configuration tools to add entries, 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.
To create directory naming entries with the Oracle Enterprise Manager or Oracle Net Manager, you must be a member of the following groups:
OracleDBCreators group (cn=OracleDBCreators,cn=OracleContext...) or the OracleContextAdmins group (cn=OracleContextAdmins,cn=Groups,cn=OracleContext...) to create a database service entry with Database Configuration Assistant
OracleNetAdmins group (cn=OracleNetAdmins,cn=OracleContext...) or the OracleContextAdmins group to create net service names or net service aliases with Oracle Net Manager
The directory user that created the Oracle Context is automatically added to these groups. Other users can be added to these groups by the directory administrator.
The OracleContextAdmins group is a super-user group for the Oracle Context. Members of the OracleContextAdmins group can add all supported types of entries to the Oracle Context.
|
See Also:
|
Most clients only 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 in one of two ways:
Dynamically, by using DNS. In this case, the directory server location information is stored and managed in a central domain name server, and the client, at request processing time, retrieves this information from the DNS server dynamically.
Statically, in a directory server usage file (ldap.ora) created by Oracle Internet Directory Configuration Assistant and stored on the client host
Once a directory is found, clients are directed to the realm Oracle Context from the root Oracle Context.
In the same way they might use other naming methods, clients make connections to a database using connect identifiers. 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.
An entry may be identified in one of two ways:
Using the Entry's Absolute Name
|
Note: The JDBC OCI Driver supports both relative and absolute naming. The JDBC Thin Driver supports absolute naming only when the complete DN is used. See the Oracle Database JDBC Developer's Guide and Reference for further information. |
|
See Also: Oracle Internet Directory Administrator's Guide for further information about clients locate a directory |
In the following example, an entry is 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=acme,c=us, as shown in Figure 3-8. If the client is configured with a default realm Oracle Context of cn=OracleContext,o=acme,c=us, then the connect identifier can simply be sales.
Consider the same directory structure as shown Figure 3-8, but with the client's Oracle home configured with a default realm Oracle Context of cn=OracleContext,o=acme,c=jp.
Because the client is configured with a default Oracle Context that does not match the location of sales in the directory server, a connect string that uses sales does not work. Instead, the client must specifically identify the location of sales, which can be done in one of two ways:
The entry's complete DN can be used in the connect string, for example:
CONNECT username/password@"cn=sales,cn=OracleContext,o=acme,c=us"
Many applications do not support the use of a DN.
The entry can be referred to by a fully-qualified name, a name that includes the name of the object and its location in the directory server, for example:
CONNECT username/password@sales.acme.us
|
See Also: "Absolute Name Specification for Directory Naming" for further information about absolute names |
If you are responsible for designing directory servers for directory naming, consider the following issues:
Connect identifiers are stored in a directory server for all clients to access. Depending on the number of clients, there can be a significant load on a directory server.
During a connect identifier lookup, a name is searched under a specific Oracle Context. Because of the scope of the lookup, you probably want users to experience relatively quick performance so that the database connect time is not affected. Users may begin to notice slow connect times if lookups takes more than one second.
You can resolve performance problems by changing the network topology or implementing replication.
|
See Also: Directory server vendor documentation for details on resolving performance issues |
Because administrative clients can create and modify entries in the directory server, security is essential. This section covers the following security-related topics:
Clients that perform lookups for information in the directory server typically use anonymous authentication.
Clients that add or modify entries in a directory must authenticate with the directory server. Database Configuration Assistant or Oracle Net Manager may be used to add or modify the entries. Only authenticated users with proper privileges can modify entries. Use one of the following authentication methods:
The client identifies itself to the directory server by means of a DN and a password, which are sent in the clear over the network. The server verifies that the DN and password sent by the client match the DN and password stored in the directory server.
Directories provide strong authentication by using public-key encryption available with Secure Sockets Layer (SSL). In public-key encryption, the sender of a message encrypts the message with the public key of the recipient. Upon delivery, the recipient decrypts the message using the recipient's private key.
Authentication is used with access control lists (ACLs) to make decisions about whether clients can modify or add information in the directory server. ACLs are created at the same time as the Oracle Context with Oracle Net Configuration Assistant during directory server access configuration.
ACLs specify the following:
The entries that the user can access
The authentication method used to access the entry
The access rights, or what the user can do with the object (read/write)
ACLs are established for a group of users. During Oracle Context creation, the OracleDBCreators, OracleNetAdmins, and OracleContextAdmins groups are created.
The user who creates the Oracle Context with Oracle Net Configuration Assistant is automatically added as the first member of these groups.
Table 3-3 describes ACL requirements for these groups and anonymous users and their relation to Oracle Net entries in the directory server.
Table 3-3 LDAP Directory User Groups
| Group | ACL Requirements |
|---|---|
| Anonymous users | All Oracle Net attributes and objects in the directory server have read access for the anonymous user. Read access of these objects for anonymous is also applied to the Oracle Context. This enables anonymous users to browse directory naming entries contained within the cn=OracleContext RDN. This does not include objects used for enterprise user security.
Oracle Net Configuration Assistant sets up this access right during client installation. |
| OracleContextAdmins group users | Members of OracleContextAdmins (cn=OracleContextAdmins,cn=Groups,cn=OracleContext,...) have create, modify, and read access to all directory naming objects. Oracle Net Configuration Assistant establishes these access rights for this group during Oracle Context creation.
In addition to the Oracle Context creator, other users can be added to this group by the directory administrator with Oracle Enterprise Security Manager. |
| OracleDBCreators group users | Members of OracleDBCreators (cn=OracleDBCreators,cn=OracleContext,...) have create and read access to database service objects and attributes. Oracle Net Configuration Assistant establishes these access rights for this group during Oracle Context creation.
In addition to the Oracle Context creator, other users can be added to this group by the directory administrator with Oracle Enterprise Security Manager. See Also: Oracle Advanced Security Administrator's Guide for further information about the OracleDBCreators group |
| OracleNetAdmins group users | Members of OracleNetAdmins (cn=OracleOracleNetAdmins,cn=OracleContext,...) have create, modify, and read access to directory naming objects and attributes. Oracle Net Configuration Assistant establishes these access rights for this group during Oracle Context creation.
In addition to the Oracle Context creator, other users can be added to this group by the directory administrator. See Also: "Administering the OracleNetAdmins Group" for information on adding users to the OracleNetAdmins group |
Directories must be populated with the correct version of the Oracle schema before Oracle Contexts or a database service or net service name entry can be created. The Oracle schema defines the type of objects, called object classes, that can be stored in the directory server and their attributes. Table 3-4 lists the object classes for database service, net service name, and net service alias entries.
Table 3-4 Oracle Net Services LDAP Main Object Classes
Table 3-5 lists the object classes used by orclDbServer, orclNetService, and orclNetServiceAlias.
Table 3-5 Oracle Net Services LDAP Derived Object Classes
These object classes use attributes that specify the contents of connect descriptors.
|
See Also: Oracle Net Services Reference Guide for further information about these object classes and their attributes |
In addition to Oracle Internet Directory, directory naming support is also provided with Microsoft Active Directory. Note the following limitations:
Oracle provides support for Microsoft Active Directory only on Windows operating systems. Therefore, client computers and the database server must also run on 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.
