Adding FA AppIDUsers to the no password expiry policy in R12

Introduction During provisioning of a new FA instance the passwords for FA AppIDUsers like FUSION_APPS_PROV_PATCH_APPID or similar users will expire after 120 days which is the standard value for normal OID users. This article is intended to describe how you can apply the no password expiry policy to all FA AppIDUsers in a newly provisioned R12 […]

Getting Credentials in Fusion Applications

Introduction Oracle Fusion Applications is configured to save normal user names and credentials in Oracle Internet Directory (OID) and used for authentication purposes. Many of the applications store connection usernames and credentials they need in the credential store and retrieve these from the store when required. This article shows how Fusion Applications Administrators can retrieve […]

Migrating your Fusion Applications Auth OHS to a DMZ server

Introduction There maybe a need to expose your application to non-employees outside of your organization such as suppliers who make use of supplier portal. This article is intended to describe how you can do this after you have already provisioned your Fusion Applications environment. Main Article In this article we will describe the steps needed […]

Load Balancer Configuration for Fusion Applications

Background The Fusion Applications installation guide describes how load balancers are used and which features are required when planning a highly available Fusion Applications environment. The Oracle documentation does not contain supplier specific configuration settings for the load balancers. The purpose of this post is to help facilitate the discussion between the networking teams and […]

Oracle VM Storage Repository Replication for On-Premise Fusion Applications Disaster Recovery

Introduction Introducing Disaster Recovery into a Fusion Applications Environment can increase the management complexity – Oracle VM offers reliable solutions to simplify ongoing maintenance and switchover/failover processes. The solution discussed here is an example deployment for Fusion Applications as an Active-Passive Environment across two datacenters. It is an addition to the previously published article Disaster […]

Harvesting Information from IT Systems – Part 1

  Introduction Back in 2012, while I was performing research on how to make a Fusion Applications environment portable, the decisive moment came when I was able to confirm that I could copy the entire FA environment from one server to another and run it there as long as I added all hostnames present in […]

Disaster Recovery for On-Premise Fusion Applications

Introduction Disaster Recovery and Business Continuity are key requirements with most business critical on-premise Fusion Applications environments. Disaster Recovery for FA can be broken down into two layers that have to be syncronised to achieve full recoverability: Shared storage & databases. The solution described here supports simple full site switchover / failover and will satisfy […]

Network File System (NFS) Considerations for Fusion Applications

Introduction Network File System (NFS) is used with the majority of Fusion Applications deployments to satisfy the requirement for shared storage. Using NFS correctly can present a challenge, because there is not a single right way to mount NFS shares in Oracle Linux and there are multiple other potential sources for errors like the network. […]

HTTP Server configuration in Fusion Applications

Overview One of the most powerful features provided by Fusion Applications is the out-of-the-box configuration of the HTTP Server at Provisioning time. This feature comes in different flavors, enabling the user to select the most appropriate type of configuration for their environment, including setting it up for use with a load balancer or reverse proxy. […]

Avoiding and resetting expired passwords in Oracle databases

Introduction   Doing a default database installation will install a feature that all passwords will expire after 180 days. Not being aware of that can cause problems in applications as they cannot connect to the database after that time period. Especially if you are working in test or development environment you will mostly not care […]

Identifying Underlying Middleware BI Software Versions within Fusion Applications

Introduction At times an administrator may need to identify which version of software one or more of the middleware components is within fusion applications.  Before downloading and installing ODI Studio, you would need to know which version of ODI that particular release of Fusion Applications was running. While this article references the BI software components, […]

Validating the Fusion Applications Security Components During Installations and Upgrades

Introduction   When installing or upgrading Fusion Applications, it is necessary to validate the security components to ensure that they are functioning correctly. This article provides a list of tasks that can be performed to accomplish this. The order of tasks below follow the dependency that the components have on each other so that if […]

Installing and Configuring BI Admin Tool for Fusion Applications

Introduction The Repository, or ‘RPD’, is the file that contains the metadata for the BI Server in Fusion Applications.  This includes database connections, tables, joins, and structure by which these are presented to the report writer.  In order to read, or make changes to the RPD file, the BI Administration Tool must be installed. While […]

Floating IP Addresses and Whole Server Migration in Fusion Applications

How to Configure and Test Whole Server Migration Network Components Introduction Here’s a cold, hard truth for sysadmins:  in enterprise computing environments, no matter how stable or how large or how fast or how powerful the hardware or network, the probability that a hardware failure or a network glitch will occur can never get to […]

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.

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…

Setting memory parameters for servers in Fusion Applications

Note: The following article applies to Fusion Apps Release 4 (11.1.4 or RUP3) or lower. The procedure has changed in Release 5 (11.1.5 or RUP4) and I’ll update the post soon with details.Setting memory parameters for Admin and Managed servers of variou…

Configuring Essbase Cluster for Fusion Applications

If you have provisioned an FA environment using Release 3 (11.1.3) or Release 4 (11.1.4) and followed Chapter 14 of the Enterprise Deployment Guide to cluster BI and Essbase, you will get an error similar to the one below when running Create Cubes ESS …

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.

Configuring the system for a successful Fusion Application installation – Part 1 – System limits

IntroductionI wanted to share my experience in the installation of Fusion Applications. For those that are not as familiar with it, Fusion application installation goes through several phases after the provisioning plan has been created. These arePr…