LDAP Directory Naming in Oracle AI Database 26ai

Directory Naming maps connect identifiers to connect descriptors in an LDAP-compliant directory. Clients look up a database service, net service name, or net service alias in the directory instead of in a per-host tnsnames.ora file (worth pairing with a predictable naming and distribution strategy, tested with TNSPING, for whatever local entries remain in the mix) or the retired Oracle Names service.

Oracle Names and the namesctl utility are obsolete. Do not install, start, or administer a Names server on 26ai. There is no namesctl replacement command for Directory Naming. You administer the directory with the directory's own tools, and you administer Oracle Net objects with Oracle Net Configuration Assistant (NetCA), Oracle Net Manager, or Enterprise Manager Cloud Control.

Supported directory servers for 26ai Directory Naming include:

• Oracle Internet Directory (OID), still supported but now legacy for most new designs; Oracle Unified Directory is the current recommendation for new LDAP directory service deployments
• Oracle Unified Directory (OUD)
• OpenLDAP (same DIRECTORY_SERVER_TYPE=OID as OID/OUD)
• Microsoft Active Directory (DIRECTORY_SERVER_TYPE=AD)

Worth being precise about scope here too: this list is about where net service names live, not about database identity. For enterprise user authentication specifically, Centrally Managed Users (CMU), covered in Lesson 1, is the current recommendation over the older Enterprise User Security approach; Directory Naming of net services doesn't require either one. Connect identifiers live under an Oracle Context, typically cn=OracleContext plus your domain components, for example cn=sales,cn=OracleContext,dc=example,dc=com. Object classes include orclDbServer (database service), orclNetService (net service name), and orclNetServiceAlias (alias with no connect descriptor of its own).

Comparison:

• Oracle Names (legacy): Central Names database plus namesctl. Removed from current releases.
• Local naming: tnsnames.ora on each client.
• Directory Naming (26ai): LDAP lookup via ldap.ora/sqlnet.ora, or LDAP parameters embedded in the connect identifier. No namesctl.
• Easy Connect / Centralized Configuration Provider: Alternatives when you do not want LDAP.

1. Create or confirm Oracle Context in the directory
   • Use the directory administration console (OID/OUD/AD tools) so an Oracle Context exists in the naming context you will use.
   • NetCA can create Oracle Context and the OracleContextAdmins group when you have directory privileges.
   • Enterprise User Security (EUS) is deprecated in 26ai. For enterprise users, plan Centrally Managed Users (CMU), not EUS. Directory Naming of net services does not require EUS.
2. Run Oracle Net Configuration Assistant (Directory Usage)
   • From the Oracle home: $ORACLE_HOME/bin/netca
   • Select Directory Usage Configuration.
   • Directory type: Oracle Internet Directory (use this choice for OID or OUD) or Active Directory.
   • Enter host and ports (LDAP and LDAPS, for example 389 and 636).
   • Select the naming context that contains cn=OracleContext.
   NetCA writes ldap.ora. Location:
   • $TNS_ADMIN if set
   • otherwise $ORACLE_HOME/network/admin or, for a read-only home, $ORACLE_BASE_HOME/network/admin
   Do not hand-edit ldap.ora unless you must; regenerate it with NetCA when the directory topology changes.
3. Point the client at LDAP in sqlnet.ora
   • Put LDAP first (or only) in the naming method list.
   • The default, if you omit the parameter entirely, is (tnsnames, ezconnect, ldap); set LDAP first when the directory is the source of truth.
   • This is also the file that holds the outbound, inbound, send, and receive timeout parameters, worth setting deliberately here too, so an unreachable directory server fails cleanly instead of hanging a client.

   NAMES.DIRECTORY_PATH = (LDAP, TNSNAMES, EZCONNECT)
   NAMES.DEFAULT_DOMAIN = example.com

4. Create directory entries
   • Oracle Net Manager: Directory folder, or local export of tnsnames.ora entries into the directory.
   • Enterprise Manager Cloud Control: Net Services Administration, Directory Naming, Net Service Names / aliases.
   • DBCA can register the database service in the directory when Directory Naming is configured.
5. Optional: authenticated LDAP bind with a client wallet
   • Anonymous browse of cn=OracleContext is common for name lookup.
   • For authenticated bind, store the LDAP user DN and password in a client wallet. mkstore is deprecated in 26ai; use orapki instead. Prefer auto-login wallet version 7, new with 26ai, over the older version 6.
   • WALLET_LOCATION is still valid on the client (and listener). It's deprecated on the database server specifically; servers use WALLET_ROOT instead.

   NAMES.LDAP_AUTHENTICATE_BIND = TRUE
   NAMES.LDAP_AUTHENTICATE_BIND_METHOD = LDAPS_SIMPLE_AUTH
   WALLET_LOCATION =
     (SOURCE =
       (METHOD = FILE)
       (METHOD_DATA = (DIRECTORY = /u01/app/oracle/wallet/ldap)))

6. Verify

   tnsping sales.example.com
   sqlplus appuser@sales.example.com

   You can also list connect strings with the 26ai connstr utility, covered in the previous lesson.

Example ldap.ora

DIRECTORY_SERVERS = (ldap1.example.com:389:636, ldap2.example.com:389:636)
DEFAULT_ADMIN_CONTEXT = "dc=example,dc=com"
DIRECTORY_SERVER_TYPE = OID

For Active Directory use DIRECTORY_SERVER_TYPE = AD. Example sqlnet.ora

NAMES.DIRECTORY_PATH = (LDAP, TNSNAMES, EZCONNECT)
NAMES.DEFAULT_DOMAIN = example.com

26ai can pass Directory Naming parameters in the connect string itself. Values in the string override ldap.ora/sqlnet.ora when both exist.

ldap[s]://host[:port]/name[,context][?parameter=value{&parameter=value}]

Example:

sqlplus "appuser/password@ldaps://ldap1.example.com:636/cn=sales,cn=OracleContext,dc=example,dc=com?DIRECTORY_SERVER_TYPE=oid&AUTHENTICATE_BIND=true&AUTHENTICATE_BIND_METHOD=LDAPS_SIMPLE_AUTH&WALLET_LOCATION=/u01/app/oracle/wallet/ldap"

DIRECTORY_SERVER_TYPE is oid (OID, OUD, OpenLDAP) or ad.

namesctl controlled Oracle Names servers (START, STOP, RELOAD, QUERY, and so on). Those operations have no 26ai equivalent because there is no Names server process.

Use these instead:

• Directory availability and schema: OID/OUD/AD consoles, ldapsearch, directory replication tools.
• Oracle Net client config: netca, netmgr, Enterprise Manager Cloud Control.
• Listener process control: still lsnrctl, unchanged role; it never replaced namesctl.
• Optional cache of directory entries: export Directory Naming entries to a tnsnames.ora file and distribute that file so clients can fall back to local naming if LDAP is unreachable.

Walking through the whole sequence for a fictional SALES service makes the individual pieces easier to place. Assume OID is already running, and an Oracle Context exists under dc=example,dc=com.

1. Run netca, choose Directory Usage Configuration, point it at the OID host on ports 389 and 636, and select the naming context containing cn=OracleContext. This writes ldap.ora to $TNS_ADMIN or the default network/admin location.
2. In sqlnet.ora, set NAMES.DIRECTORY_PATH = (LDAP, TNSNAMES, EZCONNECT) so LDAP is checked first, plus sane timeout values so a directory outage fails fast instead of hanging every client.
3. Create the SALES net service name entry itself, either through Oracle Net Manager's Directory folder, or by exporting an existing tnsnames.ora entry into the directory if one already exists locally.
4. Verify with tnsping SALES, then an actual connection attempt, sqlplus appuser@SALES, since a successful ping only confirms the listener is reachable, not that the service itself resolves and authenticates correctly.

If anonymous browse of cn=OracleContext isn't permitted in your directory's security policy, add the authenticated-bind parameters, NAMES.LDAP_AUTHENTICATE_BIND, the bind method, and a wallet location, created with orapki rather than the deprecated mkstore, before repeating the verification step.