Oracle Directory Naming and Internet Directory

Oracle Internet Directory (OID) was introduced with Oracle8i. It replaced Oracle Names, the centralized naming service used in earlier database releases, and it does the same fundamental job that Oracle Names did: giving clients a way to connect to an Oracle server without a client-side configuration file. OID is an LDAP (Lightweight Directory Access Protocol) directory, so it supports Oracle Net alongside other LDAP-enabled protocols.

Worth a currency note before going further: for most new designs today, Oracle points toward Oracle Unified Directory (OUD) rather than OID as the LDAP directory service. You'll still see OID as a configuration value, the DIRECTORY_SERVER_TYPE parameter uses it generically to mean "an OID-compatible directory," which covers OID itself, OUD, or OpenLDAP, so the acronym persists in configuration files even where the actual product running is OUD. That's a separate question from database identity, though: if what you actually need is centralized user authentication rather than net service name resolution, Oracle's current recommendation is Centrally Managed Users (CMU), confirmed directly in the Administrator's Guide: "Enterprise User Security (EUS) is deprecated with Oracle AI Database 26ai. Oracle recommends that you migrate to using Centrally Managed Users (CMU)." CMU connects directly to Microsoft Active Directory for authentication and authorization, without an intervening directory service at all, or to a cloud identity provider if your database runs in the cloud. Keep that distinction straight: this lesson is about resolving connect identifiers to connect descriptors, not about user identity, CMU solves a related but genuinely different problem.

Oracle Names has been deprecated since Oracle 9i. It was formally deprecated in that release and is no longer supported at all; Oracle recommends Net Service Names, resolved through local naming, directory naming, or Easy Connect, in its place. That's still true in Oracle AI Database 26ai: Oracle Names itself was removed long ago, but the replacement Oracle recommended back then, Net Service Names, remains part of Oracle Net Services today. Current 26ai documentation still covers creating and managing net service names in tnsnames.ora, using Oracle Net Manager or the Net Configuration Assistant to manage them, connect descriptors that map a net service name to a SERVICE_NAME, and directory naming of net service names and aliases through OID.

Oracle deprecated Oracle Names for a combination of reasons worth understanding, not just accepting:

1. Lack of standards compliance. Oracle Names used a proprietary resolution mechanism, incompatible with industry-standard directory services like LDAP, while the industry as a whole was moving toward open standards.
2. Limited scalability. It wasn't designed for large, enterprise-scale environments with hundreds or thousands of services, and it ran into real performance bottlenecks and administrative complexity as environments grew.
3. Weaker security. It lacked fine-grained security controls and modern authentication mechanisms like SSL/TLS or Enterprise User Security; LDAP-based directories support stronger encryption and role-based access control.
4. Manual, non-centralized administration. Oracle Names required manually configuring names servers and entries one at a time, without the centralized management or automated service registration a directory-based approach offers.
5. Poor integration with enterprise infrastructure. It was difficult to connect to existing enterprise directories like Active Directory or OpenLDAP; an LDAP-based directory integrates with corporate identity management naturally.

The modern replacement is Net Service Names stored in a directory service, Oracle Unified Directory (OUD) for new deployments, or Oracle Internet Directory (OID) where it's already in place, both of which support centralized configuration, dynamic service registration with service aliases, and LDAP-compliant resolution. Since Oracle Names has received no enhancements in a very long time and is fully unsupported, if you're still running an old Oracle Names configuration, migrating it to directory naming^[1] is the only real path forward.

This module covers how Directory Naming centralizes net service names, database service entries, and aliases that would otherwise have to live in individual client tnsnames.ora files. Directory Naming isn't a separate system alongside net service names, it's one of the places a net service name can actually live, resolved centrally through LDAP instead of copied out to every client by hand. Topics include:

1. A conceptual overview of how Directory Naming resolves a connect identifier through LDAP
2. Proper use of Directory Naming in a real environment
3. Configuring net service names and aliases in Oracle Internet Directory
4. Using Oracle Net Manager and the Net Configuration Assistant to manage directory naming
5. How directory naming fits alongside the other naming methods covered earlier in this course

The Oracle Names Control Utility is desupported and hasn't been available since Oracle 9.2, the last release that supported it; starting with Oracle Database 10g, it and its related control commands are entirely unsupported. A database client cannot use a Names Server to resolve connect strings anymore; the migration path is Oracle Internet Directory with LDAP directory naming, which is what the rest of this module actually covers.

Checking for deprecated parameters generally. Separately from Oracle Names specifically, it's worth knowing how to check whether any initialization parameter in your own environment is currently deprecated, since Oracle continues to deprecate parameters release over release. Run this in SQL*Plus:

SELECT name FROM v$parameter
WHERE isdeprecated = 'TRUE'
ORDER BY name;

The list this returns reflects your specific database version at the moment you run it, so treat any specific list you see in older material, including older versions of this course, as a snapshot from whatever release it was captured on, not a current or complete answer for 26ai. Run the query yourself against your own environment rather than relying on a list someone else captured years ago.

Starting with Oracle Database 12c, Oracle Enterprise Manager Database Control was desupported and is no longer available. Oracle Enterprise Manager Database Express (EM Express) replaced it, and remains the current lightweight, single-instance management tool today: it's built directly into the database, requires no separate installation, and covers the key performance and basic administration pages you'd otherwise need Cloud Control for, the Database Home page, Real-Time SQL Monitoring, and ASH Analytics among them. It's meant for managing one database instance at a time; for monitoring across multiple databases and the broader Oracle stack, Oracle Enterprise Manager Cloud Control is still the tool for that.

Worth being clear about scope here too: Oracle Names itself was never required by any Oracle environment. It was a management convenience that simplified maintaining Net8-era parameter files (now Oracle Net Services, with current connectivity increasingly handled through Easy Connect Plus or directory naming instead) and database links, not a mandatory component, which is part of why it was straightforward for Oracle to retire it once better alternatives existed.

After completing this module, you'll be able to:

1. Describe the architecture of Directory Naming
2. Describe how a connection request is resolved using Directory Naming
3. Store the overall network topology
4. Configure and manage net service names through Oracle Internet Directory

Let's begin with a conceptual overview of Directory Naming.

[1] directory naming: in Oracle, directory naming refers to a method for resolving network service names to connect descriptors using an LDAP-compliant directory server, such as Oracle Internet Directory. This approach centralizes database connection information, simplifying administration and improving security by storing connect descriptors in a secure, hierarchical structure.