Posts Tagged ‘upgrade’

Quick guide to installing SiteMinder WAM R12 SP2

Friday, January 22nd, 2010

One of the major differences between SiteMinder Web Access Manager (WAM) R12 SP2 and pre-Sp2 is in the changes made in setting up the Administration UI. The SP2 installer comes with an option to choose between a pre-configured Jboss Application Server (JBoss [Trinity] 4.2.3.GA - to serve up the Administration UI components) and your other application servers (JBOSS, WebLogic or WebSphere). In addition to that, it appears that the complex method of configuring the initial administrative user has been removed. Prior installations required you to set up a user store and configure it with the right structure in order to set up the administrator login. These improvements have made it easy to set up SiteMinder R12 SP2 relatively quickly (under 30 minutes) and significantly less complex, which to me is key for those trying to get up to speed with R12.

For those of you who are not aware, R12 allows you to install SiteMinder Administration UI ‘clients’ that can exist on remote servers separate from the Policy Server instance. We’ll be installing everything on the same machine for this tutorial.

Just keep in mind that that you might need to run a client command utility called XPSRegClient to create a trusted relationship between the Administration UI client and the Policy Server when launched for the first time. The most common error that you’ll get is the “no registration on file” message when attempting to log into the Administration UI. See the ‘tips’ section for when you need to run this utility.

The goal of this mini-tutorial is to guide you through how to set up SiteMinder in a Windows environment using ADAM as a policy store (you should be able to use any other supported policy stores) and using built-in application server that ships with the installer – all on the same machine. This is especially useful for those that do not have time to comb through the installer guide.

NOTE: This tutorial should be applicable to the other installers available for Solaris, Linux, HP-UX and AIX.

1. Make sure you have JRE/JDK 1.5 (I’d recommend the most recent JRE/JDK 1.5 version to stay on the safe side) installed on the system that you are about to install SiteMinder on. This is a requirement for the SiteMinder Policy Server.

2. Go to http://support.ca.com and download the following installers:

a. CA SiteMinder Policy Server r12.0 SP2 for Windows-32-(ESD only)

b. Administrative UI Prerequisite Installer for Windows-32-(ESD only)

c. CA SiteMinder Administrative UI r12.0 SP2 for Windows-32-(ESD Only)

3. Configure a new ADAM instance (follow steps 1 through 4 in the Configuring ADAM as a SiteMinder Policy Store guide)

4. Unzip the CA SiteMinder Policy Server r12.0 SP2 for Windows-32 installer and run it.

5. Install SiteMinder R12 SP2. The installation should be straightforward.

a. Just make sure you choose the option to initialize the instance.

b. In the “Create SM Key Database”, it wouldn’t hurt to choose to import the default CA certificates (Certificate Authority).

6. Unzip the Administrative UI Prerequisite Installer for Windows-32 and CA SiteMinder Administrative UI r12.0 SP2 for Windows-32 installer into the same directory.

Admin UI Installer

NOTE: This is important because the Administrative UI prerequisite installer requires the layout.properties file from the Administrative UI installer and if it does not find it, it will abort the installation by indicating that it was unable to find the layout.properties file.

Error when cannot find the layout.properties file

7. Run the adminui-pre-req-12.0-sp2-win32.exe installer.

8. The only options you’ll have to specify is the location of the installation and the server and port number for the Administrative UI to exist on.

Picture 27

9. Once you’ve completed, the prerequisite installer will kick off the ca-adminui-12.0sp2-win32.exe installer automatically. If not, run it.

10. There is no additional configuration parameters to be entered during this install and might take a while to install as it compiles and configures the UI components on the application server.

11. Once completed, the installer will attempt to launch a browser and display the SiteMinder Administrative login:

SiteMinder WAM Administration UI Login

Note: Under the covers, this step starts the application server and registers the SiteMinder Administration UI with the Policy Server.

12. Use SiteMinder as the username and enter the super-user password that you specified during the SiteMinder Policy server installation. Leave the ‘server’ blank as it will default to using the local server and port (unless you have specified otherwise)

13. And you’re done! You should be able to proceed with importing your SiteMinder 6.x policies and viewing them in the new Administration UI.

SiteMinder Administration UI

Tips:

If the time difference between the time you installed the Policy Server and the time you installed the Administration UI is greater than 24 hours, you might need to run the following command if you see this error when trying to login to the Administration UI for the first time:

No registration on file error

c:\CA\Siteminder\bin>XPSRegClient siteminder -adminui-setup -t 1440 -r 5 -cp -l c:/logs/ -e c:/logs/error.log –vT

• (run XPSRegClient.exe without any parameters to get the catalog of option).

• The parameter ‘siteminder’ refers directly to the super-user

• You’ll be prompted to enter a passphrase, use the super-user password

This step is necessary to create a trusted relationship between the client and the policy server.

Another thing to note is that the built-in JBoss 4.2.3 application server runs on its own JRE (1.6.0_13) that is found in the adminui/runtime directory.
As you see, the updated R12 SP2 version of SiteMinder has made it significantly easier for users to install SiteMinder R12. Check this article for an overview of how you would plan your CA SiteMinder Upgrade to R12.

Tags: , , , , , , , , , , , , , ,
Posted in General | 7 Comments »

Planning Your Upgrade to CA SiteMinder R12

Friday, October 30th, 2009

toolboxCA SiteMinder Internet Access Manager R12 improves upon the functionality available in SiteMinder 6.x in several areas. In addition to fine-grained delegation through the new administration user interface, R12 improves directory mapping, adds support for web services, bundles federation support previously only available through the Option Pack and introduces fine-grained authentication capabilities. While these features warrant upgrade consideration on their own, an eventual end-of-life of SiteMinder 6.x will require an upgrade of your existing environment.

As you begin the process of upgrading your environment to R12, careful consideration is required to make sure the migration goes smoothly. New components like an application server are required and even the way policies are stored has changed with the addition of the extended policy objects. SiteMinder deployments provide mission critical functionality and the upgrade must be completed with minimal risk or downtime. To ensure a smooth upgrade path, ensure that you spend sufficient time planning for each phase of the move to SiteMinder R12.

Your Upgrade Strategy

As you look at your strategy for upgrading to SiteMinder R12, you need to consider the following:

  • Make sure that you have detailed information on each component of your SiteMinder environment
  • Understand your maintenance windows
  • Ensure that you have a good recovery and rollback plan
  • Map out the upgrade order of the components

Analysis

When breaking down your existing SiteMinder environment, keep in mind the following SiteMinder components:

R12 Upgrade

There are several things to consider as you analyze your current environment. Make sure that you minimally have the following details:

  • The number of policy servers and agents you have deployed and the versions of each component. The audit logs on the policy servers can be reviewed to capture this information.
  • Which policy servers are being used by each agent. While the host config object can provide some details here, don’t forget that the SmHost.conf file contains the bootstrap policy server for the agent and that information is not stored centrally. You can use the audit logs to help narrow this down further.
  • Determine if your agents are operating in failover or round-robin modes and which agents are providing single sign-on for unified applications. Careful review of the upgrade documentation is required to ensure that single sign-on and correct handling of failover and round-robin modes are maintained during the upgrade process.
  • Determine which authentication schemes are being used and ensure that there are no required configuration changes for those authentication schemes.
  • Map out all your 3rd-party and custom components. You will want to validate that your 3rd-party components are compatible with R12. Any custom components will require testing and may need to be recompiled.

Spending the time to collect this information will allow you to map out a detailed plan. You can combine this with information on your maintenance windows and off-peak times to minimize the upgrade impact and reduce risk.

Recovery Strategy

If you have the luxury of standing-up another environment and then migrating over to your new systems, recovery is simply a matter of switching back to the old environment. Similarly if you are using VMWare or similar virtualized systems, this give you the flexibility or taking your existing image, upgrading it and then deploying it while being able to roll back to the old image if needed. If you’re like most of us, the only way to do this is inline. Before upgrading, be sure to backup. Aside from backing up the machine, make sure you backup the following:

  • Policy store using smobjexport
  • Configuration files like the WebAgent.conf conf, SmHost.conf customized forms and other FCC’s, etc.
  • Web Server configuration files like Apache’s httpd.conf

Upgrade Plan

Once you have completed the analysis of the environment put together a plan that ensures that all components in the environment will remain compatible. The typical approach is to upgrade the policy servers first and then the web agents. This may change depending on the version of the agents deployed. Once you have run the installer for R12, you can’t revert back without uninstalling. So, make sure that you’ve mapped out a strong recovery strategy.

Make sure that you have tested the upgrade in several environments prior to rolling this out to production. Having a well documented and tested strategy takes some time to put together, but the reduced risk and post-upgrade issues is well worth the investment.

Stay tuned for additional information. We’ll be posting tips-and-tricks, troubleshooting and other information to our blog over our next few posts.

Tags: , , , , , , ,
Posted in Identity and Access Management | No Comments »