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".


.