OpenAM Log Directory - Different School of Thought

There is a thread in OpenAM mailing list that discusses on how to re-configure the default log directory to a different directory.

With no offense to anyone, I have never find the need to change from the default setting in OpenAM via the Administration Console.

In most production environment, there is usually a dedicated filesystem partition for logging purpose. Our practice has always been to create a symbolic link from the default log directory to the dedicated filesystem partition - be it on Unix or Windows.

Nothing too difficult and easy to achieve. Why spend so much time trying to re-configure?

Different school of thought, maybe.

.

OpenAM Logging

If you have been debugging OpenAM a lot by looking through the debug logs set in MESSAGE level, you'll get "lost" at times as the logs can get very verbose.

Just saw this commit in OpenAM repository... 

Hopefully this enhancement helps!


.

OpenAM CTS Configuration Parameters - Root Suffix

Be careful if you use an external OpenDJ as the OpenAM CTS store.

The documentation has the following suggested root suffix.

It seems to suggest that root suffix for my deployment should look like "ou=openam-cts,o=xx.xx.sg". (RED arrow). However, during testing, I found out that sessions are created right under "ou=openam-cts,o=xx.xx.sg, and not the desired "ou=famrecords,ou=openam-session,ou=tokens,dc=openam-cts,o=xx.xx.sg".

The actual format for root suffix should be "ou=famrecords,ou=openam-session,ou=tokens,[your organization]".

This will create the OpenAM sessions nicely under ou=famrecords.


.

Quick note on OpenAM CTS stores

The following is extracted from OpenAM documentation (nightly maybe), but important:

• Prevent random or round-robin load balancing to external CTS stores. 
• No load balancer is needed between OpenAM and an external CTS store. Instead configure multiple directory server replicas in the Connection Strings of the configuration. 
• When OpenAM writes to a directory server in the external CTS store, directory server replication pushes the write to other directory servers in the same replication group. When under load operations in an OpenAM server can happen more quickly than the network can push replication updates. Therefore, balancing the LDAP traffic from OpenAM to the CTS store in random or round robin fashion leads to errors where a read operation arrives at a replica before the expected write operation can cross the network. 
• For complex deployments you might opt for an external directory service as the CTS store with a load balancer between OpenAM and the directory service. In this case, the choice of load balancing algorithm is important to ensure consistency under load within the CTS layer. High loads with a round-robin or random algorithm cause replication conflicts within the CTS layer, which the CTS layer is unable to resolve. The load balancer must operate only for failover, and not to balance LDAP traffic between directory servers. In other words, the load balancer in front of the external CTS store must use an Active/Passive configuration, whereby the load balancer sends all requests to the same directory server until that server becomes unavailable, and then all requests go to the standby directory server, and so on. Load balancers must not use an Active/Active configuration, as this leads to the type of errors described above.

.

FATAL ERROR: Cannot obtain Application SSO token

It has been more than a month since I last posted. How time flies? :) Happy New Year!

So, I did 2 marathons last month - Singapore Marathon 2014 and Taipei Fubon Marathon 2014. I kept my pace slow as these were supposed to be my built-up runs for a 100km race in Hong Kong next week.

Back to OpenAM…. :)

One could hit into this error fairly common - "FATAL ERROR: Cannot obtain Application SSO token".

Just a moment ago while I was configuring SSO Admin Tool for a customer, I hit into the error. Prior to hitting the error, I added a site in OpenAM console and assigned the only OpenAM instance to this new site. I also made sure that site name was added as a -D parameter in ssoadm script.

$ vi ssoadm
    -D"com.iplanet.am.naming.map.site.to.server=https://dsauth.abc.com:443/am=https://f50d.abc.com:3131/am" \

However, when the following command was executed, the error appeared!

$ ./ssoadm list-servers -u amadmin -f .pwd.txt

Logging configuration class "com.sun.identity.log.s1is.LogConfigReader" failed
com.sun.identity.security.AMSecurityPropertiesException: AdminTokenAction:  FATAL ERROR: Cannot obtain Application SSO token.
Check AMConfig.properties for the following properties
        com.sun.identity.agents.app.username
        com.iplanet.am.service.password
Logging configuration class "com.sun.identity.log.s1is.LogConfigReader" failed
com.sun.identity.security.AMSecurityPropertiesException: AdminTokenAction:  FATAL ERROR: Cannot obtain Application SSO token.
Check AMConfig.properties for the following properties
        com.sun.identity.agents.app.username
        com.iplanet.am.service.password
com.sun.identity.security.AMSecurityPropertiesException: AdminTokenAction:  FATAL ERROR: Cannot obtain Application SSO token.
Check AMConfig.properties for the following properties
        com.sun.identity.agents.app.username
        com.iplanet.am.service.password


Very strange indeed. Ah, maybe a restart of OpenAM will help. And yes, indeed!


$ ./ssoadm list-servers -u amadmin -f .pwd.txt

https://f50d.abc.com:3131/am

.