There are scenarios where it is convenient to deploy the proxy functionality and the Directory Server functionality in a single server instance. This chapter describes the supported scenarios and the limitations of such deployments.
This section contains the following topics:
You need to bear in mind some points while designing mixed deployment scenarios. This section lists those considerations, and contains the following topics:
When you install Oracle Unified Directory as a directory server using
oud-setup command, you need to keep in mind the following points:
You can only use Local Backends, Kerberos, EUS, and Pass-Through Authentication workflow elements.
Virtual ACIs are not supported.
You can use all the advanced features of the Local Backend, such as password policy, group, collective attributes, virtual attributes, privileges, referential integrity, password storage, seven bit, and so on.
You can use replication for Local Backends workflow element.
When you install Oracle Unified Directory as a proxy server, then you can achieve pass-through authentication or Join features using the workflow elements associated with them. However, you need to keep in mind the following points:
You can use all the non-local workflow elements, such as LDAP Proxy, Join, Renaming, Transformation, RDN changing, AD paging, Distribution, and Load Balancing.
You can use pass-through authentication and EUS.
You can use Local Backends as Join Participant.
The advanced features of the Local Backends is not supported.
You can use replication for a Local Backends workflow element.
ACIs defined for Local Backends workflow element are not compatibles with DN mapping at Join or pass-through authentication level, therefore you must use virtual ACIs.
You can use virtual ACIs, but bind rules can only use bind DN. For more information about bind rules, see Section 9.7.2, "Virtual ACI Syntax."
You can replicate Virtual ACIs backend.
You use pass-through authentication mechanism when the client attempts to bind to the directory server and the user credentials for authenticating are not stored locally, but instead in another remote directory server known as the authentication (Auth) server. This in turn implies, that when the user tries to authenticate, the BIND request is forwarded to the remote LDAP server, but other operations are handled locally by directory server. Such a deployment is called pass-through authentication. Figure 4-1 depicts the pass-through authentication mechanism.
The user password is stored in a remote LDAP server, but all the other attributes of the user entry are stored in locally in Oracle Unified Directory.
For more information about configuring pass-through authentication, see Section 12.7, "Understanding Pass-Through Authentication."
You can also configure pass-through authentication using Join workflow element. For more information, see Section 14.14, "Implementing Pass-Through Authentication Using Join Workflow Element."
The Shadow Joiner allows you to store entries in a source such as an LDAP or Database stores that requires a schema extension for the remote data store, but the schema extension is not possible either for business or technical reasons. The Shadow joiner allows you to store the extended attributes in another store, known as the shadow directory such as the Local Backend workflow element. For more information about Shadow Joiner, see Section 14.6.4, "Shadow Joiner Type."
Figure 4-2 illustrates a Shadow join configuration. The remote workflow element contains the user entry, whereas the Local Backend contains locality and description attribute and Join with remote server.