Virtual Directory Use Case: Entry aggregation from 2 sources
Let's keep track of the common virtual directory configuration below people ask me every week or so:
Use case description:
Sun Directory Proxy configuration:
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
dpconf add-virtual-transformation JOIN
mapping attr-value-mapping dn view-value:uid=${uid} internal-value:cn={$uid}
(quotes may be needed depending on the command interpreter you are using)
For more details, refer to the proxy documentation.
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
dpconf add-virtual-transformation
(quotes may be needed depending on the command interpreter you are using)
For more details, refer to the proxy documentation.
