Sun DS with OpenSSO schema - High Available Connections

In a highly-available setup, each OpenSSO server is recommended to connect to a dedicated Sun Directory Server for its Data Store. The other Directory Server will be configured as the secondary server (dotted lines). This ideal setup will yield better performance.

How to do achieve that in OpenSSO/OpenAM via the AM Console?

The above setup is wrong. It means both OpenSSO servers will connect to LDAP1 always. And only when LDAP1 is down, will both of them redirect to LDAP2.

This is not what we want to achieve. We want the setup to be highly available and efficient. (aka good performance)


So, we need to play with Format: LDAP server host name:port | server_ID | site_ID.


Problem is how do we know what is the value for server_ID and what is the value for site_ID?

As usual, I whack the OpenDS directly. The configuration data for the above screen is stored in ou=iPlanetAMPlatformService.

The configuration for Site is stored in ou=com-sun-identity-sites.

The configuration for Servers is stored in ou=com-sun-identity-servers.

So, the configuration should be as follows:

Nice!

.

Backing up configuration data -- Part II

The configuration data which is stored in the embedded OpenDS/OpenDJ can be dumped out into a XML file.

This little script can do the job:

/sso/bin/tools/ossotools/opensso/bin/ssoadm export-svc-cfg -u amadmin -f /tmp/.admin.pwd -e secretkeytoencryptpassword -o /tmp/svc-config-bkup.xml
echo "Configuration dumped to /tmp/svc-config-bkup.xml"

.

Backing up configuration data

Before a project goes LIVE, what do we usually do? Make sure backup is in place in case disaster kicks in.

So, this is what I am doing this week. I need to have a backup mechanism for the Single Sign-On infrastructure which I have set up for the local education ministry.

This book comes in handy - OpenAM by Indira. There's this chapter on Backup, Recovery and Logging.

The safest way to backup OpenSSO/OpenAM configuration data is non other than filesystem backup. (not mentioned in Sun's documentation)

The critical files and directories that need to be backed up are as follows:
• bootstrap
• OpenDS (whole directory)
• .version
• .configParam
• certificate stores
• config/xml (whole directory; if there is customized service schema)


ssoadmin@node01 $ /usr/sfw/bin/gtar -cvf opensso-bak.tar --exclude "opensso/opends/logs" opensso/bootstrap opensso/opends opensso/.configParam opensso/.version opensso/.configParam opensso/opensso/.keypass opensso/opensso/.storepass opensso/opensso/keystore.jks


If you are lazy, backup the whole configuration directory. But I would suggest discarding the debug and log directories. 


That can take up a huge amount of space if the log is verbose.




.

Unexpected LDAP error - ssoadm

The project I am currently on requires High Availability for Single Sign-On in the production environment. A site is configured for this purpose having 2 nodes.

Today, I was debugging something and shut down Node 2 and used ssoadm.jsp to update a service (update-svc) which I previously created.

When I tried to save, I get Unexpected LDAP error on the UI.

I found out why when I saw the following in Configuration log file:

ERROR: SMSLdapObject.modify(): Error in modifying entry: ou=1.0,ou=sunAMAuthXXXAuthService,ou=services,o=XXX,c=sg
By Principal: id=amadmin,ou=user,o=XXX,c=sg
com.sun.identity.shared.ldap.LDAPException: error result (53); The Replication is configured for suffix  o=Ministry of Education,c=SG but was not able to connect to any Replication Server
        at com.sun.identity.shared.ldap.LDAPConnection.checkMsg(LDAPConnection.java:4875)
        at com.sun.identity.shared.ldap.LDAPConnection.modify(LDAPConnection.java:3163)
        at com.sun.identity.shared.ldap.LDAPConnection.modify(LDAPConnection.java:3102)
        at com.sun.identity.shared.ldap.LDAPConnection.modify(LDAPConnection.java:3111)
        at com.sun.identity.shared.ldap.LDAPConnection.modify(LDAPConnection.java:3077)
        at com.sun.identity.sm.ldap.SMSLdapObject.modify(SMSLdapObject.java:435)

Hmm... any configuration change requires both nodes in the site to be up! Is this built by design? I need to find out more ...


.

Model must not be null in CCPropertySheet()

The project I am currently on requires High Availability for Single Sign-On in the production environment. (we have 2 nodes) The Authentication module is customized as we have special business logic to handle during users' login process.

So to plug in a new Authentication module is easy.
1. Deploy the jar
2. Dump the properties file in classes directory
3. Add in the XML file in config/auth/default directory
4. Create the new service
5. Register the authentication module

All went well with Node 1. However, I kept getting Model must not be null in CCPropertySheet() error on Node 2. I have restarted Node 2 more than once. Strange!

So what really happened?

I have forgotten to apply Step 1 - 3 on node 2. Ha!

(Note: Step 4 - 5 are only done once via the ssoadm.jsp UI)

.

Problems Solved By OpenSSO

I was reading the newly released OpenAM book by Indira Thangasamy and came across this diagram in the overview section.

Great stuff! I always salute those who can illustrate the capability of their products in a diagram. 

This diagram is able to show the 4 types of problems that OpenSSO/OpenAM is built for:

1. Access management
2. Federation
3. Securing web services
4. Entitlements

.

How to decode CSR?

After generating CSR (Certificate Signing Request) and before submitting to a CA to generate a Server certificate, it would be good if we can double check what has been generated.

If OpenSSL is installed, the following command can be used:

openssl req -in mycsr.csr -noout -text

I'm lazy. :) Thanks to SSLShopper. Here's the link.


.

Failed to establish chain from reply

If your server certificate (end-entity certificate) is signed by a Intermediate CA, then it is important to take note to import both Root CA and Intermediate CA certificates into your keystore (certificate store) before importing the server certificate.

Importing only Root CA certificate into the keystore is not sufficient. Otherwise, you'll get the following error when you import the Server certificate without the Intermediate CA certificate - "Failed to establish chain from reply".

.

Active Directory Primary Server Configuration for Multiple OpenSSO Servers

In a large scale IAMS infrastructure setup, it would be better if each OpenSSO server is configured to authenticate against a dedicated authentication source (in my case, Microsoft Active Directory).

Is this feature available in OpenSSO 8.0 U2? Yes, as far as the OpenSSO Admin Console is concerned. (see digram below)

However, you need to first figure out what does "local server name" means?

I had a hard time figuring out what this really mean. In the end, I had to read the source codes from OpenAM 9.5 (forgerock.com) to figure out. The code refers "local server name" to AM_SERVER_HOST.

private static final String localDsameServer = SystemPropertiesManager.get(

        Constants.AM_SERVER_HOST); 

OK, AM_SERVER_HOST should then be FQDN of the OpenSSO server.

Server Name is protocol://FQDN:port/opensso-uri

So, I'm up and running. I have the following in my Active Directory Primary Server:
osso1.xxx.xxx.xxx.sg|ad1.xxx.xxx.sg:636
osso2.xxx.xxx.xxx.sg|ad2.xxx.xxx.sg:636

I configured the reverse for my Active Directory Secondary Server:

osso1.xxx.xxx.xxx.sg|ad2.xxx.xxx.sg:636

osso2.xxx.xxx.xxx.sg|ad1.xxx.xxx.sg:636

Theoretically, this will definitely work. I was wrong! There is a bug in OpenSSO 8.0 U2.

The method getServerMapAttr() in CollectionHelper class is not able to detect that there are multiple entries. What's worse is it is not able to parse the String with the "|" to return the appropriate Active Directory server.

The code simply gets the first entry without any parsing and tries to connect. And of course, "Unknown host" is thrown.

Luckily, the code for this method in OpenAM 9.5 looks good. I copied and finally fixed the issue. 

Thank you, OpenAM!

.

An internal authentication error has occurred

I am near the final milestone of this IAMS project - deploying the Production environment.

We have a custom Authentication Module for this enterprise Single Sign-On infrastructure. I have done it many times in the development and staging environment and they worked!

However, I keep getting "An internal authentication error has occurred" when this custom Authentication module is turned on.

No choice. I need to turn on the verbose logging and this is what is been captured in Authentication debug log - "unable to find LoginModule class"

Ok, I must have made a mistake during the registration of the auth module via ssoadm.jsp. I think I must have key in only the Java class name without the full package path.

So I went ahead with ssoadm.jsp again to register with a full package Java class name.

Restarted OpenSSO server just to play safe. No luck!

Hmmm.... I recalled that in the days of Sun Access Manager 6.x and 7.x, there was no such thing as registering an authentication module via ssoadm.jsp. We did it manually and one of the steps was to add in the Pluggable Authentication Module Classes in Configuration > Core.

So I went ahead to verify the entries. Jackpot! 

Removing the last entry resolved the issue.


.

GlassFish + PostgreSQL server bundles

I'm pretty curious about the Take-Up Rate of GlassFish with PostgreSQL database bundle. Download here.

It has been a long while since I last worked on PostgreSQL database. Ever since I grabbed a copy MySQL, I have never turned back. Ha!



.

Pain upgrading to Oracle iPlanet Web Server 7.0.10

As part of the security/hardening measures of my current project, we are required to update every software component to the latest with patches. 

It's time to say bye-bye to Sun Java System Web Server branding. 

However, the upgrade experience wasn't pleasant... *Sigh*

Very strange - "Cannot upgrade the product from version 7.0U8 to 7.0.10" 


How can it be? This is not how Sun product works ... Every release should have a proper upgrade path. It has always been so.


What's the hack then?

Step 1: Go to /appl/opt/webserver7/setup
Step 2: Edit WebServer.inf

Step 3: Remove 8 from PRODUCT_SP_VERSION

Step 4: Remove U8 from PRODUCT_FULL_VERSION

Step 5: Done

Welcome to Oracle iPlanet Web Server 7.0.10!

.

ESSO product from PasswordBank

I have been involved with numerous SSO (Single Sign-On) projects - some of which are complemented by ESSO (Enterprise Single Sign-On) product.

Passlogix v-GO SSO was pretty popular. So popular that it's now being bought over by Oracle. So far, I have participated in 2 projects using Passlogix v-GO SSO. Pretty easy to configure if the user source is Microsoft Active Directory. A lot harder if Sun Directory Server is used as the user source. It's basically a Microsoft-centric product (my personal opinion).

Today, I came across a ESSO product from PasswordBank. Started in 2008, still a pretty young company.

This product differentiates itself by being able to support Desktop Platforms like Windows, Linux and Mac OS. This is something great! ESSO product has always been very Windows driven.

OpenSSO - Agents and Policies Entries in OpenDS

For this on-going project which I have been in-charge of since last August, I have been playing around with Agents and Policies more often than my previous projects.

Ever wonder where the configuration for the Agents is in OpenDS?

Answer is ou=AgentService, ou=services, ... :

How about the Policies? Where are they stored?

 Answer is ou=iPlanetAMPolicyService, ou=services, ... :

I find the latter most useful for me. Instead of creating policies via the OpenSSO Admin Console (which to me is pretty tedious), I'll go direct to OpenDS and edit the sunKeyValue for the xmlpolicy.

I'm lazy, maybe. :)

.

Active Directory Authentication Error via OpenSSO

We have configured OpenSSO Authentication Service to perform authentication via Microsoft Active
Directory.

We know that Microsoft Active Directory is able to detect first-time-login, password expired, account locked, account disabled etc ...

However, by using the in-built Active Directory Authentication module in OpenSSO, it keeps displaying the same error "Invalid credentials" whenever any of the errors is encountered. This confuses the users a lot. It also gives administrator wrong impression of what exactly is the error.


If a manual search is performed, the following is what we get:

bash-3.00# ldapsearch -h 192.168.131.50 -p 389 -D "cn=cclow,cn=users,dc=central,dc=sg,dc=sun" -b "dc=central,dc=sg,dc=sun" -s sub "objectclass=*"
Enter bind password:
ldap_simple_bind: Invalid credentials
ldap_simple_bind: additional info: 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 773, v1771


bash-3.00# ldapsearch -h 192.168.131.50 -p 389 -D "cn=cclow,cn=users,dc=central,dc=sg,dc=sun" -b "dc=central,dc=sg,dc=sun" -s sub "objectclass=*"
Enter bind password:
ldap_simple_bind: Invalid credentials
ldap_simple_bind: additional info: 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 533, v1771


Microsoft Active Directory has this habit of sending back error messages in 2 lines. The 1st contains what I call it General Error Message. The 2nd will contain the Actual Error Message ("additional info").

In this 2nd line, you need to tokenizes the message to grab the part that contains ", data xxx,". This will give you the Exact Error Message.

ldap_simple_bind: additional info: 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 533, v1771

So we went ahead to develop our own custom Active Directory Authentication module, and we have the following mapping:

public static final String ERROR_FIRSTTIME = "773";
public static final String ERROR_PASSWORDEXPIRED = "532";
public static final String ERROR_ACCOUNTLOCKED = "775";
public static final String ERROR_ACCOUNTDISABLED = "533";
public static final String ERROR_ACCOUNTEXPIRED = "701";


.

To Configure the OpenSSO Enterprise Deployment Against Cookie Hijacking

The OpenSSO Infrastructure which I had setup has just been configured to prevent Cookie Hijacking.

With this change, all my Policy Agents have to be re-configured. There's again this standard document from Sun. And once again, it disappoints me.

If your Policy Agents are deployed behind a load-balancer, then the above steps are not sufficient enough.

 You'll get the following errors:

ERROR: Invalid Agent: Could not get agent for the realm

What's the complete steps to configure for Cookie Hijacking Prevention?

Step a and b:

Step c:

Change Agent Root URL for CDSSO from host-based FQDN to load-balancer FQDN.

.

Yahoo Mail Filter is back!

I mentioned in my blog in February that I'm saying Goodbye to Yahoo Mail.

It has been a long while since I went into Yahoo Mail. I did that just. 

The Filter feature is available now!  Cool!

.

Backup OpenSSO Configuration Data in Embedded OpenDS

OpenSSO 8.0 U2 comes bundled with a super old embedded OpenDS. (Version 1.0.2)

The current version of OpenDS is 2.2.

Anyway, that aside, the embedded OpenDS comes with a number of sub-folders left empty.

E.g. bin, classes, lib

Without the executables in bin directory, there is no way to backup the configuration data which are all stored in the OpenDS.

What's the workaround?

1. Go to the j2ee-modules in GlassFish application deployment directory 

   .../j2ee-modules/opensso/WEB-INF/lib

2. Copy OpenDS.jar and je.jar to lib directory in OpenDS

3. Go to OpenDS 1.0 website

4. Download the zip file (Note: Do not download the latest OpenDS 2.2 zip file. It will bomb.)

5. Upload _mixed-script.sh, _server-script.sh, _client-script.sh and _script-util.sh to lib directory in OpenDS

6. Upload to executables to bin directory in OpenDS

For me, I'm only interested in backup, export-ldif and status since my environment is going LIVE soon.


.

Load Balancer in Front of the Web Agent

I continue to play with OpenSSO Policy Agent 3. This time round, I have 2 x Policy Agents deployed behind a load balancer. The Sun Web Server 7 acts as a Reverse Proxy to the backend GlassFish Application Server 2.1 running Sun Identity Manager.

Naturally, I'll follow the steps from Sun OpenSSO Enterprise Policy Agent 3.0 User's Guide for Web Agents. (Read here)


Oh mine!


The instruction was wrong and I spent a long time debugging the configuration steps. In the end, I had to read the source code for the Policy Agent for Sun Web Server 7.

The source was in C and C++. I'm never a C person. :) Another struggle.




The instruction to configure FQDN is OK.

Problems come when you start to read further down ...

If you map the above instruction to the UI in OpenSSO console (see below), you will never be able to find a way to configure the last property.

 In fact, the instruction should simply be Enabled or Not enabled.

The last property is supposed to be "Enabled". 


That's not all. There is another place where you need to make slight change:

The Agent Deployment URI Prefix should change from "Host-url/amagent" to "LB-url/amagent".


.