Search Results get_dn_for_guid

Overview

FND_LDAP_UTIL is a utility package owned by the APPS schema that provides the integration layer between Oracle E-Business Suite and an external LDAP directory service. Its principal role is to support Oracle Internet Directory (OID) based authentication and user provisioning, allowing EBS to authenticate users against a central enterprise directory rather than relying solely on native FND_USER credentials. The package encapsulates the record structures, constants, and session handling logic needed to bind to the directory, read and write user attributes, and map those attributes to the EBS user model. The ldap_user_type record declared in the package specification defines the canonical attribute set — including uid, cn, sn, mail, orclisEnabled, orclActiveStartDate, orclActiveEndDate, and orclGUID — that the package exchanges with the directory. Package globals such as G_SUCCESS, G_FAILURE, G_TRUE, and G_FALSE normalize return codes across the API surface, while constant strings such as G_COM_PROD_ORCLECTX and G_DEFAULT_BASE anchor LDAP distinguished-name paths under cn=Products,cn=OracleContext.

Key Procedures and Functions

The documented API comprises fourteen procedures and functions. Session and connection management are handled by GET_OID_SESSION and its cached variant C_GET_OID_SESSION, which obtain and reuse a bound LDAP session, and by UNBIND and C_UNBIND, which release that session. GET_ORCLAPPNAME — the member surfaced in the user's search — resolves the Oracle application name associated with an LDAP identity, allowing EBS to reconcile a directory entry with the corresponding application context. Identity lookup is supported by GET_DN_FOR_GUID and GET_GUID_FOR_DN, which translate in either direction between a distinguished name and the directory's globally unique identifier, providing a stable key independent of renames or directory reorganizations. PROXY_AS_USER enables operations to be executed in the security context of a specified user, which is essential for provisioning and delegated administration. GET_DAS_OPERATIONURL retrieves the directory operation URL from the DAS configuration subtree defined by G_DEFAULT_BASE. Attribute-level work is performed by ADD_ATTRIBUTE_M and GETLDAPATTRIBUTE, which respectively add or modify attributes and retrieve attribute values for a directory record. LOADLDAPRECORD populates the ldap_user_type structure from directory data, serving as the bridge between raw LDAP responses and the attribute-oriented model used throughout the package.

Tables Accessed

The package references FND_USER through its APPS synonym to reconcile directory identities with EBS application user accounts, principally when resolving application names and validating that a directory entry corresponds to a provisioned user. DBMS_LDAP is the Oracle-supplied PL/SQL LDAP client package that performs the actual network protocol operations — binding, searching, comparing, adding, and modifying entries — and is the substrate on which all of the FND_LDAP_UTIL session and attribute procedures depend. DBMS_UTILITY provides supporting PL/SQL utilities used during processing. Because the package operates against an external directory, most of its data manipulation occurs outside the EBS schema; FND_USER is the primary local table involved.

Usage Notes

FND_LDAP_UTIL is an internal utility package rather than an end-user-facing API. It is invoked indirectly by higher-level EBS components that support OID integration, including the sign-on and user-management flows configured through the Oracle E-Business Suite LDAP integration profile options (such as the host, port, username, and dbldapauthlevel settings referenced by the package constants). The package is reported as referenced by four other packages, which is consistent with its role as a shared foundation consumed by authentication, synchronization, and provisioning modules rather than called directly from forms. Custom code should treat the documented procedures as the supported entry points and should not rely on internal globals or the record layout beyond their declared purpose. Because the LDAP_SYNCH and DBLDAPAUTHLEVEL settings govern behavior, any use of GET_ORCLAPPNAME or the GUID lookup routines in a custom extension must be validated against the site's directory configuration and the level of LDAP integration enabled.