4 Understanding Mixed Deployments
Note:
To use the virtual directory capabilities described here, you must have a valid Oracle Directory Service Plus license.
4.1 Considerations For Mixed Deployment Scenarios
It is essential that you understand the design considerations and deployment options while designing mixed deployment scenarios.
This section lists those considerations, and contains the following topics:
4.1.1 Understanding Installation of Oracle Unified Directory as a Directory Server
This section is intended to help you understand the considerations to bear in mind when you install Oracle Unified Directory as a directory server.
You must keep the following points in mind while you install Oracle Unified Directory as a directory server using the oud-setup command:
-
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 Backends, 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.
4.1.2 Understanding Installation of Oracle Unified Directory as a Proxy
If 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 understand the considerations while doing so.
You must keep the following points in mind:
-
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 either use pass-through authentication or 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 About the Virtual Access Control Instructions Syntax.
-
You can replicate Virtual ACIs back end.
4.2 Example of Pass-Through Authentication Configuration
Pass-through authentication is a strategy in which a directory server consults another to authenticate bind requests. This enables you to administer user and configuration information on separate instances of Directory Server.
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.
Note:
To use the virtual directory capabilities described here, you must have a valid Oracle Directory Service Plus license.
See Also:
-
Understanding Pass-Through Authentication for information about configuring pass-through authentication
-
Optimizing Search Results From a Virtual Directory for information about configuring pass-through authentication using a Join workflow element
Figure 4-1 Pass-Through Authentication Mechanism
4.3 Example of Shadow Joiner Configuration
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. See 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.
