Directory Naming: Module Summary

This module set out to explain Directory Naming, and doing that properly meant correcting a fair amount of folklore that had carried over from Oracle Names along the way. The two services solve the same basic problem, resolving a name a client types into the actual address of a database, but treating Directory Naming as simply "Oracle Names on LDAP" turns out to be wrong in specific, useful ways. This closing lesson pulls the seven lessons that got you here back together, corrections included.

Directory naming determines where to connect; it doesn't determine how the application establishes communication once it gets there, that's a separate concern, client connection handling, dedicated server, shared server, or Database Resident Connection Pooling, and the two are genuinely independent. A client supplies a net service name, the directory returns a connect descriptor, listener address and destination service, and the client uses that descriptor to reach the listener. Database authentication happens afterward, as its own step.

One distinction worth restating because it's easy to blur: a net service name is the object being resolved, unchanged in concept whether it lives in a local tnsnames.ora file or a centralized directory. Directory Naming isn't a competing system alongside net service names, it's one of several places a net service name can actually live, LDAP-based resolution instead of a copy distributed to every client by hand.

The directory landscape itself has a currency wrinkle worth carrying forward: Oracle Internet Directory is still supported, but Oracle Unified Directory is the current recommendation for new deployments. You'll still see DIRECTORY_SERVER_TYPE=OID in configuration files even where OUD is the product actually running, since that value is used generically for any OID-compatible directory. And directory naming for net service names is a genuinely different question from database identity: for centralized user authentication specifically, Centrally Managed Users is the current recommendation over the older, now-deprecated Enterprise User Security, and it connects straight to Active Directory or a cloud identity provider without an intervening directory service. Keep the two apart; this module is about the first one.

A concrete resolution walks through five steps: the client checks local naming first, finds nothing, and falls back to the directory; it sends a resolution request for the net service name; the directory returns a connect descriptor with no database credentials in it; the client connects to the listener directly using that descriptor; and only then does it authenticate, as a separate step handled at the database itself.

That "no credentials in the response" detail deserves the more precise version this module eventually arrived at, since the first pass overstated it. Oracle Names' standard response for an ordinary client lookup was also just a plain connect descriptor, no credentials involved; the credential-bearing behavior was a narrower, optional feature tied specifically to configured global database links, where Oracle Names could store a link's user ID and password so it would authenticate automatically. That was a real security consideration, a shared stored credential exposing the linked account, but it was never the standard behavior for every lookup. What Directory Naming actually removed is that one legacy exception, not a general credential leak that never existed as broadly as it first sounded.

Every step in a resolution assumes the directory actually answers, which is why sqlnet.ora's timeout parameters, OUTBOUND_CONNECT_TIMEOUT, INBOUND_CONNECT_TIMEOUT, SEND_TIMEOUT, and RECV_TIMEOUT, matter specifically for Directory Naming: without them, an unreachable directory server can hang a client indefinitely instead of failing cleanly with a usable error.

Oracle's own documentation lays out a real, specific comparison across three naming methods, Local Naming, Directory Naming, and Centralized Configuration Provider Naming, and the threshold is concrete rather than a vague "it depends": past roughly 20 client machines with services that change often, the cost of hand-updating every client's local configuration starts to outweigh the cost of running a centralized directory. A ten-person shop with two stable databases stays in Local Naming territory comfortably; a 200-client organization adding and retiring services every quarter is exactly the gap Directory Naming closes. Beyond raw client count, wanting one authoritative catalog of services and aliases, needing cross-Context aliases for multi-domain setups, or already running LDAP for other purposes all point the same direction.

The real disadvantage is just as concrete: once clients depend on the directory to connect at all, its availability becomes your availability, which is exactly why this module also covered redundant directory servers, more than one server holding the same naming entries, as a real mitigation with its own real infrastructure cost, not a free add-on. A few more specific signals worth checking beyond the client-count threshold: needing an alias defined in one Oracle Context that points to a service in a different Context, useful for multi-domain or multi-region setups, is something only Directory Naming supports at all; wanting to migrate existing tnsnames.ora entries into a central store rather than maintaining both indefinitely is another. And where the deciding factor is a cloud configuration store rather than LDAP specifically, Centralized Configuration Provider Naming, using OCI Object Storage or Azure App Configuration, covers the same large-and-changing profile without requiring a directory service at all.

Four files, not two, represent the local view of network topology on any given host: tnsnames.ora for net service names, sqlnet.ora for naming method order, tracing, security, and those same timeout parameters, listener.ora for the listener's own endpoints, and cman.ora where Connection Manager is in use. Keeping those first two straight matters: sqlnet.ora does not configure the listener's port, that's listener.ora's job specifically, a conflation worth catching since it would send someone troubleshooting a listener problem to the wrong file entirely. All four have predictable default locations under a home's own network/admin directory, overridable with TNS_ADMIN.

Oracle Names had its own dedicated configuration file, names.ora, and it's worth remembering why that mattered beyond just being outdated syntax: a real names.ora file carried an administrative password in plain text, directly in the file, readable by anyone with filesystem access. That's a genuine security weakness, a different specific instance of the credential-handling pattern this module kept returning to. Directory Naming has no equivalent file and no equivalent weakness, because there's no local, dedicated server process to configure in the first place; whatever authentication a directory requires runs through that directory product's own, generally more robust, security model instead.

The actual setup sequence has a handful of concrete pieces worth remembering as a checklist: confirm an Oracle Context exists in the directory (NetCA can create one, along with the OracleContextAdmins group); run NetCA's Directory Usage Configuration to write ldap.ora; set NAMES.DIRECTORY_PATH in sqlnet.ora with LDAP positioned where it actually belongs in your search order (the default, if you never touch it, is (tnsnames, ezconnect, ldap)); create the actual net service name entries through Oracle Net Manager or Enterprise Manager Cloud Control; and, where anonymous directory browsing isn't permitted, configure an authenticated LDAP bind using a client wallet.

That last piece has real, current specifics worth holding onto: mkstore is deprecated in favor of orapki, and 26ai introduces a new auto-login wallet version, version 7, superseding version 6. WALLET_LOCATION itself is deprecated only on the database server side, where WALLET_ROOT is now the recommendation; it remains valid on the client and listener. And 26ai clients don't strictly need ldap.ora or sqlnet.ora configured at all, LDAP parameters can be embedded directly in the connect identifier, with connect-identifier values winning whenever both exist.

Strung together end to end for a single fictional service, that sequence looks like: run netca's Directory Usage Configuration against the directory host, set the naming search path and timeouts in sqlnet.ora, create the actual entry through Oracle Net Manager or by exporting an existing local one, then verify with tnsping followed by an actual connection attempt, since a successful ping only confirms the listener is reachable, not that the service resolves and authenticates correctly end to end.

There's no Names control utility in current Oracle Net, and that's an architectural fact worth understanding rather than a missing feature to mourn: namesctl existed because the Names server was a single-purpose Oracle component with nothing else to administer. A directory server is different by design, the same LDAP server might authenticate a dozen unrelated applications, so it's managed through its own general-purpose tools, oidadmin for Oracle Internet Directory, the directory product's own service commands to start and stop it, rather than an Oracle Net-specific utility.

What actually happens during a directory outage is the most practically useful thing this module can leave you with. Sessions already connected keep working entirely undisturbed, the directory was only consulted once, at connection time. New connections that depend on Directory Naming fail at the resolution step, cleanly and fast if timeouts are configured, as a hang if they aren't. The database itself is completely unaffected; it has no dependency on the directory at all. And a client still holding a cached local tnsnames.ora entry, if local naming sits in the fallback path, can often connect anyway, which is exactly why keeping an exported local-naming fallback is worth its small maintenance cost for anything genuinely critical. That asymmetry, existing sessions fine, new ones blocked, database untouched, is the whole practical shape of what Directory Naming actually depends on: a client connectivity problem, never a data availability one.

Step back and the throughline across all seven lessons is really one idea, examined from several angles: Oracle Names' job, centralizing what used to be scattered across individual client files, was genuine and worth keeping; its specific implementation, a proprietary protocol, a single-purpose server, credentials and administration bundled together in ways that don't hold up, was what actually needed replacing. Directory Naming keeps the job and changes the implementation to a standard, general-purpose protocol with the pieces properly separated: naming here, authentication there, administration through the tools built for what's actually being administered. The next module in this course builds on that same architecture from a different angle.

Before moving on to the next module, click the Quiz link below to test your knowledge of Oracle Names.
Oracle Names - Quiz
The next module looks at the Oracle Enterprise Manager Console and how it handles distributed communications within Oracle.