3.2.6 Considerations When Using Directory Servers

The following considerations should be reviewed when using directory servers:

• Performance Considerations
  
• Security Considerations
  
• Object Classes
  

3.2.6.1 Performance Considerations

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. Users expect relatively quick performance so the database connect time is not affected. Because of the scope of the lookup, users may begin to notice slow connect times if lookups take 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

3.2.6.2 Security Considerations

Administrative clients can create and modify entries in the directory server, so security is essential. This section contains the following security-related topics:

• Authentication Methods
  Clients use different methods of authentication depending upon the task to be performed, such as resolving connect string names and managing directory entries.
• Access Control Lists
  Authentication is used with access control lists (ACLs) to determine whether clients can read, modify, or add information in the directory server.

3.2.6.2.1 Authentication Methods

Clients use different methods of authentication depending upon the task to be performed, such as resolving connect string names and managing directory entries.

• Clients that perform lookups for information in the directory server typically use anonymous authentication.

  You can configure the client LDAP naming adapter to authenticate the LDAP bind during name lookup. Sites that need to protect their network service data or disable anonymous binds to the directory must configure their clients to use wallets for authentication during name lookup.

  This configuration involves mapping the DN in the client certificate to the user's DN in the directory server. You must set the following parameters in the sqlnet.ora file for these clients:

  • NAMES.LDAP_AUTHENTICATE_BIND=TRUE
  • WALLET_LOCATION=location_value

  The Oracle wallet trust store must contain root certificates issued by the certificate authority of the LDAP server.

  Starting with Oracle Database 21c, you can configure the client LDAP naming adapter to authenticate the LDAPS bind using simple authentication. This method uses LDAP over TLS connection (LDAPS) by accessing the user name and password stored in the wallet.

  The parameter WALLET_LOCATION is deprecated for use with Oracle AI Database 26ai for the Oracle Database server. It is not deprecated for use with the Oracle Database client or listener.

  For Oracle Database server, Oracle recommends that you use the WALLET_ROOT system parameter instead of using WALLET_LOCATION.

• Clients that administer the directory server entries authenticate with the directory server. Database Configuration Assistant or Oracle Net Manager can be used to add or modify the entries. Only authenticated users with proper privileges can modify entries. Use one of the following authentication methods:

  • Simple Authentication

    The client identifies itself to the directory server using a DN and password. The server verifies that the DN and password sent by the client matches the DN and password stored in the directory server.

  • Strong Authentication

    The client identifies itself to the directory server using a public-key encryption available with Transport Layer Security (TLS). 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.

    If you have configured the directory server with mutual TLS authentication and have mapped the DN in the client certificate to the directory user entry, then the directory server uses the client certificate for authentication.

3.2.6.2.2 Access Control Lists

Authentication is used with access control lists (ACLs) to determine whether clients can read, modify, or add information in the directory server.

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, such as read or 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 Oracle Context using Oracle Net Configuration Assistant is automatically added as the first member of these groups.

Note:

Enterprise User Security (EUS) is deprecated with Oracle AI Database 26ai.

Oracle recommends that you migrate to using Centrally Managed Users (CMU). This feature enables you to directly connect with Microsoft Active Directory without an intervening directory service for enterprise user authentication and authorization to the database. If your Oracle Database is in the cloud, you can also choose to move to one of the newer integrations with a cloud identity provider.

Table 3-2 describes ACL requirements for these groups, anonymous users, and their relation to Oracle Net entries in the directory server.

Table 3-2 ACL Requirements for 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 Oracle Context. This enables anonymous users to browse directory naming entries contained within the cn=OracleContext RDN. Oracle Net Configuration Assistant sets up this access 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 using Oracle Enterprise Manager Cloud Control.
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 the 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 Manager Cloud Control.
OracleNetAdmins group users	Members of OracleNetAdmins (cn=OracleNetAdmins,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.

Situations in which a high degree of security is desired for lookup or read-access to Oracle Net Services name and related data, administrators can define additional read-access control for some or all of the data. Such ACL definitions can prevent anonymous users from reading the Oracle Net Services data. If read-access to Oracle Net Services data is restricted, then clients must use authenticated binds to do name lookups.

There are no predefined groups or procedures for the Oracle configuration tools for defining read-access restrictions on this data, so administrators must use standard object management tools from their directory system to manually create any necessary groups and ACLs.

ACLs can be added to Oracle Net Services objects using ldapmodify and an LDIF-format file. Example 3-2 shows how to restrict all access for user, cn=user1:

Example 3-2 Restricting User Access with an Access Control List

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

The preceding example illustrates the basic form of an ACL for a single object. This approach is not necessarily the best way to define access because access definitions for objects are complex and may involve security properties which are inherited from parent nodes in the DIT. Oracle recommends that administrators refer to the documentation for their directory systems, and integrate access management for Oracle Net Services objects into a directory-wide policy and security implementation.

For Oracle Internet Directory directories, oidadmin has functionality to create users, groups, and also define ACLs for objects and general directory security.

For more information on how to set ACLs on directory entry, see documentation from your directory server vendor.

3.2.6.3 Object Classes

Directories must be populated with the correct version of the Oracle schema before Oracle Context, a database service or network 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. The following table lists the object classes for database service, network service name, and network service alias entries.

Table 3-3 Oracle Net Services LDAP Main Object Classes

Object Class	Description
orclDbServer	Defines the attributes for database service entries.
orclNetService	Defines the attributes for network service name entries.
orclNetServiceAlias	Defines the attributes for network service alias entries.

The following table lists the object classes used by orclDbServer, orclNetService, and orclNetServiceAlias.

Table 3-4 Oracle Net Services LDAP Derived Object Classes

Object Class	Description
orclNetAddress	Defines a listener protocol address.
orclNetAddressList	Defines a list of addresses.
orclNetDescription	Specifies a connect descriptor containing the protocol address of the database and the connect information to the service.
orclNetDescriptionList	Defines a list of connect descriptors.

These object classes use attributes that specify the contents of connect descriptors.

See Also:

Oracle Database Net Services Reference for additional information about these object classes and their attributes