Invalid Credential when Add to Existing Deployment

I wanted to conduct a mini-POC for my customer with a dual instance of OpenAM servers. However, we have only 1 OpenAM server running in our labs. So, I went ahead to install the 2nd instance.

No good! Keep hitting "Unauthorised - Invalid Credentials" error...

How can that be? I was very sure I keyed in the correct credential of the 1st OpenAM in Step 1.

It was only after a while then I found out the cause. Our 1st OpenAM was already configured to authenticate with Microsoft AD by default.

The installer, by default, needs to communicate with OpenAM via the DataStore instance. So, we need to temporarily switch the AZAD instance back to DataStore.

And once the installer goes through, switch back to AZAD again will do the trick!

.

OpenAM High-Availability with Security

There are many types of customers. But there is 1 common characteristic in them - save cost! :)

When OpenAM servers are to be deployed in Production, high-availability is required most of the time (in fact, all of the time for my customers). So this implies more machines and thus more money!

And so, usually when High-Availability is concerned, 2 boxes are more than what they can commit.

But, it is not a good practise to deploy the Administrative Console facing the Internet. I would recommend the following architecture, always. 

This architecture strips off the administrative capability of the 2 Internet-facing OpenAM servers. To save cost, the OpenAM server with Administrative Console can be deployed in on of the boxes. 

It's not resource intensive since how many administrators can you have in a corporate? It can also be shut down when not in use. No excuse please.

.

Open Identity Stack

What is an Open Identity Stack? A simple diagram says it all.

Want to know more? Go to ForgeRock website by clicking here.

.

Common Boot-up Issue

It is fairly common to hear OpenAM administrators complaining of reaching the Configuration Options page after a restart of OpenAM server, even though they are pretty sure OpenAM was previously successfully configured.

Well, sometimes, I still do hit the same irritating page! Just like today. :) What happened?


A look at the web container's log (in my case, Tomcat 7) will reveal why:


INFO: Initiating Jersey application, version 'Jersey: 1.1.1-ea-SNAPSHOT 07/13/2009 07:22 AM'
checkConfigProperties :com.sun.identity.setup.ConfiguratorException: /home/azlabs/.openssocfg/AMConfig_home_azlabs_opt_am1_webapps_openam_ (No such file or directory)


A history of what I have executed in the shell prompt also confirm what's the real cause:


[azlabs@idp ~]$ history

  902  opt/am1/bin/shutdown.sh
  904  opt/am1/bin/startup.sh
  907  cat .openssocfg/AMConfig_home_azlabs_opt_tomcat-7.0.34-am1_webapps_openam_
  910  opt/am1/bin/shutdown.sh
  911  /home/azlabs/opt/tomcat-7.0.34-am1/bin/startup.sh
 

When OpenAM was initially configured, the Tomcat was started up via "opt/tomcat-7.0.34-am1/...". The symbolic link "am1" (which points to tomcat-7.0.34-am1) was later created.

As such, if Tomcat is now started via "opt/am1/...", it will attempt to look for a file "AMConfig_home_azlabs_opt_am1_webapps_openam_" in the .openssocfg directory (which obviously will fail since there is no such file).

And so, the famous "Configuration Options" page will appear.


.