By Sylvain Duloutre on Jul 25, 2008
Use case description:
- User entries stored in a LDAP directory server, e.g uid=sylvain, ou=people, o=sun.com
- Additional user attributes stored in Active Directory. Corresponding entry is cn=sylvain, cn=users,dc=sun, dc=com
- user credentials identical on both sides (same password)
- Aggregated entries containing the merge of LDAP and AD available as uid=sylvain, ou=people, o=sun.com
Sun Directory Proxy configuration:
- Create a LDAP data view, LDAP1, viewBase set to ou=people,o=sun.com, pointing to the LDAP data source
- Create a LDAP data view, LDAP2, viewBase set to ou=people,o=sun.com, dataSourceBase set to cn=users,dc=sun,dc=com, pointing to the AD server
- Create a Join data view, JOIN, viewBase set to ou=people,o=sun.com, primary view set to LDAP1, secondary data view set to LDAP2
- Make sure to mark LDAP1 and LDAP2 as non 'routable' so that the join data view providing aggregated view only can be exposed to the proxy clients. Otherwise, a search to ou=people,o=sun.com may be routed to the 3 data views, leading to duplicate entries to be returned.
With the configuration above, the proxy automatically rewrites DNs when appropriate. However the proxy would bind as uid=sylvain,cn=users,dc=sun,dc=com when it needs to contact the AD source. The naming attribute is wrong, so a dn transformation needs to be configured on the LDAP2 data view to map dns like uid=\*,ou=people,o=sun.com to cn=\*, ou=people,o=sun.com. Mapping of the static portion of the dn is done automatically.
To create the dn transformation, use
(quotes may be needed depending on the command interpreter you are using)
For more details, refer to the proxy documentation.