OIM11gR2 Setting a specific user as a system administrator

Technique to set a user OIMADMIN to have the same access as XELSYSADM.
OIMADMIN is just an example.

Step 1: Set the user's USR_TYPE to "End-User Administrator"

update usr set usr_type='End-User Administrator' where usr_login='OIMADMIN';
commit;

Step 2: Add the user to the System Administrators "Admin Role"

In the Identity Webapp, logged in as xelsysadm, navigate to Organizations and search on the organization called "Top".
The first role in the Top organization is System Administrators.  Select it.
Explicitly add the OIMADMIN user to this role by direct assignment using the dialog provided.

Be sure to check the sub-orgs and Apply

That is it.   You should see SYSTEM ADMINISTRATORS in the Roles tab of the view user page.

Packaging an incident report on a weblogic managed server

How to package an incident report:

View this URL:

http://docs.oracle.com/cd/E27559_01/core.1112/e28516/diagnostics.htm#ASADM11171

Quick setup:

Here is a little script to list the OIM incidents (for OIM):

#!/bin/sh
# Lists time and problem for incidents on OIM
PWD=`pwd`
now=`date`
tf=/tmp/litmp$$
cd $DOMAIN_HOME/servers/oim_server*/adr/diag/ofm/oim_domain/oim_server*
echo "Searching incident reports"
find incident/ -type d -name 'incdir_*' -print > $tf
for each in `cat $tf`
do
  echo " "
  head -4 $each/readme.txt
done

Find the incident you want.

Have this script setenv_adr handy and source it:

ORACLE_HOME=$MW_HOME/wlserver_10.3/server/adr
export ORACLE_HOME
LD_LIBRARY_PATH=$ORACLE_HOME
export LD_LIBRARY_PATH
PATH=$PATH:$ORACLE_HOME

Next run adrci and copy in the following:

SET BASE <use your MW_HOME folder>/user_projects/domains/oim_domain/servers/oim_server1/adr
SET HOMEPATH diag/ofm/oim_domain/oim_server1

Of course use your own folder names and server names.  Then enter:

IPS CREATE PACKAGE INCIDENT incident_number

IPS ADD FILE filespec PACKAGE package_number 

IPS GENERATE PACKAGE # in /tmp

Working with the Oracle Diagnostic Logging on Weblogic

How to use the ODL effectively in the following:

Event Handlers
Scheduled Tasks
ICF Connectors

First, use the following classes in your code:
java.util.logging.Logger
java.util.logging.Level

You do not have to use log4j-xxx.jar it is not needed.

Second, and this is very important, if you CAN, do not begin your package name with com, rather use something unique like edu for colleges or your company abbreviation.  This will make it easier to do the configuration in the Enterprise Manager.

Next, in your code, use the following techniques:
1) In your class definition, create a private static final Logger called logger and initialize it with the class like this:
private static final Logger logger = Logger.getLogger(MyClass.class.getName());

2) In each method specify a String with the method name such as:
String methodName="execute";

3) At the beginning of each method use:
logger.logp(Level.FINE, getClass().getName(), methodName, "Entering");

4) Optionally, at the end of each method use:
logger.logp(Level.FINE, getClass().getName(), methodName, "Exiting");


5) For the rest of your output statements, use:
logger.logp(Level.FINE, getClass().getName(), methodName,
   "whatever you want to say in your message");

For these types of statements the following are available:
Level.SEVERE         Level.WARNING      Level.INFO
Level.FINE               Level.FINER             Level.FINEST

That's it for the code.

In Weblogic's Enterprise Manager, open the deployment where you have placed your code, Nav to this with WebLogic Domain -> domain name and select the managed server.

You will see the managed server name (it needs to be up with the green up arrow) and below that will read WebLogic Server and show a down arrow.  Select the down arrow and nav to Logs -> Log Configuration.

In here you see 3 tabs, Log Levels, Log Files, and QuickTrace.  Select Log Levels, View Runtime Loggers, and search on your class name.

Find your class name.  The default log level is normally WARNING.  Choose wisely the class or package you want to modify, and set the level to the highest level you wish to see.  Scroll to the bottom of the screen and check the "Persist log level state across component restarts" and then click "Apply".  Your logger is now set to go to the diagnostic.log file.

If you want to have your data go to a separate set of log files, go to the Log Files tab and select the odl-handler Handler Name, then click on "Create Like...", and create a new Handler.  Give it a cool name and change the configuration to use a different file name pattern than -diagnostic.  Save this and then assign your classes to it.  Done.

OIM How to pull an IT Resource Parameter

Inputs will be the IT Resource Name and the IT Resource Parameter Name

Define the following:
private tcITResourceDefinitionOperationsIntf itResDefOp=null;
private tcITResourceInstanceOperationsIntf itResInstOp=null;
private    long itResourceKey = 0L;

Next, in some module pull the Ops:

itResDefOp=Platform.getService(tcITResourceDefinitionOperationsIntf.class);
itResInstOp=Platform.getService(tcITResourceInstanceOperationsIntf.class);

Define a search and get the itResourceKey

Map searchFor = new HashMap();
searchFor.put("IT Resources.Name", itResourceName);
try {
    tcResultSet results = 
        itResInstOp.findITResourceInstances(searchFor);
    if (results.getRowCount() == 1) {
        results.goToRow(0);
        itResourceKey = 
            results.getLongValue("IT Resources.Key");
    } else {
        searchFor.clear();
        results = 
            itResInstOp.findITResourceInstances(searchFor);
        for (int i = 0; i < results.getRowCount(); i++) {
            results.goToRow(i);
            if (results.getStringValue("IT Resources.Name")
                .equalsIgnoreCase(itResourceName)) {
                itResourceKey = 
                     results.getLongValue("IT Resources.Key");
                break;
            }
        }
    }
}
catch (Exception ex) {
    ;
}

Finally, pull the parameter value:

try {
    tcResultSet paramSet= itResInstOp
       .getITResourceInstanceParameters(itResourceKey);
    int numParams=paramSet.getRowCount();
    if (numParams < 1) {
        ;  // Do something here it's not found
    }
    for (int iparam=0; iparam < numParams; ++iparam) {
        paramSet.goToRow(iparam);
        String paramName=paramSet
           .getStringValue("IT Resources Type Parameter.Name");
        if(paramName
           .equalsIgnoreCase("WhatYouAreSearchingFor")) {
            ResultValue=paramSet
               .getStringValue("IT Resource.Parameter.Value");
        }
    }
}
catch (Exception e) {
    ;
}

Reduce Weblogic startup time

This one is from my coworker:

In the jre/lib/security/java.security file for the JDK you are running WLS under look for this line:

securerandom.source=file:/dev/urandom

and change it to:

securerandom.source=file:/dev/./urandom

It cuts the startup time in half.  It has to do with a bug where Java interprets /dev/urandom as /dev/random which is a really slow RNG in Linux.  Adding the /./ reference is a simple workaround and makes it go back to /dev/urandom as the RNG.

SSL Keytool Mojo

Keytool setup: put the following into your .bash_profile:

JAVA_KEYSTORE="-keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit"

DEMOTRUST_KEYSTORE="-keystore $WL_HOME/server/lib/DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase"

This will make it easy to use keytool.  Then you can do:

keytool -list $JAVA_KEYSTORE

keytool -list $JAVA_KEYSTORE | grep rootca

keytool -delete -alias rootca $JAVA_KEYSTORE

keytool -import -alias rootca -file <filename> $JAVA_KEYSTORE

Tips on using SourceTree with Git.

One option is to not use a branch at all, just work on the master repo.
This is a good option for just uploading a bulk operation.
In this case, just change your files and Stage the changes.
Then just commit the changes and push them.

Create a develop branch.

Check out the develop branch.
Make your code changes.
Your new code should be in the File Status tab, Working Copy Changes.
Review your changes and click the up arrow to push all of your code to Staged Changes
Click Commit and enter an appropriate note.
Your develop branch will now be above your master branch.
Click on master and check it out.  Will see the purple as your main line.
Click Merge and select the develop branch.  (Commit merge immediately).
Develop and master should be on the same line.
Now do a push of master up to the remote branch.

OIM How-To set the xelsysadm password to never expire

To set the xelsysadm password to never expire, log into the database as the OIM schema owner and execute:

update usr set usr_pwd_warn_date=null, usr_pwd_expire_date=null,

usr_pwd_never_expires='1' where usr_login='XELSYSADM';

commit;

You can do this for any user.

How-To set the OIM database accounts to never expire

Because Oracle has put reasonable security limits into the default profile of the 11g database, when the OIM RCU runs it put the schema accounts into the default profile.  These account passwords will expire if you do not explicitly set them to not expire.  Assuming a Prefix of EDG the procedure will look like this:

$ sqlplus / as sysdba

SQL> CREATE PROFILE SERVICE_ACCOUNT

2    LIMIT PASSWORD_LIFE_TIME UNLIMITED

3    FAILED_LOGIN_ATTEMPTS UNLIMITED;

Profile created.

SQL> ALTER USER EDG_MDS PROFILE SERVICE_ACCOUNT;

User altered.

SQL> ALTER USER EDG_OIM PROFILE SERVICE_ACCOUNT;

User altered.

SQL> ALTER USER EDG_SOAINFRA PROFILE SERVICE_ACCOUNT;

User altered.

SQL> ALTER USER EDG_OPSS PROFILE SERVICE_ACCOUNT;

User altered.

SQL> ALTER USER EDG_ORASDPM PROFILE SERVICE_ACCOUNT;

User altered.

​

If the user passwords are due to or already have expired, go through all 5 of them (as sysdba) and re-set the password by entering (example for user EDG_OIM):

SQL> ALTER USER EDG_OIM IDENTIFIED BY <password>

Where <password> is the password of record, or a new password if you want to make those changes

Some updates 2015-June:

Use this script to get the list of profiles:

clear breaks
set linesize 120
set pagesize 10000

select * from dba_profiles;

Use this script to get the list of users:
clear breaks
set linesize 120
set pagesize 10000

select username, profile, account_status from dba_users;

For some systems you may have additional users to add to the profile.

OIM11gR2 Testing Access Policies

When developing and testing access policies, the following guidelines are good advice to follow:

In the Scheduler, typically the Evaluate User Policies scheduled job runs every 10 minutes.

When testing access policies, it is a good idea to click the Disable button so that the job does not run on its schedule.  The job can then be executed using the Run Now button.

When modifying an Access Policy, if the Retrofit Access Policy flag is set to Yes, then every user will be re-evaluated, and if the user fits the policy, that user will have their POLICY_EVAL_NEEDED flag set to 1 in the USER_PROVISIONING_ATTRS table.  If you don't want every single user to be re-evaluated, then after modifying the access policy, execute an update query such as:

UPDATE USR_PROVISIONING_ATTRS SET POLICY_EVAL_NEEDED=0

and then when you are prepared to test a user, use a similar query such as:

UPDATE USR_PROVISIONING_ATTRS SET POLICY_EVAL_NEEDED=1 WHERE USR_KEY=2023

It's a good idea to review and document the user that you chose to test before and after the test.  To execute the access policy logic, just go back and run the Evaluate User Policies scheduled job.

OIM11gR2 finding a list of active plugins

To find a list of plugins in your environment

Log into the OIM schema account for your environment

Execute a SELECT * FROM PLUGINS to view all of the active plugins.

Execute a SELECT * FROM LATEST_PLUGINS to compare.

It is a good practice, when performing active updates to plugins in your development environment, to modify the version number each build, so you have a way to validate that your plugin was picked up by the system.  Another way to do this is to review the diagnostic log for the messages indicating that the plugin has been picked up.

OIM11gR2 finding the event handlers currently deployed

To find the list of event handlers in OIM11gR2

• Log into the OIM Enterprise Manager http://<site>:7001/em
• On the left display, expand the Identity and Access folder and then the OIM folder under that, and then select the oim(11.1.2.0.0) object under the OIM folder.
• On the right display, select the dropdown reading Oracle Identity Manager and release on the System MBean Browser.
• In the folder structure, find under Application Defined MBeans: oracle.iam, and expand the Server: oim_server1 folder.
• Continue expanding the Application: oim and IAMAppDesignMBean folders, to expose the ConfigQueryMBeanName.  Searching on this name may work but may yield multiple results.
• Select the Operations Tab and click on the getEventHandlers operation.
• In the query put the Entity you wish to search on (User for user event handlers) and the operation (Create, Modify, Delete typically) and click Invoke.
• The display will reveal the Stage, Order, Name, Location, and Conditional flag for each event handler.
• System event handlers will typically have their location prefaced by /metadata.
• Registered custom event handlers will typically have their location prefaced by /custom
• Properly constructed plugin handlers will typically have their location prefaced by Plugin:
• Continue documenting the handlers you wish to review and then after modification.