setting mBean attributes after securing OIM with SSL

When you setup SSL for Oracle Identity Manager, you have to click through a pretty complicated mBean path. Since I am all about scripting deployments, I created a small WLST script that sets the appropriate mBean attributes for me. Creating this script was easier because of one of Edwin Biemond’s posts.

The specific attributes are:

• OimFrontEndURL: The URL the end-user uses to access the OIM application, usually a VIP on a http-loadbalancer
• Rmiurl: The URL the OIM application uses to contact SOA over RMI. This is a comma separated list of SOA servers available to OIM
• Soapurl: The URL on which the OIM application can invoke services on SOA, usually a VIP on a http-loadbalancer

Please keep in mind that you might have to set up mod_wl_ohs on an http server. Also keep in mind that you have to choose the correct ports, in my case default https for OIM and SOA SOAP (with mod_wl_ohs in place) plus 8002 for t3s for SOA RMI.

Anyway, here’s the script (and yet again: sorry for the fubar layout):

connect('weblogic','Welkom01','t3s://oim.area51.local:7002')

domainRuntime()

oimBean = ObjectName('oracle.iam:Location=oim_server1,name=Discovery,type=XMLConfig.DiscoveryConfig,XMLConfig=Config,Application=oim,ApplicationVersion=11.1.1.3.0')
fUrl=Attribute('OimFrontEndURL','https://oim.area51.local')
mbs.setAttribute(oimBean,fUrl)

soaBean = ObjectName('oracle.iam:Location=oim_server1,name=SOAConfig,type=XMLConfig.SOAConfig,XMLConfig=Config,Application=oim,ApplicationVersion=11.1.1.3.0')

soaConfigRmiURL=Attribute('Rmiurl','t3s://oim1.area51.local:8002,t3s://oim2.area51.local:8002')
soaConfigSoapUrl=Attribute('Soapurl','https://oim.area51.local')

mbs.setAttribute(soaBean,soaConfigRmiURL)
mbs.setAttribute(soaBean,soaConfigSoapUrl)

disconnect()

After you have configured SSL correctly, I suggest you also enable the SSL port for OIM. How this can be done I explained here.

P.S. if you would setup OIM on a cluster, you would need to setup these attributes too.

Hope this helps.

reponse files for iam 11.1.1.5 is broken

When you run the silent install of iam 11.1.1.5 with the out of the box response file you get an error:


[ERROR] Data Insufficient to start Install.
[ERROR] One and Only One of the following variables must be present

Variable Name:SKIP_SOFTWARE_UPDATES     Expected Value:true
Variable Name:SPECIFY_DOWNLOAD_LOCATION Expected Value:true
. Aborting Install


As the error shows, the response file for iam 11.1.1.1.5 is missing the SKIP_SOFTWARE_UPDATES directive.

Just add SKIP_SOFTWARE_UPDATES=true to the .rsp file and you’re set to go.

The new file would look like this:


[ENGINE]
#DO NOT CHANGE THIS.
Response File Version=1.0.0.0.0
[GENERIC]
#Provide the complete path of the Oracle Home. The Oracle Home directory name may only contain alphanumeric , hyphen (-) , dot (.) and underscore (_) characters, and it must begin with an alphanumeric character.
ORACLE_HOME=/u01/app/oracle/middleware/Oracle_IAM1
#Provide the complete path to a valid Middleware Home.
MIDDLEWARE_HOME=/u01/app/oracle/middleware
#Give the list of complete paths of all the valid Middleware Homes existing on the system.
MIDDLEWARE_HOME_LIST=/u01/app/oracle/middleware
SKIP_SOFTWARE_UPDATES=true
[SYSTEM]
[APPLICATIONS]
[RELATIONSHIPS]


OID11 on Windows 2008R2 abnormality

One of the organizations I work for is running their middleware on Windows (on VMWare), to be precize on Windows 2008 R2. Last week service pack 1 was applied on their boxes and somehow OID died on me. When I checked opmn I noticed that oid was really down:

opmnctl status

Processes in Instance: asinst_1
--------------+--------------+------+---------
ias-component | process-type | pid | status
--------------+--------------+------+---------
oid1 | oidldapd | N/A | Down
oid1 | oidldapd | N/A | Down
oid1 | oidmon | N/A | Down
EMAGENT | EMAGENT | 3868 | Alive


Now when I called opmn to start all processes, I didn’t see an error, but somehow OID still didn’t start:

opmnctl startall
opmnctl startall: starting opmn and all managed processes...

opmnctl status

Processes in Instance: asinst_1
--------------+--------------+------+---------
ias-component | process-type | pid | status
--------------+--------------+------+---------
oid1 | oidldapd | N/A | Down
oid1 | oidldapd | N/A | Down
oid1 | oidmon | N/A | Down
EMAGENT | EMAGENT | 3868 | Alive


When I checked the logfiles I noticed that the .oidmonstdout had a different filesize from normal. The contents was this:


ORA-24550: signal received: Unhandled exception: Code=c0000005 Flags=0

----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
kpeDbgCrash()+83 CALL??? kpedbg_dmp_stack()+ 0774AB328 00168DD86 000000000
0 005CFD9D0
kpeDbgSignalHandler CALL??? kpeDbgCrash()+0 00168E026 000000000 005CFD9D0
()+122 000000002
skgesig_Win_Unhandl CALL??? kpeDbgSignalHandler 000000000 000000000 000000000
edExceptionFilter() ()+0 000000000
+171
0000000077439490 CALL??? skgesig_Win_Unhandl 000000001 000000000 000000001
edExceptionFilter() 000000000
+0
00000000776543B8 CALL??? 0000000077439330 005CFDB40 000000006 000000000
000000001
00000000775D85A8 CALL??? 0000000077654374 000000000 000000000 000000000
000000000
00000000775E9D0D CALL??? 00000000775D850C 005D00000 005CFFF90 005CFFF90
077702DE8
00000000775D91AF CALL??? 00000000775E9D00 005D00000 0774ADF08 000012F24
00369C680
0000000077611278 CALL??? 00000000775D8E20 005CFE780 005CFE290 000000000
000000000
0000000000402877 CALL??? 000000007761124A 000000000 00056B5BC 005CFE730
005CFE6A8
0000000010011A80 CALL??? 00000000004027B4 000000000 000000000 004FCD010
003790000
0000000010005E3E CALL??? 0000000010011A24 000000000 7FEFD8E1413
004FCD010 004FCD010
000007FEFD92C387 CALL??? 0000000010005E08 00504E900 000000000 000000000
000000000
000007FEFD92C424 CALL??? 000007FEFD92C370 7FEFD971EA0 004FCD010
000000000 000000000
00000000773B652D CALL??? 000007FEFD92C3A8 000000000 000000000 000000000
000000000
00000000775EC521 CALL??? 00000000773B6520 000000000 000000000 000000000
000000000

----- End of Call Stack Trace -----


Some googleing tought me that this has to do with some sqlnet settings for diagnostics. Funny how diagnostics can actually break your stuff on Windows… Anyway, placing a sqlnet.ora in C:\Oracle\asinst_1\config (yes, that’s the config directory of your instance, or any other location if you have modified your opmn.xml manually) with this contents fixed the issue:

DIAG_ADR_ENABLED=OFF
DIAG_SIGHANDLER_ENABLED=FALSE
DIAG_DDE_ENABLED=FALSE

Hope this helps.

Configure a Database Audit Store for System Components

The documentation for configuring a database audit store for system components is wrong. When you populate the audit store password in the secret store, docs tell you to run this command:

$ORACLE_HOME/jdk/bin/java -classpath
$ORACLE_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar:
$ORACLE_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar:
$ORACLE_HOME/jdbc/lib/ojdbc5.jar:
$ORACLE_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar:
$ORACLE_HOME/modules/oracle.pki_11.1.1/oraclepki.jar
-Doracle.home=$ORACLE_HOME -Doracle.instance=$ORACLE_INSTANCE
-Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid
-Dauditloader.username=username
-Dstore.password=true
-Dauditloader.password=password
oracle.security.audit.ajl.loader.StandaloneAuditLoader

It should be this instead:

$ORACLE_HOME/jdk/bin/java -classpath
      $MW_HOME/oracle_common/modules/oracle.osdt_11.1.1/osdt_cert.jar:
      $MW_HOME/oracle_common/modules/oracle.osdt_11.1.1/osdt_core.jar:
      $ORACLE_HOME/jdbc/lib/ojdbc5.jar:
      $MW_HOME/oracle_common/modules/oracle.iau_11.1.1/fmw_audit.jar:
      $MW_HOME/oracle_common/modules/oracle.pki_11.1.1/oraclepki.jar
      -Doracle.home=$ORACLE_HOME
      -Doracle.instance=$ORACLE_INSTANCE
      -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid
      -Dauditloader.username=username
      -Dstore.password=true
      -Dauditloader.password=password
      oracle.security.audit.ajl.loader.StandaloneAuditLoader

Hope this helps.

“ignore” means “please restart the process”

I just wasted lots of my precious time (and the time of a support officer at Oracle).  When loading a repository using RCU I got an error mentioning that the TSPURGE package was not valid. The option I got were “ignore” and “stop”. Looking some more into the error it turns out that the tspurge package (in ODS schema) relies on DBMS_JOB. The grant to public for DBMS_JOB was removed on the security advice from OEM though. Just granting execute privileges on DBMS_JOB to the ODS user and hitting “ignore” results in a faulty repository (even though RCU claims all went perfectly). So, “ignore” means “please restart the process from the start”. It’s very interesting that Oracle’s own RCU tool doesn’t handle the security settings suggested by Oracle though.

Group existence

Usually I work on Linux and I love it. For some sort of reason it just took me an hour to find out if a group existed and what the gid was (ldap was configured). Therefore I make this not to myself: getent is cool!

The easiest way I found to check for group existence is:

$ getent group dba
dba:x:4006:

And, other way around, if you have the gid here’s how you find the group name :

$ getent group 4006
dba:x:4006:


</end reminder>

EUS and asmcmd

I have been working a lot with EUS lately at a big customer. My personal account is able to login to databases (EUS) and also on to OEL (OAS4OS). This combined with some chown/chmod commands on OEL enables me to do my job with my personal account.

Since this customers also uses ASM, I figured I would like to use my personal account for asmcmd too. First I tested the process with a local account, baby steps usually works best for me. I created an account jhl

# useradd -g asmadmin -G dba jhl

Next i su’d to jhl and tested the procedure:

$ id
uid=10238(jhl) gid=4007(asmadmin) groups=4006(dba),4007(asmadmin)

$ . oraenv
ORACLE_SID = [+ASM1] ? +ASM1
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.1.0/asm_200 is /u01/app/oracle

$ asmcmd
ASMCMD> ls

This looks promising, all needed to be done next was repeating the steps only now with an account from the OID. First I had to add the group to the OID, here’s the ldif I used:

EUS stopped working, solution found

Some time ago I wrote that EUS stopped working. Today I was finally able to spend some time on this issue. Obviously I could have know that the solution was easy: the default password policy was blocking the account. Creating a new password policy with an enormous password expiry date for the cn=OracleContext,dc=acme,dc=com subtree solved all EUS problems.

P.S. if you happen to create your own custom password policy, please follow the documentation carefully. The right-click-create-like method does not work.

SSO registration

Since I always seem to have to lookup how to call the ssoreg.sh script, here’s a reminder to myself. Hopefullu other people find this helpfull too.

#!/bin/bash
#
# Remember to setup the oratab!

VHOST=$1

if [ “${VHOST}x” = “x” ]
then
 echo “usage $0 virtual_host_url”
 exit 1
fi

ORAENV=/usr/local/bin/oraenv
 
ORACLE_SID=appserv
ORAENV_ASK=NO
. ${ORAENV}
ORAENV_ASK=YES
 
${ORACLE_HOME}/sso/bin/ssoreg.sh -oracle_home_path ${ORACLE_HOME} -config_mod_osso TRUE -site_name ${VHOST} -remote_midtier -config_file /opt/vhosts/${VHOST}/osso.conf -mod_osso_url http://${VHOST} -virtualhost

Suddenly EUS stops working….

For one of my clients I am assisting on a EUSimplementation with RDBMS 10.2.0.4 and OID 10.1.4.3 all on OEL 4.7. After implementing EUS and enjoying using my personal credentials instead of working as sys or system all worked like a charm. Customer happy, me happy, everybody happy.

After some time all of the sudden EUS stoped functioning for certain databases. Since the number of databases that EUS was not working for is growing, I was called to find out what was going on. I checked the login by setting event 28033:

alter system set events ‘28033 trace name context forever, level 9’;

Next i tried to login and I read the tracefile in $ORACLE_ADMIN/ORACLE_SID/udump:

/u01/app/oracle/admin/ORACLE_SID/udump/DB_NAME_ora_8058.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_200
System name: Linux
Node name: SERVER.DOMAIN_NAME
Release: 2.6.9-78.0.8.2.2.ELlargesmp
Version: #1 SMP Mon Dec 22 02:43:08 EST 2008
Machine: x86_64
Instance name: ORACLE_SID
Redo thread mounted by this instance: 2
Oracle process number: 67
Unix process pid: 8058, image: oracle@SERVER.DOMAIN_NAME

*** ACTION NAME:() 2009-09-16 14:06:03.492
*** MODULE NAME:(sqlplus@SERVER.DOMAIN_NAME (TNS V1-V3)) 2009-09-16 14:06:03.492
*** SERVICE NAME:(ORACLE_SID) 2009-09-16 14:06:03.492
*** SESSION ID:(527.12773) 2009-09-16 14:06:03.492
kzld_discover received ldaptype: OID
kzld found pwd in wallet
KZLD_ERR: Failed to bind to LDAP server. Err=49
KZLD_ERR: 49
KZLD is doing LDAP unbind
KZLD_ERR: found err from kzldini.

Ldap error 49 is invalid credentials, but I know for sure that my credentials are correct! I even use them to logon to the machine that the database is running using OAS4OS (which was somewhat challenging too, since OAS4OS as provided by Oracle is far from enterprise ready).

Knowing my userentry is correct, I checked the database entry in the oid. To my surprise I noticed that pwdexpirationwarned and pwdgraceusetime was set for the database entry (see cn=DB_NAME,cn=OracleContext,dc=domain,dc=acme). This suggests that the passwordpolicy was enforced for databases too, even though the effective subtree was set to cn=users,dc=domain,dc=acme. Simply removing the attributes for all databases in the OID solved the issue for now:

$ORACLE_HOME/ldap/bin/bulkmodify basedn=”cn=DB_NAME,cn=OracleContext,dc=DOMAIN,dc=nl” attribute=”pwdgraceusetime” value=”” replace=true filter=”objectclass=orclDBServer”
$ORACLE_HOME/ldap/bin/bulkmodify basedn=”cn=DB_NAME,cn=OracleContext,dc=DOMAIN,dc=nl” attribute=”pwdexpirationwarned” value=”” replace=true filter=”objectclass=orclDBServer”

Or for the die-hards:

delete from ds_attrstore
 where entryid in ( select entryid
                      from ct_dn
                     where rdn = ‘cn=db_name’ )
   and attrname in (‘pwdgraceusetime’,’pwdexpirationwarned’);

Please keep in mind that Oracle doesn’t support direct querying on the OID.

Let’s find out what Oracle Support is going to give me for a more permanent solution 😉