So one of the more challanging issues with Siteminder Web Agents on UNIX / LINUX is the way that shared objects are handled. I call the three general ways this can cause issues the Three P’s:

  1. Patch
  2. Path
  3. Permissions


whenever a webagent is patched you run the risk of mucking up the shared objects. Always backup everything before you start, never manually copy things in, and making sure that your environment scripts are correct is the easiest way to avoid this.


Historically, the .so libraries have been stored in the WebAgentHome/lib directory, but things have been moving to /bin for some time. bringing up the LLAWP webagent process with error -LLAWP: error while loading shared libraries: cannot open shared object file: No such file or directory.

Making sure that the PATH, LD_LIBRARY_PATH, and other environment settings are set correctly for the user, the users profile, and various start scripts is well documented on the CA support site and is always a good first place to start.


Definitely the hardest thing to troubleshoot–changes to the file system ownership is generally the root cause–someone doing chown -g dave or something so that the group permissions get all messed up can cause error while loading shared libraries: cannot open shared object file: No such file or directory type errors at startup which do not make much sense and are hard to find.

Make sure stuff like:

LLAWP /path/to/webagent.conf -APACHEversion



work is a good place to start.  Comparing closely with a working server is likely the only way to find these–be sure to pay attention to sym link permission.


Using SMPolicyReader to Correct Differences Between Tiers

I am currently using the SMPolicyReader to try to resolve differences between ACO settings in the various tiers [we use DEV/TST/STG/PRD].

Download from the community site. Unzip. Run the .bat file–there is video on youtube with more instructions.

Creating Exports
I generally use something simple like:

xpsexport e:\david\TST-Policy.xml -xb -npass -vT


There are a lot of issues–the first is naming standards. For the difference engine to work either the OID’s need to be the same [which is hard to control even with mature import/export strategies] or the names must exactly match. I am trying to use name match–going back and renaming ACO’s, updating WebAgent.conf, & then restarting is not that difficult–make a copy and clean up later is safest. In any event, even with the names exactly the same you can still see challenges:

This is because I did not select Options > Compare uses ObjectXID. Turing that off improves the comparison by only using name…


Trouble Shooting
Here is an example where a manual admin error was made on a rule which in most cases would be very difficult to track down–generally involving the need to troubleshoot with the app team. Here we can see that there is an obvious difference in the OnAccessReject rule:


Looks like it was a configuration issue in which the wrong Action was selected


Easy to fix–but stuff like that can be very hard to find sometimes, APP teams often don’t test it until it is too late, and human error is always a possibility.

There are still some challenges with the tool–it would be nice if there was a setting to ignore certain fields on certain objects.

I run into challanges on some objects with attribute values I do not understand or don’t show up on the admin console, for example here is an ACO setting for IgnoreURL=2 or =0–the value of the attribute in the console for both is the same.


Mobile Authentication: Key Considerations for Developing Your Strategy

Here are my unedited notes from today’s talk by David Gormley who spoke on Mobile Authentication from the CA Siteminder perspective:

Mobile authentication
Infrastructure that supports similar platforms
General set of platforms
Session mgmt
Policy centralization

Mobile devices are iniquitous
Help with other logons

Out of band authentication via mobile device
Key VOB on phone
Strong authentication embedded in phone
Risk based authentication. Transparent
Build auhn/Sdk in the app
Adaptive or RISK based auth
User behavior
Device identification
Device based rules
Ca products
User/pass across the board
Web and mobile
Social sign on
Session mgmt
Coarse grained API authorization. Limit transaction to one million etc
CA arcotID One Time Password
Available now from App Store
Protected seed values
Locked to a device

CA RiskMinder
CA AuthMinder

Take a holistic view
Understand options
Use web knowledge
Security vs convenience
Lock credentials to devices
Use browser based apps when possible.

Installing the Administrative User Interface

CA Communities has a new article which includes screen shot of Admin UI install.

Pasquale Russo wrote the piece which is clear and to the point–he covers Solaris [which I miss], but does have some warnings about how to do this in other environmnets.

I still apploaud CA for spending the time and energy in trying to clean up their UI–and expensive and thankless software excercies in all cases.However, this UI is still very clunky & does not support an ‘old school’ setting allowing admins to do ‘everything that they used to do’ in the same way, which I have constantly argued should always be a top priority.

In any event, a fun article in a growing community.

SiteMinder: Agent Keys

This one is a little old–but a great Tuesday Tip on Agent Keys.

Jeff Tchang‘s initial description of the keys, what they do, and how to trouble shoot is nice, but the real meat of the post comes in the comments when Josh Perlmutter provides information on how to export the keys & troubleshoot from that.

Very helpful tips.

User Authorization Cache

This  week the CA Tip is on AZ Cache.

The Policy Server caching framework is something that I have struggled with a lot over the years–I seem to think of ‘front end cache’ and ‘back end cache’–FEC is the stuff that is cached between policy server & web agent and BEC is the stuff cached between the policy server & user stores. I generally don’t worry much about what the policy server caches of the actual policies. I think I think this way mostly because the policies I work with are generally fairly simple & I just assume everything is in cache. Also, problems only seem to occur if something is slow going back to the User Stores.

I find this comment in the article very telling:

Please note that if a policy is bound to a user name (or DN, OU, and O); the Authorization Cache is ineffective because in this case there is no need to search the directory in the first place

The distinctions between CN or or OU is very interesting.

Also, this seems very interesting to me:

a) the cache limit is reached 25% random entries are removed

I have posted to the forums to try to get more information on this.