Thursday Apr 18, 2013

Oracle Virtual Desktop Infrastructure and Unified Directory

Oracle Virtual Desktop Infrastructure offers a complete solution for managing and providing access to virtualized desktop environments hosted in the datacenter.  Oracle Virtual Desktop Instrastructure enables organizations to simplify administration, reduce operating costs, increase the utilization of existing IT assets, and boost security by moving from a tradtional desktop environment to a virtual desktop architecture.

Typically, you configure Oracle VDI to use the information held in a corporate user directory, like Oracle Unified Directory Server.

You can use the OUD setup or the ODSM to create a suffix holding users, eg,  ou=People,dc=oscr,dc=uk,dc=oracle,dc=com using existing schema.
Then create a few user entries with the fields User Name, First Name, Last Name, User ID and User Password.  So for my account it is

User Name : Sylvain Duloutre
First Name : Sylvain
Last Name : Duloutre
User ID : sduloutr
User Password : ****

To install Virtual Desktop Infrastructure, follow the install guide, then connect to the VDI Web UI using your preferred browser. Here is a screenshot showing the setup of the VDI server :

Next are 2 screenshots showing the LDAP settings and how they map to VDI:

As you can see there isn't actually a lot of configuration to do.  You  can now login to VDI from a Sunray or from the Oracle Virtual Desktop Client using the login name and password stored in OUD.

Thanks to Rob for VDI snapshots and testing.

Monday Jan 26, 2009

Forum about LDAP, Sun Directory, Proxy Server and Virtual Directory

If you have some questions about Sun Directory Server Edition, Directory Proxy and Virtual Directory or you want to share best practices, don't hesitate to use the Sun Developer Forum dedicated to these products.

See you there!

Friday Jan 23, 2009

Fail-over based on the directory server operational state

DPS 6.x load-balancing / fail-over can be configured to stop sending traffic to a specific directory server instance in maintenance, even when that instance is up and running. For instance, you may want to remove a directory server instance from the mesh while an import or re index is in progress.

DPS 6.x periodically checks each ds server for availability by issuing (amongst others) a search request. A directory server instance is considered unreachable when that search fails or does not return any entry. By default, the search request hits the rootDSE entry. It can be configured to hit an entry in cn=config or cn=monitor to take into account the directory server operation state.

For more info, look at dpconf properties monitoring-search-filter and monitoring-entry-dn in the ldap data source object.

Friday Dec 19, 2008

DIT changes with dn virtual transformations

Here is a summary of a common deployment scenario with Sun Directory Proxy Server:

LDAP entries are grouped by location in the DIT, e.g user entries are located under ou=north,ou=people,dc=company, dc=com or  ou=south,ou=people,dc=company, dc=com or ou=east,ou=people,dc=company, dc=com or ou=west,ou=people,dc=company, dc=com based on user physical location.

Later, for sake of simplicity, the DIT is flatten so that every user entry is stored immediatly under ou=people, dc=company, dc=com

New applications are aware of the DIT structure change but DPS is used so that legacy applications expecting the location container node can operate w/o problem.

The dn mapping needed can be achieved by using virtual data transformations as described  in

Let's assume that
- you have a data view DV1 with viewBase (suffix) set to dc=company,dc=com.
- entry location (north, east,...) is always available in each entry in attribute 'location'
- entry uid=\*,ou=(north|south|east|west),ou=people,dc=company,dc=com mapped to uid=\*,ou=people,dc=company,dc=com

You have to create a virtual data transformation on the 'dn' for data view DV1. For inbound traffic (requests), the proxy must get rid of the ou=(north|south|east|west) node. For outbound traffic (responses), the proxy gerenates a (fake) ou=(north|south|east|west)  from the content of the 'location' attribute of each entry.

Here is the dpconf command to do that:

dpconf add-virtual-transformation -h <host> -p <port> -d <proxy manager> DV1 mapping attr-value-mapping dn internal-value:uid=\\${uid},ou=people view-value:uid=\\${uid},ou=\\${location},ou=people

Note: you might have to escape some characters (e.g $) in the command below depending on the command interpreter you are using. In the example above, I used \\$ instead of plain $.
Note2: dn patterns used in virtual transformations must not contain the data view viewBase (dc=company,dc=com in this case) as it is implicit.

Friday Jul 25, 2008

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:
  • User entries stored in a LDAP directory server, e.g uid=sylvain, ou=people,
  • 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,

Sun Directory Proxy configuration:
  • Create a LDAP data view, LDAP1, viewBase set to ou=people,, pointing to the LDAP data source
  • Create a LDAP data view, LDAP2, viewBase set to ou=people,, 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,, 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, 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, to cn=\*, ou=people, 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.

I am Sylvain Duloutre, I work as a Software Architect in the Oracle Directory Integration Team, the customer-facing part of Directory Services & Identity Management Product Development, working on Technical Field Enablement.

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.


« April 2014