Split profiles with AD and OID for Fusion Apps IDM

In this post I will walk you through on How to set up split profiles with AD and OID as backend directory server while Oracle Virtual Directory links them together to present a single consolidated view.

This is a very generic implementation scenario but is very important when setting up IDM for Fusion Applications, where clients would like to use their existing Enterprise Repository for the user base. Very common example is to provision users out of existing AD without replicating the user base to some other repository, that’s when split profile AD and OID comes into place, while OVD becomes the presenter of consolidated view.

Here are some of the FAQs:

1. Why do we need OID  for Fusion Applications when existing Enterprise Repository can be used ?
   a.       All the Fusion Applications specific and Oracle specific attributes are created in OID
2.  Can multiple directories still be used as Identity stores?
   a.       Yes. Multiple directories can still be used as Identity stores with oracle specific attributes present in OID and enterprise specific attributes and Fusion Application specific attributes present in say AD.I will discuss this scenario in upcoming blogs
3. A re User Login Ids unique across directories?
   a.       Yes , this a pre requisite and other pre requisites and limitations are very well discussed in IDM Enterprise Deployment Guide for Fusion Applications for configuration of directories other than OID
4. W hen is the good time to configure split directory mode, before or after FA provisioning?
   a.       I will stress this  and recommend to go with this configuration after FA provisioning is completed 
   b.      Since this can also be done prior to FA provisioning  , in that case the recommendation is to complete the IDM Environment with OVD and OID (ID Store,Policy Store) >>Validate IDM Environment >> Then proceed with split AD Configuration
   c.       Configuring AD and OID before IDM validation is prone to good number of user errors.
   
   
    
   For easy understanding and simple configuration I will stick to the scenario of split profile configuration where existing Enterprise Repository is not extended.In this scenario this is how the view is from OVD level (adapter plug-in view/ unified view).
   
   
   As you see in the image above even though the actual base of both OID and AD repositories are same ‘dc=us,dc=oracle,dc-com’ , OVD Adapters are configured to map uniquely and to consolidate to a unified view  of ‘dc=adidm,dc=oididm,dc=com’
   
   
   Now let’s get in to action on how to create above configuration. On a high level this can be split in to 5 tasks
   
   1. Setting up Shadow directory  in OID
   2. Create a shadow joiner
   3. Create user Adapters for AD and OID
   4. Create Changelog Adapters for AD and OID
   5. Create Join View Adapter and Global Change Log Plug-In
      
      
      
      
      
      
      
      

   1.Set up OID as shadow directory

   Since AD is not being extended, OID will be used as a shadow directory and use Oracle Virtual Directory to merge the entities from the directories and for this purpose we need to create a container in OID to store Fusion Apps specific attributes
   
   
   a. Create 'shadowentries' container in oid ( below is sample ShadowADContainer.ldif)
   
   dn: cn=shadowentries
   cn: shadowAD1
   objectclass: top
   objectclass: orclContainer
   
   
   b. Load the group with following command
   
   $ORACLE_HOME/bin/ldapadd -h <oid-host> -p <oid-port> -D cn=orcladmin -w <password> -c -v -f
   ShadowADContainer.ldif
   
   c. Create acis on the newly created group/container  to grant access to RealmAdministrators and OIMAdministrators(This is the group that does all ID Administration in OIM)
   
   dn: cn=shadowentries
   changetype: modify
   add: orclaci
   orclaci: access to entry by group="cn=RealmAdministrators,cn=groups,cn=OracleContext,dc=us,dc=oracle,dc=com" (browse,add,delete)
   orclaci: access to attr=(*) by group="cn=RealmAdministrators,cn=groups,cn=OracleContext,dc=us,dc=oracle,dc=com" (read,write,search,compare)
   orclaci: access to entry by group="cn=OIMAdministrators,cn=groups,dc=us,dc=oracle,dc=com" (browse,add,delete)
   orclaci: access to attr=(*) by group="cn=OIMAdministrators,cn=groups,dc=us,dc=oracle,dc=com" (search,read,compare,write)
   -
   changetype: modify
   add: orclentrylevelaci
   orclentrylevelaci: access to entry by * (browse,noadd,nodelete)
   orclentrylevelaci: access to attr=(*) by * (read,search,nowrite,nocompare)
   
   
   d. An image of how the shadow container looks after creation.
   
   
   
   
   
   
   
   
   

    Note: All the steps here after are to be performed by connecting to OVD via ODSM.You can use the screen shots as pointers for configuration.

    

   
   

   2.Create Shadow Joiner Adapter

   Shadow Joiner User Adapter settings 
   
   
   
   
   
   
   
   
   
   
   
    
   
   

   3.Create User Adapters for AD and OID

   you would need to create a User Adapter for AD and OID.Use these screen-shots as pointers
   
   
   3.1 User Adapter for AD
     
   
   
   
   
   
   
             AD User Adapter Parameters
   
   
   
   
   
   3.2   User Adapter for OID
   
   
   
   
   
   
   
   
   
   
         OID User Adapter Parameters
   
   
   
   
   

   4.Create Change Log Adapters for AD and OID

     4.1 Change Log Adapter for AD
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   4.2 Change Log Adapter for OID
   
   
   
   
   
   
   
   
   
   
   
   
   
   

   5.Create a Join View Adapter and Global Change Log Plug-in

   5.1 Join View Adapter Settings
   
   
   
   
   
   
   
    5.2 Global Change Log Plug-in
   
   
   
   
   
   
   
   Finally this is how the summary of all the OVD Adapters is shown in HOME tab for OVD in ODSM
   
   
   
   
   
   Next Steps ? 
   Now that split profile is configured, what are the settings that need to change in OAM and OIM , I will discuss that in next blog.