Mass Reset Password -part2 – using OIM Apis

Introduction Back in November, I wrote a blog about Mass Rest Password using OID. As mentioned there, and expected for this month, Oracle is now providing the same password change feature, but now using Java OIM API. Main Article In this case, for develoment and test environments customers usually want something that they can control […]

Mass Reset Password-part1 OID

Introduction One of the great features that customers need to be aware of and it could be used, as post-process, on many different situations such as: P2T, T2P and clone is the ability to reset multiple passwords simultaneously. Imagine the customer is scaling out their environment because they need an additional UAT environment. This customer […]

Resetting Environments – An Alternate Approach

Overview There are times when you are in the midst of testing where you need to reset things back to the way they were; to be able to quickly restart your testing at from a previous point. This is technologically quite easy with current storage infrastructures supporting snapshot mechanisms. This is equally easy in those […]

IDM FA Integration flows

Introduction One of the key aspects of Fusion Applications operations is the Users and Roles management. Fusion Applications uses the Oracle Identity management for its Identity store and policy store by default.This article explains how user and roles flows work from different poin of views, using ‘key’ IDM products for each flow in detail. With […]

Index of Platform Security articles

Index of IDM Governance articles

Index of IDM Directory Services articles

Index of Access Management articles

OAM and OIM Config changes for Split Profile ( Split Profile Configuration -Part 2)

In my previous post i have discussed split profile set up scenario with AD and OID in Fusion Applications IDM Environment and how to create Adapters in OVD  for consolidating the two directory servers AD and OID.Adapters configuration alone is not…

Super User/Role setup for Common Implementation of Fusion Apps

 
Hello Everyone!
This post is about preparing the installed IDM/FA for Common implementation of Fusion Applications (FA).  

 

Please note that this procedure needs to be done for BARE METAL Installation. However for OVM template based installation it has been observed that these steps have been already done as a part of installation. My suggestion for OVM would be to validate these steps and complete any/all of the step(s) as needed.

 

After the installation of FA, an organization starts the common implementation that involves a  series of tasks shown below. 
 

 

This blog is limited to explaining the first 2 tasks in the above diagram. Kindly refer to Getting Started with Fusion Applications : Common Implementation document for  further details.

A little background on why we are doing this.
In Fusion Applications, users along with security are managed by HCM Task flows which require Enterprise structures to be setup.  For setting up these Enterprise structures we need to create specific users in HCM. Initially since there will not be any Enterprise structures, we need to have a Super User who can create appropriate implementation users.

The implementation user created by the super user in turn will be responsible for providing
  1. Users and their Security Management.
  2. Implementation Project Management.
  3. Enterprise Structure creation and management.

As part of our post IDM/FA install, we have to complete  the following two tasks using the OIM system administrator.

  1. Preparing Oracle Fusion Applications Super User for User Management and Configuration

     

  2. Preparing IT Security Manager Role for User and Role Management

     

 Requirements

 

 Before we begin we have to  make sure the following.

  1. FA install is successfully completed. Any RUP install are done and successfully completed.

 

  • URLs for Oracle FA and OIM are available.

 

 

  • OIM system administrator user and Super User (FAAdmin or weblogic_fa or user defined) credentials.

 

Preparing Oracle Fusion Applications Super User for User Management and Configuration
During the provisioning and installation of Oracle Fusion Application a super user is created by default (FAAdmin or weblogi_fa  etc as provided during the installation). However the email id for this super user may  not be setup correctly during the provisioning and installation. The first task is to make sure the super user has a valid email id as it is mandatory for  User management and configuration.  This could be done in couple of ways

a)      Command Line (Linux)   

Command Line Interface

  1. Open a new Terminal.

     

  2. Using Vi editor or gedit,  create an ldif file with the following contents (sample.ldif).  I had stored this file along with other property file in the following directory /u01/fastage/prop_files

     

dn: cn=weblogic_fa, cn=users, dc=mycompany, dc=com

 

changetype: modify

 

replace: mail

 

mail: valid e-mail_address
Note that the super user in this case is “weblogic_fa”.
  1. In the Oracle Identity management domain (IDM), set  the Oracle Home to point to IDM.
$> export MW_HOME=/u01/app/oracle/product/fmw 
$>export ORACLE_HOME=$MW_HOME/idm
  1. Run the ldapmodify command to modify the super user (in this case weblogic_fa) email id.
            $> $ORACLE_HOME/bin/ldapmodify -h idstore.mycompany.com -p 389
-D cn=orcladmin  -w Welcome1  -f $HOME/prop_files/superuseremail.ldif
 Note we use the OIM administrator “orcladmin” to effect the email changes to the super user “weblogic_fa”.
  1. Make sure that the command is run without any errors.

 

  • Run the Reconciliation detailed below (after the GUI Interface for ODSM section)

 

  1. Log into ODSM using OIM administrator (xelsysadmn).
 
  1. Click on “connect to directory” and select OID – OID-SSL  and log in as administrator (cn=orcladmin)
 
  1. Select Data Browser TAB and expand DN “dc=com” which provides the details of the users.
 
  1. Navigate and select the super user “weblogc_fa”.  On the right side pane, you can edit/change the email address.
 
  1. Press APPLY to effect the changes.

Reconciliation

Run the reconciliation to synch LDAP with  OIM.

6.      Launch the OIM URL and use the OIM system administrator user name and password to sign in.
7.       Click the Advanced link in the upper right of the interface.

 

            a.        Click Search Scheduled Jobs in the System Management tasks. 

             b.       Enter LDAP User Create and Update Full Reconciliation in the Search Scheduled Jobs field.  

 

 
               c.        Select the job in the search results.
 
    1. Click Run Now to reconcile user updates based on the change log from LDAP.  Scroll down to make sure that the job has run successfully.
 
 
The super user created during the installation and provisioning can implement the Oracle Fusion application and administer security. However it does not have roles to create and manage Oracle Fusion Application users. Hence for the IT Security Manager role we add the following OIM roles.
  • Identity User Administrators, which carries user management entitlement

 

  • Role Administrators, which carries role management entitlement

 

Note: If you plan to implement your pilot project entirely while signed in as the super user and do not plan to create additional users, then you can skip this step. In reality there would be multiple Fusion Application Users created for various transactions and you are most likely need to perform this step.

 

  1. Sign in to OIM. Launch the OIM URL and use the OIM system administrator user name and password to sign in.
 
2.       Click on Administration in the upper right of the interface

                                a.   Search for the IT Security Manager role, and select the role name in the search results.

                               b.       From the Hierarchy tab, click on Inherits From.

                               c.        Click on Add.

                               d.       Select the role category: OIM  Roles and click the find arrow.

                                e.      Select IDENTITY USER ADMINISTRATORS & ROLE ADMINISTRATORS (ctrl + click) and move them to the Add Role list.

 

 
 
                         f.        Click Save. This enables the IT Security Manager with both the roles (Identity user Administrator & Role Administrators) to IT Security Manger.

3.       ALTERNATE for the above task # 2). You may just add SYSTEMADMINISTRATORS role which Inherits from both the roles Identity user Administrator & Role Administrators)  to IT SECURITY MANAGER role

 

 
4.       Return to the Welcome to Identity Manager Delegated Administration page,    

  • In the search pane, enter  Xellerate Users in the search field
  • Select organization on the left drop down box and hit search arrow
  • Select the organization name in the search results. The left pane should now display the corresponding details of Xellerate Users.

                           a.        Click the Administrative Roles link in the row of links above the Xellerate Users page.

b.       In the POPUP window Click ASSIGN

                                      c.        In the Filter By Role Name field of the Details window, enter *IT_SECURITY_MANAGER*

                                      d.       Click Find.

                                      e.        Enable Read, Write, Delete, and Assign.

                            f.        Click Assign and Confirm.

 

 
  1. Close the window and sign out.
This concludes this post on preparing the IDM/FA installed environment for Common Implementation of Fusion Applications.

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. Are 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. When 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.

Setting up HTTPS on OHS for Fusion Apps

Hello and Welcome to Everyone!I’ve been selected to write the inaugural post for the team’s blog, and the topic I’ve chosen is one that I’ve had to help a couple of clients with in the past couple of weeks: How to replace the default SSL certificates f…

Tips and Tricks When Upgrading IDM for Fusion Applications – RUP1 through RUP3

In this article, I want to share some lessons learned from doing the IDM portion of the FA upgrade. Overall, the process of upgrading the security components is straightforward if you follow the instructions carefully, but there’s no denying that the IDM part of the upgrade is a little more hands-on and potentially confusing that the FA part.

A Note About Versions

When you start reading the documentation below, you may notice like I did that the naming convention for the upgrades is changing — up to now, the upgrades have been referred to RUP1, RUP2, etc., but the documentation no longer reflects that:
Version              Old Name                   New Name
11.1.2.0.0          FA 11gR1 RUP1         FA 11gR1 Update 1
11.1.3.0.0          FA 11gR1 RUP2         FA 11gR1 Update 2
11.1.4.0.0          FA 11gR1 RUP3         FA 11gR1 Update 3

You will see references to both naming conventions, so you should keep both in mind when searching in My Oracle Support or in your favorite search engine for information.
Important Note: These are incremental and not cumulative patches. You will need to apply RUP1 before you can apply RUP2, and the same goes for RUP3 (RUP1 and RUP2 need to be applied first).

The Documentation

Starting with RUP2/Update 2, the documentation you need to upgrade consists of three separate docs:

For RUP1/Update 1:
Release Notes: MOS Document 1382781.1
Patching Guide: http://docs.oracle.com/cd/E25054_01/fusionapps.1111/e16602/toc.htm

For RUP2/Update 2:
Release Notes: MOS Document 1439014.1
Patching Guide: http://docs.oracle.com/cd/E25178_01/fusionapps.1111/e16602/toc.htm
IDM Upgrade Procedure: MOS Document 1435333.1

For RUP3/Update 3:
Release Notes: MOS Document 1455116.1
Patching Guide: http://docs.oracle.com/cd/E28271_01/fusionapps.1111/e16602/toc.htm
IDM Upgrade Procedure: MOS Document 1441704.1

You should always start with the release notes before looking at the patching guide. The IDM upgrade procedure is a complement to the patching guide — while following the patching guide for the upgrade you’re performing, it will refer you to the IDM upgrade doc, which will then refer you back to the patching guide to continue.
Important Note: These docs have all been updated over time — make sure you check online before starting your upgrade to make sure that you have the most recent version!

Upgrading IDM from RUP1/Update 1 to RUP2/Update 2

Most of this consists of patching, but there are a couple of major changes on the IDM side, namely, the upgrade of the IDM Suite to 11.1.1.6.0 from 11.1.1.5.0 which in turn requires the upgrade of WLS in the IDM domain to 10.3.6.

Things You Should Do Before You Start the Upgrade

As of the time I’m publishing this, the RUP2 binaries on eDelivery come with the wrong copy of the IDM Suite installer (version 11.1.1.5.0 instead of the required 11.1.1.6.0). This means you will need to separately download the correct version from eDelivery. Once you have everything downloaded and ready to go, it’s worth going through the binaries to identify where the IDM-specific patches are so you don’t have to search for them later. In my case, everything was unpacked to “/u01/backup/rup2” on the machine where I first tried this:

Patch                Location
13797139        /u01/backup/rup2/installers/oracle_common/patch/13797139
13642895        /u01/backup/rup2/installers/oracle_common/patch/13642895
13686287        /u01/backup/rup2/installers/oracle_common/patch/13686287
13579026        /u01/backup/rup2/installers/oracle_common/patch/13579026
13782459        /u01/backup/rup2/installers/pltsec/patch/13782459
13620505        /u01/backup/rup2/installers/pltsec/patch/13620505
13399365        /u01/backup/rup2/installers/iam_patches/13399365
13115859        /u01/backup/rup2/installers/iam_patches/13115859
13684834        /u01/backup/rup2/installers/iam_patches/13684834
13477091        /u01/backup/rup2/installers/webgate/ext

Note that the last patch (13477091) is an OAM 10g patch for WebGate and is not applied with OPatch but run as a standalone executable.
In a similar vein, the doc references some common paths, and the example paths in the doc do not reflect the paths that are specified in the Enterprise Deployment Guide. I went through the paths on one of my lab servers which does follow the EDG:

IDM_ORACLE_HOME                             /u01/app/oracle/product/fmw/idm
OID_ORACLE_HOME                             /u01/app/oracle/product/fmw/idm
IDM_ORACLE_COMMON_HOME        /u01/app/oracle/product/fmw/oracle_common
IAM_ORACLE_HOME                            /u01/app/oracle/product/fmw/iam
OIM_ORACLE_HOME                            /u01/app/oracle/product/fmw/iam
IAM_ORACLE_COMMON_HOME       /u01/app/oracle/product/fmw/oracle_common
SOA_ORACLE_HOME                           /u01/app/oracle/product/fmw/soa
OHS_ORACLE_HOME                           /u01/app/oracle/product/fmw/web
WEB_ORACLE_HOME                          /u01/app/oracle/product/fmw/web
OHS_WEBGATE_ORACLE_HOME      /u01/app/oracle/product/fmw/oam/webgate
OHS_ORACLE_COMMON_HOME      /u01/app/oracle/product/fmw/oracle_common

Again, this is an exercise worth doing before you begin to make the upgrade steps go a little more quickly.

Following the Upgrade Doc

The upgrade doc divides the tasks into 13 steps, and I will highlight some specific comments below for the steps where I encountered an issue or where I felt that some clarification was warranted. For example, there are four patches (13797139, 13642895, 13686287 and 13579026) that you are instructed to apply in Step 6 and then again in Steps 7 and 8 and this made no sense at first. On a closer read, however, it became clear that the doc was covering a very generic deployment where the IDM Suite, the IAM Suite and the Web Tier were on separate WebLogic domains. And that’s not the case for FA installations that follow the EDG. So you really only need to apply the four patches in Step 7 because the WLS-based security components are all in one domain.

Step 4: Create Backups

Do not neglect this step! Upgrading FA is a large and complex effort.

Step 5: Download Required Patches

This step was a bit of a puzzle for me, because it belongs in the “Before Upgrading” section before Step 1. Besides, with the exception of the IDM Suite 11.1.1.6.0, everything else is included in the RUP2 binaries that you download from eDelivery.

Step 6: Upgrade the IDM Node

There should be no drama in this section, but remember from above that you can wait until Step 7 to apply those four patches. If you don’t, you will need to roll back and reapply those patches in the next step.

 Step 7: Upgrade the IAM Node

Remember that if you followed the EDG, the IDM and IAM nodes are one and the same and you have already upgraded WLS (and don’t need to do it again).

Apply Oracle Identity Manager patch 13399365

There are two things that happened to me when I tried this the first time. The first thing was an error from OPatch saying that this patch conflicts with patch 12961473. Turns out that this is a known issue and the fix is to simply roll back patch 13399365 and then reapply it. The second thing was deploying the new weblogic.profile file. There were some unfamiliar parameters that needed to be given values, and to save you some time, here is a copy of what it should look like for FA:

# For passwords if you dont want to put password </optional> in this file just comment it out from here, you will be promted for it in rumtime.
#Neccessary env variables [Mandatory]
ant_home=/u01/app/oracle/product/fmw/modules/org.apache.ant_1.7.1
java_home=/u01/app/oracle/product/fmw/jrockit-jdk1.6.0_24
mw_home=/u01/app/oracle/product/fmw
oim_oracle_home=/u01/app/oracle/product/fmw/iam
#DB configuration variables [Mandatory]
operationsDB.user=FA_OIM
# Database password is optional. if you want to  give it on terminal itself leave it commented. Otherwise uncomment it.
OIM.DBPassword=Welcome1
operationsDB.driver=oracle.jdbc.OracleDriver
operationsDB.host=idmdbhost.mycompany.com
operationsDB.serviceName=oimedg.mycompany.com
operationsDB.port=1521
appserver.type=wls
isMTEnabled=false
# If you have milty-tenancy enabled in your environment
mdsDB.user=<MDS DB Schema owner>
#Password is optional,  if you want to  give it on terminal itself leave it commented. Otherwise uncomment it.
#mdsDB.password=<MDS DB Schema password>
mdsDB.host=<MDS DB Host>
mdsDB.port=<MDS DB port>
mdsDB.serviceName=<MDS DB ServiceName>
#For domain level configurations [Mandatory]
# put here your admin server related credentials
weblogic_user=weblogic
#Password is optional,  if you want to  give it on terminal itself leave it commented. Otherwise uncomment it.
weblogic_password=Welcome1
weblogic_host=servername
weblogic_port=7001
weblogic.server.dir=/u01/app/oracle/product/fmw/wlserver_10.3
#oim specific domain level parameters [Mandatory]
oimserver_host=servername
oimserver_port=14000
oim_managed_server=wls_oim1
oim_domain_dir=/u01/app/oracle/admin/IDMDomain/aserver/IDMDomain
isSODEnabled=false
#SOA specific details [Mandatory]
soa_home=/u01/app/oracle/product/fmw/soa
soa_managed_server=wls_soa1
soaserver_host=servername
soaserver_port=8001
#put here the name of the targets of taskdetails. in non cluster it will be soa server name and in cluster it will be something like cluster_soa
taskdetails_target_name=cluster_soa
isOHSEnabled=false
#Following params is needed only if you have enabled OHS in your env
ohs_home=/u01/app/oracle/product/fmw/web
#If your env is FA, you can set this var false or ignore this if your env is non FA.
isFAEnabled=true

The patch_weblogic.sh script is in the same directory as weblogic.profile. You may see an error in the last step that it runs, and this seems to be due to the fact that the script tries to deploy SOA stuff before the server is fully up. This is another known bug, and the easiest fix is to check for undeployed apps in the WebLogic console and manually deploy them.

Upgrading IDM from RUP2/Update 2 to RUP3/Update 3

Most of this consists of patching, but there are a couple of changes on the IDM side, namely, the upgrade of the WebGates to 11g from 10g. The other thing (and it’s not quite spelled out in the doc) is that the FA database is upgraded to 11.2.0.3, and while this is mandatory for the FA DB it is optional for the IDM DB. For that reason alone, if you are going to upgrade the IDM DB as well, I recommend that you wait until the overall upgrade is complete and smoke tested before doing it.

Things You Should Do Before You Start the Upgrade

Once again, you should map the homes as above to have those paths handy, and locate the patches in the RUP3 binaries before rather than during the upgrade:

Patch 12575078, which contains Oracle Access Manager WebGates (11.1.1.5.0)
 /u01/rup3/installers/webgate/Disk1
Patch 13453929 for Oracle Access Manager WebGates
 /u01/rup3/installers/webgate/patch/13453929
Patch 13735036 for Oracle Identity Manager
 /u01/rup3/installers/idm/patch/13735036
Patch 13768278 for IDM Tools. Note: Be sure you download the 11.1.1.5.0 version of this
patch, which is named p13768278_111150_Generic.zip.
 /u01/rup3/installers/idm/patch/13768278
Patch 13787495 for Oracle Access Manager Config Tool
 /u01/rup3/installers/oracle_common/patch/13787495
Patch 13879999 for Oracle Internet Directory
 /u01/rup3/installers/pltsec/patch/13879999
Patch 13893692 for Oracle SOA Manager
 /u01/rup3/installers/oracle_common/patch/13893692 < for ORACLE_COMMON_HOME
 /u01/rup3/installers/soa/patch/13893692 < for SOA_HOME
Patch 13901417 for Oracle Access Manager
 /u01/rup3/installers/idm/patch/13901417

Important Note: Patch 13893692 has two parts that are applied separately, and the two parts live in different directories.
Finally, when you install the 11g WebGate(s), you will need a couple of specific gcc libraries present, and for me, my server had the 32 bit versions but not the required 64 bit versions. You can build these from scratch by downloading the source from GNU, but if you’re like me and in a hurry sometimes, you can just get them via yum:

 yum update libgcc
 mkdir /u01/app/oracle/product/fmw/gcc_lib
 cd /u01/app/oracle/product/fmw/gcc_lib
 ln -s /lib64/libgcc_s-4.1.2-20080825.so.1 ./libgcc_s.so.1
 ln -s /usr/lib64/libstdc++.6.0.8 ./libstdc++.so.6

You will need this in Step 9.

Following the Upgrade Doc

Same applies here as above — there are 14 steps in this doc with a special section that applies to Solaris.

Step 8: Upgrade the IAM Node

When you apply patch 13893692, you will get a message stating that it is already present. Just to be safe, I did a roll back and reapplication of it.

Step 9: Upgrade the OHS Node

This is where you need those gcc libraries — from the installer, specify the path that contains the symbolic links above (/u01/app/oracle/product/fmw/gcc_lib for me) for the location of the gcc libraries. The file names have to match those above.
In the new httpd.conf file, you may need to add the following lines to ensure that all logins work as they previously did:
You may need to add one line to httpd.conf to ensure that login works correctly:

 #*******Default Login page alias***
 Alias /oamsso “/u01/app/oracle/product/fmw/oam/webgate/access/oamsso”

Coda

So that’s it. If you’re careful and methodical, you shouldn’t encounter any issues for the IDM part of the upgrade. The two upgrade docs, while a bit confusing in some respects, are complete and should work for you. If anybody has their own experiences to share, please do.

Validating an Oracle IDM Environment (including a Fusion Apps build out)

In this post I walk you through how to validate an Oracle Identity Management build out containing OID, OVD, OIM, and OAM. This post was motivated by work I have done with Fusion Apps.

It is important to validate the IDM build out for Fusion Apps before you move on to the provisioning of Fusion Apps itself. Problems detected during the IDM build out are much easier to diagnose and fix than problems detected during FA provisioning, FA functional setup or FA operations themselves.

In addition, it is important to have documented validation steps for your Oracle IDM environment to use at other points as well. For instance, you will want to validate your IDM environment when you bring it back online following a backup.

Lastly, you will want to be able to go through validation steps for your IDM environment as a means of debugging IDM related application issues. For example, let’s say people come to you all of the sudden saying they can’t login to a Fusion HCM application. You’ll want to be able to go through the IDM validation steps to see what if anything is wrong with the IDM infrastructure that could be causing this issue.

Again, I wrote this with Fusion Apps in mind but everything here also applies to enterprise Oracle IDM build outs that use OID, OVD, OIM, and OAM. The only differences may be that for an enterprise deployment, the IDM services may be spread out across multiple WLS Domains and the system account being verified in the OID validation step may be different.

Recommended Validation Steps

The following are test cases for validating your IDM environment from bottom to top. We begin with just verifying that all services are running, move onto validating that the directory services are working, and then onto validating that OAM and OIM are working. We finish up with advanced but important tests that validate that SOA suite (the workflow provider for OIM) is working properly with OIM and that OAM/OIM integration is working.

These are descriptive test cases rather than fully documented click by click instructions. If you new to the Oracle IDM stack I encourage you to put in the time to flush this out into click by click instructions.

1) Verify all services are running. Login to IDM Domain admin server and ensure that all managed servers are up and running.
 
a. Go to environment –> Servers.

b. Make sure that the AdminServer and all 4 Managed Servers (OAM, OIM, SOA, and ODSM) are in Running state

2) Verify ODSM and OID. Go to ODSM connect to OID and verify that you can see all users and JPS root (for policy data).

a. Go to ODSM: http://idmost.mycompany.com:7777/odsm

b. Click on Connect to a directory and choose OID

c. Go to Data Browser and verify the following folders under Root:

idm_jpsroot: this folder should look like this:

 
dc=com –> dc=mycompany should look like this:

Make sure the following users are present:

Make sure the following groups are there:

f. For each one of the groups below, make sure user membership is as follows:

Groups
Members
cn=IDM Administrator
cn=weblogic_idm
cn=OAMAdministrators
cn=oamadmin
cn=OIMAdminstrators
cn=oimldap
cn=orclFAGroupReadPrivilegeGroup
cn=idrouser
cn=oamldap
cn=orclFAGroupWritePrivilegeGroup
cn=idrwuser
cn=orclFAOAMUserWritePrivilegeGroup
cn=oamldap
Cn=orclFAUserReadPrivilegeGroup
cn=idrouser
cn=oamldap
cn=orclFAUserWritePrefsPrivilegeGroup
cn=idrouser
cn=orclFAUserWritePrivilegeGroup
cn=idrwuser
cn=orclPolicyAndCredentialReadPrivilegeGroup
cn=policyrouser
cn=orclPolicyAndCredentialWritePrivilegeGroup
cn=policyrwuser
1)      3) Verify OVD 
a.       Go to ODSM and connect to OVD
 
b.      Go to Data Browser and verify that you can see the dc=mycompany, dc=com tree
 
c.      Verify that you can see change log data.  Verify ACL (security) during first validation, but this can be skipped on restart validation.
 
 
 
1)      4) Verify OID and OVD for LDAPS.  If doing LDAPS repeat steps 2 and 3 for LDAPS ports
 
 
1)      5) Verify OAM admin console 
a.       Go to OAM admin console and verify that login form is being served through “SSO” virtual host (sso.mycompany.com).  
b.      Verify that you can see policy data.   
c.       Sign out, you should see the login screen again.
1)      6) Verify OAM and EM
a.       Go to EM and verify that the login form is an OAM login form being served through the “SSO” virtual host (sso.mycompany.com).
b.       Verify that EM sees all the IDM services. 
 
 
c.       Logout.
 
 
1)      7) Verify OAM and OIM. 
a.       Go to OIM as xelsysadm and verify that the login form is the OAM login form being served through the “SSO” virtual host. 
 
b.      Verify that you can see all the users. 
                                                               i.      Go to Administration
                                                             ii.      On the left hand side perform a blank search for Users
                                                            iii.      Verify you can see the users from item #2 above
 
c.       Verify that you can see all the roles.
                                                               i.      On the left hand side perform a blank search for Users
                                                             ii.      Verify you can see the groups from item #2 above
 
1)      8) Verify OIM part 2. 
a.       Create user and a role in OIM
b.      Assign the user you created to the role you created
c.       Verify that it all shows up in OID
 
 
1)      9) Verify OIM part 3.

a.       Create user in OID and assign it to a group. 
b.      Login to OIM as xelsysadm and do reconciliation for both users and rolls. 
c.       Verify that you can login as that user into OIM, verify that the user shows up in OIM and that user has role that is mapped to group that you assigned user to in OID. 
 
 
 
1)      10) Verify OIM part 4.  Verify that SOA is working with OIM. 
 
a.       Login to OIM as xelsysadm, create another new role “test role 1”.  Logout. 
b.      Login as the test user you created, go to requests, create request, request for me, self assign role, then select “test role 1”.  Logout. 
c.       Login as xelsysadm and see that the request is awaiting your approval.  Approve the request.  You’ll have to do the approval twice.  The first approval is for the request and the 2nd approval is for the operation.
d.      Verify that the test user has been assigned the role they requested.
 
1)      11) Verify OAM/OIM integration and in particular OIM to OAM connectivity. 
a.       Create a new user in OIM and assign that user the IDM Administrator role. 
b.      Login to EM as that user.  You should be taken to OIM self service page to reset the user’s password and fill in forgotten password questions.  When that is complete you should be taken back to EM without having to login again.

Peripheral Responsibilities Required for Large IDM Build Outs (Including Fusion Apps)

Complexity and delay can occur during deployments of Oracle Identity and Access Management products (including the IDM build out for Fusion Apps) due to the fact that certain tasks required for the build out can sometimes only be performed by individuals that are not a part of the core team doing the deployment.

In many organizations IT responsibilities are very siloed. Some tasks during an IAM deployment may require assistance from individuals that operate in silos that are different from the team doing the deployment itself.

It is important to identify these tasks up front. When possible it is a good idea to make as many of these tasks as possible pre-requisites to the actual onsite installation/deployment. When that is not possible, then it is important to line up the assistance that will be required from role players who are outside of the core install/deployment project team to perform tasks that require their help.

The following are examples of such tasks:

Network

1. Provisioning of virtual hosts and VIPs.

2. Configuration of load balancers.

DB

1. Provisioning of DB including install, configuration, and creation of instances.

2. Running the RCU.

3. DB backups

Machine and Storage Provisioning

Provisioning shared storage and machines required for install. Provisioning of machines themselves including the installation and patching of OS. You’d think this would go without saying, but I’ve seen enough projects get delayed due to a lack of machines and storage that I feel I have to mention it.

Root Access

Root access is required during the creation of oraInventory and at several points during the web tier, OID, and OVD install. It is also required to do environment (file system) backups if backup is done as dictated by the EDG. One possible alternative is to do the backup as the install user and then separately backup the few files that are owned by root which do not change from the early stages of the install.

Certificates – PKI Administration

People often forget about the creation of certificates needed for SSL connections and web services security until they are actually needed. The trouble is that in many organizations, the team of people that create certificates for the organization is often small and the process by which certificates are requested and granted can take time. I recommend that when possible certificates be requested and created in advance.

When the request must come from a software component that is being installed as part of the deployment, it is still a good idea to talk to your PKI administrators in advance to make sure that the procedure for issuing the request is clear and to give them a heads up that you’d like the certificate issued as quickly as possible.

Fusion Security – Apps Edition

When we first started this blog more than 2 years ago, we debated about whether to name it “Fusion Security” or more specifically “Fusion Middleware Security”. We all work in the Fusion Middleware team on Fusion Middleware but even back then we saw Fusion Applications coming down the pipe and after all Fusion Apps is a set of big business applications whose principal distinction (in my opinion) is that it is the first set of business applications to be built on a truly modern middleware platform.

The much anticipated Fusion Applications was recently released. For those of you unfamiliar with Fusion Apps, it is composed of several families of applications (CRM, Financials, HR, Supply Chain, Procurement etc) that comprise the next generation version of Oracles Apps portfolio (PeopleSoft, E-Business Suite, Siebel etc.) and as I said it is built on top of most of the Fusion Middleware products that currently exist today.

Welcome Apps Community

I will start off by welcoming those in the Oracle Apps community to the Fusion Middleware community and specifically the FMW security community. The middleware products may seem complicated, even overwhelming at first, but they are good powerful products that you can build your business upon.

Why You Should Care

What does this mean for those of us in the Fusion Middleware Security community? Why should we care?

For one Fusion Apps has been driving much of the direction of Fusion Middelware for some time and now is your opportunity to see what it is all about and how the Middleware you know and love is used. In this post I’ll provide an overview of this usage and follow up with much more detail in the coming months.

Secondly, I think our community is about to get much larger. Every Fusion Apps customer will become a Fusion Middleware Security Customer. So, I’ll also take the opportunity now to say welcome to all the new Fusion Apps architects, developers, and administrators out there that may happen across this post.

Thirdly, Fusion Applications is a very large and complex set of applications. Oracle has created an Enterprise Deployment Guide specifically discussing how the Identity Management products that Fusion Apps utilizes should be deployed. It is worth reading this just to get an idea for what Oracle considers as reference architecture for an IAM environment that supports large business applications.  You can find the Enterprise Deployment Guide for Oracle Identity Management (Fusion Apps Edition) here.

I myself have been very involved in the initial rollout of Fusion Applications and will continue to be very much involved along with other members of this blog in helping to advise customers on the security technology involved in Fusion Apps deployments.

What This Doesn’t Mean

With all that being said, while I do think the release of Fusion Applications is exciting and important to those of us in the Fusion Middelware Security community, I have heard some messaging around Fusion Applications and its impact on Fusion Middleware that I think oversells the importance of Fusion Apps and is ultimately incorrect.

I’ve heard it said many times that customers should closely align their use of our Fusion Middleware products to how they are used in Fusion Applications. While I agree that customers should be mindful of how FMW is used in Fusion Apps, I simply don’t agree with that statement.

Fusion Applications is a set of specific applications, namely business applications, which use our Fusion Middleware Security stack in a specific set of ways. They do not make use of every feature or even every product in our FMW Security stack. Our Fusion Middleware customers use our middleware products in a wide variety of ways, to create and support a wide variety of applications, with a wide array of business requirements, in a large variety of environments. Some of the differences between what our customers are trying to achieve with Fusion Middleware vs. what we achieved with Fusion Middlware in Fusion Apps means that customers can and should take different approaches from what was taken with Fusion Applications.

What FMW Security Is In Fusion Apps

Now that my rant is out of the way, I’ll proceed to talk about how Fusion Middleware Security is used in Fusion Applications on a product by product basis. Again, for a more detailed discussion at this time see the Enterprise Deployment Guide for IDM (FA Edition).

  • Oracle Internet Directory (OID) serves as the store for OPSS security policies and as the default store for Fusion Apps users.
  • Oracle Virtual Directory (OVD) serves as a go-between layer for user stores when OID is not being used (and optionally when OID is being used. It is also always used in conjunction with OIM for a feature called LDAP sync which provides real time synchronization of users between OIM and an LDAP directory.
  • Oracle Access Manager (OAM) provides authentication and singles sign-on (SSO) for Fusion Apps. It is worth noting that OAM runs in a special mode in Fusion Apps build outs and does not by default provide authorization, even course grained, for Fusion Apps. This means that some careful consideration will have to be done by customers wanting to use a single OAM deployment for Fusion Apps and other applications in their environment.
  • Oracle Identity Manager (OIM) helps provision users to the FA environment and provides delegated management and self service user management services to the Fusion Apps environment.
  • Oracle Platform Security Services (OPSS) provides the fine grained authorization for the application in Fusion Apps as well as an assortment of other functions such as LDAP connectivity and key management.
  • Oracle Web Services Security Manager (OWSM) provides web services security (WS-SEC) for both FA internal web services communication and the external web services interfaces to FA.
  • WebLogic Server serves as the core container for Fusion Apps and so WLS security is part of the picture. Specifically, identity asserters and authenticators (SSPI providers) are configured in FA. Other WLS security areas such as transport (SSL) security and node manager security also come into play.
  • Oracle HTTP Server (OHS) serves as the web tier for Fusion Apps. There are actually two web tiers in a Fusion Apps deployment. The first web tier is the front end to the IDM environment and the 2nd is the front end to the Fusion Apps themselves. Both web tiers will have OAM webgates on them. Beyond that SSL is the main security consideration you will have to configure / manage.
  • SOA Suite – SOA Suite is widely used throughout Fusion Apps including (as most of you know) its use as the workflow engine for OIM. There is a good deal of security in SOA Suite to manage including transport and message level security.

WebLogic Domain Models for Installing the Oracle Identity Management Suite – Part 2

A couple days ago I wrote what I consider to be an important post about whether different Oracle middleware packages (or bundles) should be installed together in a single domain or installed in separate domains.

I’ve received a few questions asking a logical extension of that topic which is what about the individual products within one package? Should individual products within one package be installed together in a single domain (which is really the default behavior) or be spread across several domains? For example, if you are deploying the Identity Management package with OID,OVD, and OIF, should you install them all in one domain or maybe put OIF in one domain and OID in a separate domain?

There are a number of things to consider in answering this question.

Let’s begin by looking at the issues that led me to recommend that you not install multiple packages/bundles in a single domain.

The first issue was the risk of incompatibilities between the packages and the difficulty in dealing with such issues when they arise. I would have to say that this issue does not apply to multiple products within one package. After all, the package was explicitly developed and tested with the idea that all the products would be running in same domain.

The second issue I raised was the notion that deploying multiple packages to one domain could complicate patching and upgrading; even potentially leading to a situation where you will be kept from upgrading due to version incompatibilities. Again, since we are now talking about products within one package, there is less of a concern about patching and upgrades. However, since even a single product patch could include components that are common across the entire package, having all the products from a package in a single domain means that you should really test every product that you use in the domain before deploying the patch to production. I don’t see this as being a huge deal but it is something to consider.

The next consideration which I did not address in my last post is delegation of duty or purpose for a domain. Some customers segregate certain WLS domains for certain purposes. Often this is seen as a security practice such as the case where a customer deploys all intranet apps to one domain , extranet apps to a second domain, and utility services to a third domain. If you are a customer that does this you may see some products in a package as falling in a different category from another. One example of this is that many customers will see OID and OVD as being “internal” or “utility” applications where as they might see OIF as being an “external “– end user facing application. This might lead them to deploy these applications from the Identity Management package into separate domains.

The last consideration is to note that some of the integrations between products in a package only work if the products are installed in the same domain. Two examples of this are the OAM/OIM integration and the native integration between OAM and OAAM. If you want to use the integrated functionality offered by these packages, you have to deploy them in the same WLS domain.

Tell what patches are installed in your Oracle IAM 11g deployments using OPatch

People often want to know how they can tell what versions (including patches) of software they are running in their different environments. Fortunately, there is a simple standard way to get this information for all software that uses the Oracle Universal Installer. The method I speak of uses the OPatch utility that is standard for all Oracle products that use the universal installer. This includes most, if not all of Fusion Middleware 11g and all of the 11g Identity Management packages.

OPatch is the utility used to patch Oracle products that utilize the Oracle Universal Installer. It is included in most product/package installs under that package’s ORACLE_HOME/OPatch.

Now, keep in mind that when you execute OPatch it will operate on the ORACLE_HOME that is set in the environment. So, if you are operating in an environment where you have multiple products/packages installed under one Fusion Middleware Home (FMW_HOME) you want to make sure that you have an ORACLE_HOME environment variable pointed to the product/package you are interested in patching or analyzing.

To get information on the version and patch levels of your Oracle product/packages run ‘opatch lsinventory’. Again, make sure that ORACLE_HOME is set to the product/package that you want the information for. If it is not set, then OPatch picks some default ORACLE_HOME from your FMW_HOME in a manor I have yet to figure out.

You can also use OPatch to tell you all the ORACLE_HOMEs that exist under your FMW_HOME by running ‘opatch lsinventory -all’.

The documentation for OPatch can be found in the Oracle Universal Installer and OPatch User Guide