Wednesday, June 27, 2012

Password Reset Capability in OpenAM

Why do I like OpenAM that much after all these days (from Sun Access Manager, to Sun OpenSSO, to ForgeRock OpenAM)?

The answer is simple: it's highly flexible.

For automatic generation of a random password after a reset, there is always a default implementation - PasswordGenerator that comes out-of-the-box.

So what if this default implementation does not suit what your customers want? Write your own implementation! That's what I like about it - the flexibility to hook in my own plugin.

For password reset notification, the default implementation - NotifyPassword uses email medium to alert users.

If your customers require a SMS notification, what do you do? Write your own implementation! That's what I like about it. :)

Well, maybe not for those who do not like to code though. :>


How to enable old password prompt?

I'm preparing a POC for a customer in Thailand to showcase the capability of OpenAM integrated with their Microsoft Active Directory.

One of the requirement is to be able to change password, but the user must be prompted to enter his old password first.

The default Change Password UI from OpenAM has the filed greyed out.

To enable old password prompt, go to Configuration -> Console -> Administration. Enable "Prompt user for old password".

It's enabled now. Nice!


Saturday, June 23, 2012

LDAP Error 53: The LDAP server is unable to perform the specific operation

I was trying to configure a AD Data Store. 

It was pretty straight-forward to get the AD Data Store configured. If configured properly, all AD users will be displayed according in the Subjects tab.

So, I went ahead to create a new user. (OK, just for testing purpose. I have never used OpenAM to provision users in production before. There are far better tools in doing the same.)

BOMB! I received "LDAP Error 53: The LDAP server is unable to perform the specific operation" when I clicked OK.

What could have gone wrong?

LDAPv3Repo: Create called on IdType: user: forgerocker attrMap = {uid=[forgerocker], unicodePwd=xxx..., sn=[Rocker], inetuserstatus=[Active], givenname=[], cn=[Forge Rocker]}
LDAPv3Repo:06/18/2012 09:51:10:065 PM SGT: Thread[http-apr-8180-exec-1,5,main]
    : before ld.add: eDN=cn=forgerocker,cn=users,DC=az-ex,DC=sg
LDAPv3Repo:06/18/2012 09:51:10:207 PM SGT: Thread[http-apr-8180-exec-1,5,main]
ERROR: LDAPv3Repo.create failed. errorCode=53  0000001F: SvcErr: DSID-031A11E5, problem 5003 (WILL_NOT_PERFORM), data 0

LDAPv3Repo:06/18/2012 09:51:10:207 PM SGT: Thread[http-apr-8180-exec-1,5,main]
LDAPv3Repo.create failed
com.sun.identity.shared.ldap.LDAPException: error result (53); 0000001F: SvcErr: DSID-031A11E5, problem 5003 (WILL_NOT_PERFORM), data 0

at com.sun.identity.shared.ldap.LDAPConnection.checkMsg(
at com.sun.identity.shared.ldap.LDAPConnection.add(
at com.sun.identity.shared.ldap.LDAPConnection.add(
at com.sun.identity.shared.ldap.LDAPConnection.add(
at com.sun.identity.idm.plugins.ldapv3.LDAPv3Repo.create(
at com.sun.identity.idm.server.IdServicesImpl.create(
at com.sun.identity.idm.AMIdentityRepository.createIdentity(

A google search solves the issue.. the connection from OpenAM to AD must be in SSL mode. Read here and here for detailed explanation. This is due to the attribute unicodePwd in AD. 

So I went ahead to enable my AD for SSL and re-configure the AD Data Store in OpenAM to connect via SSL.

Well, the following error is ever so common ... "PKIX path building failed: .... unable to find valid certification path to requested target"

Always happen without fail if self-signed certificate is used. :) Well, importing the Root CA cert of the self-signed certificate into the cacerts store in JDK will resolve the issue.


Ignore User Profile in OpenAM

There are 4 ways to control whether a user profile is required for authentication to be successful in OpenAM.

The default is Required and the next popular is Dynamic. I have never tried Ignored before. 

So I went ahead to test what to expect if Ignored is chosen.

1. I created a AD authentication module
2. I purposely ignored creating a corresponding AD data store
3. I even went to the extend of deleting the default OpenDJ data store

The following is the screen when my AD user successfully authenticated - "You've logged in".
The end user console is skipped from displaying.

A session is still created when you navigate to the Session tab in OpenAM Admin Console.


Wednesday, June 20, 2012

OpenAM Active Directory Data Store

If you create an Active Directory Data Store post-installation, then you'll come across this screen. The instruction (see here) was clearly stated:

Before saving these settings ensure the 'Load schema when finished' check-box at the top of the page is selected, as this should install the OpenAM schema into Active Directory.

The LDIF file that contains the AD User schema can be found in [openam-config-directory]/ldif/ad/ad_user_schema.ldif.

So where will these schema be populated in the AD? I had a hard time finding them as I am not familiar with ADSI on Windows machine.

The trick was to select "Schema" for well known Naming Context!

There you go ...


Monday, June 18, 2012

OpenAM Logging

In OpenAM 10.0.0, there is an enhancement to the logging subsystem.

Previously, the log files in %BASE_DIR%/%SERVER_URI%/log/ are accumulated. And they can get really huge if no proper housekeeping is in place.

So the enhancement in this release is to implement log rotation (-1 implies no rotation).

To turn on log rotation, key in a value greater than -1 (1440 in minutes == 1 day). There is no need to restart OpenAM server.

Nice! The logs are now rotated every day.

However, the nightmare remains.... the logs in debug and stats directories remain unrotated. The next improvement should be the log files in these 2 directories. For the time being, nightly cron is still a must! :)

Updated on 21th Jun 2012

I was wrong about saying logs in debug directory remain unrotated. See OPENAM-41. It's there, but super not obvious only.


How to customize OpenAM Login Page?

The chapter Customizing the OpenAM End User Pages in the latest OpenAM 10.0.0 documentation has the steps to re-brand the OpenAM Login Page.

The most important statement in the document is "where suffix is the value of the RDN of the configuration suffix, such as opensso if you use the default configuration suffix dc=opensso,dc=java,dc=net" in Step 2.

This is where past document and/or wiki did not do a good job and thus caused confusion. Honestly, I could not make the customization to work until this latest document is released.

By following the instruction, I quickly located my configuration suffix, which is (take note not to  confuse with user data store suffix).

Then I was about to create the required directory, which is /path/to/tomcat/webapps/openam/config/auth/

It works!

Updated on 21th Jun 2012:

The following information is captured in Authentication log if you turn debug log to MESSAGE.


Wednesday, June 6, 2012

Account Lockout feature in OpenAM

I'm still playing with the latest OpenAM 10.0.0 in preparation of a upcoming overseas project.

I came across the Account Lockout feature in OpenAM.  

Go Access Control > / (Top Level Realm) > Authentication > All Core Settings ...

Scroll down a little and you'll see the Account Lockout section...

Note that this functionality is in addition to any account lockout behavior implemented by the LDAP Directory Server.

There has been questions asked many times regarding this feature. Many customers thought they can use this OpenAM UI to configure the setting in their backend directory server (Sun DS, OpenDJ or even AD).

This is totally wrong assumption. OpenAM is not capable of and should not even be capable of managing the backend directory server. It only provides a generic authentication mechanism to authenticate with any backend directory server.