All posts by Robbert van der Hoorn

Unraveling OAM Service Providers, partner profiles and authentication schemes

Unraveling your OAM Service providers

Service providers in OAM are mapped to  partner profiles and authentication schemes. These are defined with wlst commands. Unfortunately, these settings are not visible in the OAM console. They can be discovered by looking in the oam-config.xml file, but that is a rather tedious exercise.

There is a set of wlst-commands to unravel the structure. I will try to describe them below.

Listing all serviceproviders

Serviceproviders can be listed with the command


Partner profiles

ServiceProviders have partner profiles attached to them. A list of partner profiles can be retrieved with the command


To see which partner profile is attached to a SP, use


The other way round, to see which partners are attached to a profile, use


Authentication schemes

Now, you may want  to check which authentication scheme is used for a partner. This is tricky: the authentication  scheme can be defined on the partner profile level or on the SP level, or both.  If both are defined, the SP level scheme supersedes the profile level scheme. Problem: once defined on the SP level, it can only be deleted with

 deletePartnerProperty(partnerName,partnerType, “defaultschemeid”)

To check the scheme on the SP level, use

getPartnerProperty(“<partnerName>”, “sp”, “defaultschemeid”)

If no default scheme is defined, you will get no answer.

To check the scheme on the partner profile level, use


and look for the property defaultschemeid.

Webgate status page webgate.cgi

To monitor a webgate status, OAM webgates have a status page: webgate.cgi.  It does not reveal much information, but the page shows (at least) two important things:

  • Whether the webgate is working (getting a response means it works)
  • The attached OAM instance (so you don’t have to check the local ObAccessClient.xml file)

Looking at the layout of this page, it used to show more info, but appearantly it is not working anymore.

To enable the status page, some changes to the webgate and resources must be made.

  1. Add a user-defined parameter to the SSO webgate in OAM
  2. Unprotect the resource /ohs/modules/** (exclude) or modify webgate.conf and add
  3. For security reasons, you might add a pre-authorization rule allowing access from a limited range of ip addresses.

The webgate.cgi page is located at different url’s for different Application Servers:

  • OHS = http(s)://hostname:port/ohs/modules/webgate.cgi?progid=1
  • Apache = http(s)://hostname:port/apache/modules/webgate.cgi?progid=1
  • IIS = http(s)://hostname:port/webgate/webgate.dll?progid=1

The underlying wallet operation failed

Using a webgate with an OAM agent may result in the error: “The underlying wallet operation failed.” raw_code^223.

This is caused by the file cwallet.sso, which is not compatible with It needs to be converted at the OAM server with the command:

/oracle_common/bin/orapki wallet convert -wallet ./cwallet.sso -auto_login_only

Copy the converted cwallet.sso to the webgate and restart.

Installing Openldap 2.4 on Redhat

Besides the wonderful Oracle LDAP servers OUD and OID, there is the open source LDAP server OpenLDAP.  For a project that lacked the money to pay for the Oracle beauties, I had to install and configure OpenLDAP on Linux.

I’m not much into Open Source so I’d have to do with Google…

Installing the software and creating an initial LDAP server is fairly straightforward:

  • yum install openldap-server
  • service slapd start

And I have a running LDAP server on port 389.

Making sure the server will restart on reboot of the server:

  • chkconfig –levels 235 slapd on

Then comes the hard part.  I want to define my domain (dc=xx,dc=local) and I want to use a tool like ldapadmin (on Windows…) to connect to my server, so I need a user account and password.

No problem (according to some folks on the internet). Just edit the file /etc/openldap/slapd.d/cn=config and add/edit some values. But wait…. what’s on top in the file?

# CRC32 5061e392

which at least suggests that we can not edit this file by hand. But as the documents suggested, I still did and changed the domain and added a password (generated with slappaswd)

olcSuffix: dc=xx,dc=local
olcRootDN: cn=Manager,dc=xx,dc=local
olcRootPW: {SSHA}R+r/c9gbudNXUa01AbpjvQtGX0DB9IPM

This works but: I get logs with checksum errors!

Advise: DO NOT EDIT THE FILE!!!! Use ldapadd/ldapmodify!!!

Next article: HOW do we use ldapadd/ldapmodify?


Oracle 12c EPG (XDB) uses digest authentication in stead of basic.

After an upgrade from 11g to 12c, an application using the external procedural gateway (EPG) and basic authentication got a 401: not authorized.

It appears that in 12c, the EPG uses digest authentication in stead of basic authentication by default. You won’t notice this using a browser or WGET, but applications using CURL will fail.

Digest is a two-step way of authenticating, returning a so called nonce first to be used to encrypt the username and password in the request.

Using CURL, this can be solved by adding – -digest before the request.

An other option is to reset EPG (actually XDB) to use basic again by editing xdbconfig.xml (a row in the table XDB$CONFIG).

This can be done using this call:

call dbms_xdb.cfg_update(updateXML(
, ‘/xdbconfig/sysconfig/protocolconfig/httpconfig/authentication/allow-mechanism/text()’
, ‘basic’))

followed by


Don’t forget to commit…



Configure DIP to synchronize with Secure LDAP AD using wallets and keystores.

To configure DIP to be used with a secure LDAP AD (SSL), first a certificate store must be created for DIP. It can be created with a tool like keytool or kse. Create a JKS store and call it dip.jks. Get a trusted certificate from the AD server (this can be achieved with an ldap command, I used ldapadmin, browsed for CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,C=nl and exported the certificate to file by right-clicking the Cacertificate attribute of the certificate entry). Import this certificate as a trusted certificate in the jks keystore.
This keystore will be used with DIP. For manual ldapcompare and bind commands (and later for the plugins), you will also need a wallet with this certificate.

Now, we need to tell DIP to use this jks store. This can be achieved with the command
./manageDIPServerConfig set -h -p 7015 -D weblogic -attribute keystorelocation -val /oracle/middleware_OID/keystore/dip.jks
(change servername, port and location as desired). The port must be the port ODSM is using.

We have to create a credential to store the keystore password in OID using wlst:

Run the following commands to create a CSF credential and update the Java Keystore password:

Open the WLST prompt by running the following command:


Connect to the WebLogic Admin Server:

connect(‘Weblogic_User’, ‘Weblogic_password’, ‘t3://Weblogic_Host:Weblogic_AdminServer_Port’)

Create the credential and update the Java Keystore password:

createCred(map=”dip”, key=”jksKey”, user=”jksuser”, password=”JKS_password_created_previously_in_step_2″)

The only thing to change here is the password, copy the rest “as is” .

Then, we create the profile as ‘usual’ , ticking the ssl enabled flag and specifying the ssl port of the AD. After correcting the domain mapping rules, bootstrap the profile with $ORACLE_HOME/bin/syncProfileBootstrap.

Second part is to get the oidexplg plugins working. They are configured like any other oidexplg plugin. I created a new one from scratch, because my AD plugins were alreay in use for synchronising with another AD. I copied all the paramters one by one from the AD plugin. The flexfields can be entered after saving the configuration. Don’t forget the secure flexfields for the wallet.

Yes: we need a wallet, with the same certificate as in the keystore we created. Wallets can be created from the Em-console Menu oid/wallets.

To find the created wallet, look for a file ewallet.p12. This location must be registered with the plugins, inlcuding the ewallet.p12 filename.
The wallet password is stored in a secured flexfield.

Examine OID Replication Human intervention Queue

Oracle recommends using the scripts, $ORACLE_HOME/ldap/bin/ (or but I wasn’t able to get these to work even after modifying as indicated on metalink. I was able to do the following and then confirmed with Oracle Support that this was correct.

Log in to the Database (Replica DB) as ODS user:

Determine what we are dealing with (I wanted to see what columns were in the table)

1. sqlplus ods/password
2. describe asr_chg_log
3. select chg_no, orclguid, chg_seq, retry_cnt from asr_chg_log; Delete entries whose RETRY_CNT is -1 (which means they are in the HIQ):
4. delete from asr_chg_log where RETRY_CNT = ‘-1′;

Restart OID (on both nodes: master and replica)

1. opmnctl stop

2. opmnctl start Use ODM to make change in master.

Confirm by watching for change in Replica.

Using x after sudo su –

As first logged in user, type: xauth list
Gives something like
servername:11 MIT-MAGIC-COOKIE-1 b5d6725cd2be54e6b681b8fe5e4d4702
servername:12 MIT-MAGIC-COOKIE-1 e2ed6b2ebcaf1b2cde22b75085e6ee17
servername:10 MIT-MAGIC-COOKIE-1 1ead678498951862eca4775f1936e3e5

Type: env | grep DISPLAY
Note :10, so use the magic cookie for :10 (last line in this example)

Sudo su –
export DISPLAY=ipaddress:10:0
xauth add servername:10 MIT-MAGIC-COOKIE-1 1ead678498951862eca4775f1936e3e5

And type xclock to verify.

Tracing the Kerberos Plugin Authentication module in OAM

When I was installing and configuring OAM with WNA using the Kerberos plugin, I had the need to trace what was happening while the plugin was trying to log me on.
Weblogic has loggers configured, and by setting the log level of oracle.oam.plugin to TRACE:32, the plugin could be traced. Unfortunately, oracle.oam.plugin is a child of the root logger, so all tracing will be mixed with other traces/logs.
A seperate logger for oracle.oam.plugin can be created however. In the enterprise manager console, under Weblogic domain, select the server you want to trace, and select “logs/log configuration”.
Select “view: loggers with persistent log level state”. Below, you’ll find a box “Name” under Specify Loggers.
In this box, type “oracle.oam.plugin”.
Once this logger is defined, a seperate log file can be defined for this logger. Plugin traces are now seperated from other log files and can be tailed with Linux while debugging/tracing.

OAM cluster, ECC, WNA and load balancer

It took me some time to configure an Oracle Access Manager Cluster with a loadbalancer and ECC for Windows Native Authentication. After successfully configuring WNA for one of the branches without loadbalancing, it appeared to be fairly simple to move to a load balanced situation. The most important thing to do is to make sure the cluster can resolve the name of the loadbalancer via DNS. When this is done, NO configuration for virtual hosts or whatever has to be done.
These three steps should be taken:
1) Configure your load balancer just for the Managed Server port (in most cases 14100, or a port in the 700x range). It’s the port for the login screen if WNA is not supported. Port 5575 (webgate) does not need to be load balanced, this is resolved by the webgate itself
2) Add the loadbalancer address to DNS
3) In the Access manager settings page of the Access Manager Console, change the server name and port to those of the load balancer entry
4) Generate ONE .keytab file with a Server Principal Name for the load balancer address, and use this file on both managed servers.

No update of the gateways has to be done (just bounce opmnctl once), no restart of the Access Manager Server.