Securing TEP with LDAP

We use a bunch of Tivoli monitoring products that connect into our central ITM (IBM Tivoli Monitoring V6.2.1) infrastructure. The focus point for operations is the TEP (Tivoli Enterprise Portal), where we use views, situations/alerts, etc, to monitor the current and historical status of the key components of our environment.

We secured access to TEP to restrict who can logon. We can give differenct users, access to different views. We secured access using  TDS (Tivoli Directory Server V6.1). Having had a few teething problems configuring TDS and ITM, we thought we’d share how we did it. In the following example we give access to a user from the WebSphere Message Broker operations team. The instructions below come in 4 sections, orientated around the product or component being administered.

A. Define a new user in TEP

1. Login to TEP. For example, point your browser at http://fitmps07:1920///cnp/client and enter the TEP username and password.  Before TEP has been secured, the username SYSADMIN (with blank password) can be used.
2. Click the Administer Users button.
   
3. Click on the Create Another User button.
   
4. Fill in the details of the new user. In this case WMB_OPS1. Click OK.
   
5. Set the user’s permissions, etc in the Adminster Users dialog and click OK.

B. Define a new user in TDS

1. Login to Tivoli Directory Server Web Administration Tool.
2. Click on Directory Management and Manage Entries.
   
3. Expand levels until your reach the level where you’d like your TEP user to reside (e.g. for us, ldap://fitmps04:389 > dc=lgi,dc=com > cn=users >cn=systemids). Click the Add button.
   
4. Set Structural object classes to inetOrgPerson and click Next.
   
5. Ignore Select auxiliary object classes and click Next.
6. Set Relative DN to uid=wmb_ops1, CN to WMB_OPS1, SN to ADMIN, and click Next.
   
7. Set givenName to WMB OPS User 1, set the userPassword, and click Next.

C. Configure TEMS to access TDS

Note: You only need do this section once. Once TDS and TEMS are talking, you can add other users simply bydefining them in TEP and TDS.

1. ./itmcmd config -S -t TEMS

   ...

   Security: Validate User ? [1=YES, 2=NO] (Default is: 1):

   LDAP Security: Validate User with LDAP ? [1=YES, 2=NO](Default is: 1):

   Enter required LDAP user filter ?(Default is: (&(uid=%v)(objectclass=inetOrgPerson))):

   LDAP base ?(Default is: DC=LGI,DC=COM):

   LDAP bind ID ? [ 1=anonymous bind, or enter a value ](Default is: CN=ROOT):

   LDAP bind password ?(Default is: ********):

   LDAP host name ?(Default is: fitmps04):

   LDAP Port Number(Default is: 389):

   LDAP SSL communications: Use SSL ? [1=YES, 2=NO](Default is: 2):

   ...

2. Restart TEMS and TEPS.

D. Test the TEP logon!

1. Login to TEP. For example, point your browser at http://fitmps07:1920///cnp/client.  Use the username and password you have just configured in TEP and TDS (e.g. WMB_OPS1).

Securing WMQ channels with SSL

The IBM® WebSphere® MQ (WMQ)  channels in the Mixed Platform Stack environment are secured with Secure Sockets Layer (SSL) to provide secure connections with privacy and data integrity. In this post we share the considerations and commands required to create the SSL certificates for:

• WMQ channels between queue managers
• MQLink between a WMQ queue manager and WebSphere Process Server (WPS)

Note that although the commands used to create the SSL certificates for our WMQ client channels are not listed, they are almost identical to those for WMQ channels between queue managers. The main differences being:

• Certificate labelling.
  • For a WMQ queue manager on AIX, ibmwebspheremq followed by the name of your queue manager changed to lower case (e.g. for QM01, ibmwebspheremqqm01).
  • For a WMQ queue manager on z/OS, ibmWebSphereMQ followed by the name of your queue manager changed to upper case (e.g. for QM01, ibmWebSphereMQQM01).
  • For a WMQ client, ibmwebspheremq followed by your logon user ID folded to lower case (e.g. ibmwebspheremqmyuserid).
• Certificate distribution and storage issues associated with machines that often not owned by WMQ administrators.

Our environment spans z/OS and AIX so we utilised RACF (z/OS) and GSKit (AIX) as certificate management tools, as well as using the Integrated Solutions Console to adminstrate WPS.

All the commands are added as a handy pdf attachment here:  WMQ SSL Instructions

We’ve left most of the WMQ commands out (e.g. the MQSC commands to create channel definitions, etc) as that is typically seen as the easy bit.

In addition to the actual commands, here are some of the factors our team considered when enabling SSL:

What signer model to use?

The two main choices are:

• Self-signed certificates – signed by themselves, so the distinguished name (DN) of the certificate matches the DN of the signer certificate (e.g. a queue manager’s certificate).
• Certificate Authority (CA) signed certificates – signed by a seperate entity, so the distinguished name (DN) of the certificate does not match the DN of the signer.

If using self-signed certificates, the public portion of a local queue manager’s certificate must be copied to the SSL keyrings of all the remote queue managers that wish to connect using an SSL channel. In a WMQ network involving many to many connections (e.g. a WMQ cluster) this can mean transferring every queue manager’s public certificate to every other queue manager’s keyring – this results in many signer certiificates in each SSL keyring and a lot of work moving certificates around! If using CA-signed certificates, the public portion of the CA’s certificate must be copied to the SSL keyrings of all the remote queue managers that wish to connect using an SSL channel – this results in only one signer certificate in each SSL keyring and relatively little work.

Self-signed certificate are often used in test environments as they can be created easily without the need to spend time or money on external certificate services. Although mostly seen as the quick and dirty method, self-signed certificates can be seen as more secure than CA-signed certificates because of the one-to-one relationship between certificate and signer, compared to the one-to-many relationship between certificate and signer with the CA model. For instance, imagine a CA provides two companies, A and B, with signed certificates. Now imagine that your company wishes to connect an SSL channel to company A. This requires that the public CA certificate is stored in your local SSL keyring. This now means that you trust company A, but is also means that you trust company B (which was not the intention). By using the SSLPEER channel attribute (see below), you can restrict connections, so that A can connect, but B cannot. When listening to the argument that self-signed certificates are more secure than CA-sign certificates, you have to remember features like SSLPEER, and also raise the question – Who do you trust more? The administrator that created their own certificate or a reputable company offering SSL certificate services?

CA-signed certificates are usually used in production. The CA can be one of the many reputable certificate service providers or can be an internal entity (e.g. an company’s internal security team). You can even combine these approaches by chaining certificates so that, for example, your queue manager certifcate is signed by an internal CA, and the internal CA’s certificate is signed by an external CA. If chaining certificates, each public certificate up the chain must be stored in the SSL keyring used when authenticating the queue manager’s certificate. The decision regarding the choice between internal CA, external CA ,or chained usually comes down to the following considerations:

• Mutual trust. For example, if a WMQ channel spans organisations, the two organisations require a trusted, independant entity to sign both their and their partner’s certificates. Using an internal CA based in one of the companies is not usually permitted by the other company.
• Cost. External CAs will charge for signing a certificate. In fact internal CAs may also use internal charging.
• Flexibility. Procuring a certificate might be quicker and easier from an internal CA than from an external CA (or sometimes, vice versa).

We chose to use CA-signed certificates rather than self-signed certificates because of the number of queue managers in our environment and associated workload of tranferring signer certificates. We chose to use an internal CA only, because our channels do not cross organisational boundaries, we had no budget to buy certificates, and our internal CA is quick and easy to use.

Where the internal CA is hosted?

This will usually be decided by a security team, but for our systems, where we are the security team, we used RACF on one of our z/OS systems. This was mainly because GSKit on AIX is not designed to be used as a CA, and we found plenty of useful RACF resources to make signing certificates trivial on z/OS.

Where will you create certificate requests?

It is possible to create certificate requests local to the certificate owner (e.g. on the machine hosting the queue manager) or on the CA machine or elsewhere. It would be acceptable to choose any of these options, but we chose to create requests local to the queue manager, assuming that owners of queue managers should be responsible for the request creation.

Removing unwanted CA certificates from key databases

SSL key databases often come pre-filled with public certificates of major CAs. These should be removed unless they are being used. If you leave surplus CA certificates in your key databases, any queue manager or client holding a certificate signed by those CAs can connect to your queue manager. This risk can be mitigated by using SSLPEER (see below), but it’s best practices to keep your key databases as clean as possible.

Use of SSLPEER to restrict connections

Even if you remove all surplus CA certificates from your key database, leaving just the one for your CA, anyone holding a certificate signed by that CA can connect to your queue manager. In order to restrict connections to only those who you trust, you can use the SSLPEER channel attribute. This feature compares the string pattern in the SSLPEER channel attribute to the disinguished name (DN) in remote partner’s certificate. Only those with matching DNs are allowed to start channels. So if you set your local receiver channel’s SSLPEER to “CN=QM2, OU=FIT, O=IBM”, remote partners must have that DN or the channel will not be able to start. This is easy where a one-to-one mapping between channel endpoints exists (e.g. with a typical sender-receiver channel) because the SSLPEER can be set specifically to the single remote partner’s DN. But where a one-to-many mapping exists (e.g. with a cluster receiver or server connection channel) the SSLPEER must be more generic in order to allow the many remote partners to connect in through the single channel definition. Typically this means avoiding the use of specific DN attributes in the SSLPEER (e.g. not using the CN attribute in “OU=FIT, O=IBM”) or using wildcards in the SSLPEER (e.g. “CN=QM*, O=IBM”).

Use of SSLCAUTH to force the client to be authenticated

The SSL protocol supports either one-way authentication, where the client authenticates the server, or two-way authentication, where the client authenticates the server and the server authenticates the client. There are many SSL scenarios where one-way authenication is preferred. For example, your web browser client will often connect to a web server,and typically your browser will not have a certificate, but you will wish to ensure that the server is trusted. In this example, only the server holds an SSL certitficate. For our WMQ cluster environment and other SSL secured connections, we required two-way authentication so we set the SSLCAUTH channel attribute to REQUIRED.

Considerations for SSL in WMQ clusters

For further considerations and a step by step guide see Enabling SSL in an existing WebSphere MQ cluster.

And in conclusion…

… there is a lot more to WMQ security beyond SSL channels, but hopefully you found these tips and commands useful. Comments, as usual, most welcome!

Monitoring Server Energy Usage (Part Two)

The previous post explained how to use IBM Active Energy Manager to obtain power usage data from servers and other datacenter infrastructure. This post will explain the steps necessary to collect this data within IBM Tivoli Monitoring (ITM).

For the purposes of this post, it is assumed that an existing ITM environment will be extended to collect power usage data. The installation and configuration of the base ITM components will not be covered.

This post is split into two sections Active Energy Manager and Tivoli Enterprise Monitoring Server. To allow ITM to monitor energy usage software must be installed on each of these components. The installation and configuration for each component is covered in the appropriate section. These components may reside on the same system or on multiple systems. In the case described in this post, the components are installed on separate systems.

Active Energy Manager

To allow the energy management features provided with Active Energy Manager to communicate with ITM, the following ITM components must be installed on the Active Energy Manager server:

• Monitoring Agent for Linux OS
• Active Energy Manager Agent

To install the Monitoring Agent for Linux OS, extract the installation media into a temporary directory. From the location where you extracted the media run the following command:

• ./install.sh

Accept the default installation directory /opt/IBM/ITM and either allow the installer to create the directory if it does not yet exist or reuse it if it does already exist.

Select the option to “Install products to the local host.”

The license agreement will be presented which you will need to accept to continue. At this point you may be asked to provide an encryption key. If you are asked to provide this, you must use the same encryption key as used by your TEMS installation. This is necessary to enable the agents and TEMS to communicate.

When presented with the operating system selection screen, select the option that matches the operating system version and architecture being used on your system, in our case this is “Linux Intel R2.6 (32 bit)”. Note that the menu items for the agent may vary dependent on the components shipped on the media you are using. In our case the correct option is option number 10.

You will now be presented with the product selection screen from which you should select the appropriate monitoring agent to install. In this case you need to choose the Monitoring Agent for Linux OS V06.21.00.00. The other types of agent listed (Agentless and Universal Agent) are not required.

Once the installation has completed successfully, you will be asked whether you wish to install additional products, choose No to complete the installation and exit the installation program.

The steps to install the Active Energy Manager Agent are the same as for the Monitoring Agent for Linux OS. You should run the install.sh script from the install media to start the installation program. At the product selection screen you should choose to install Active Energy Manager Agent V06.20.01.00. Once the installation is complete, the next step is to configure the two agents.

Configuring the agents for Active Energy Manager (GUI method)

The agents must now be configured to communicate with the Tivoli Enterprise Monitoring Server (TEMS). here are two methods that can be used to configure the agents graphical and command line. Both of these are started using the itmcmd command which can be found in /opt/IBM/ITM/bin assuming that you are using default install locations.

To use the graphical configuration interface enter the following command:

• /opt/IBM/ITM/bin/itmcmd manage

To configure an agent, right click on the agent and select Configure from the menu.

On the configuration screen specify the values for TEMS Hostname, Protocol and Port Number that are appropriate in your environment. The screenshot below shows the values

Note that you must configure each agent that you wish to use. To enable energy monitoring you must configure both the Monitoring Agent for Linux OS and the Active Energy Manager Agent. The configuration for both agents is identical and is as described above. Once the agents have been configured they can be started. To start the agents, select the appropriate agent and select Start Service either from the Actions menu or the context sensitive menu accessed with the right mouse button.

Configuring the agents for Active Energy Manager (Command line method)

If you wish to configure the agents using the command line, you must know the product code for the agent you wish to configure. The product code is a two character code that uniquely identifies each agent. A comprehensive list of IBM Tivoli Monitoring 6.x product codes can be found here.

From the list of the product codes, we find the product codes we need are lz for the Monitoring Agent for Linux OS and e9 for the Active Energy Manager Agent.

To use the command line to configure the Monitoring Agent for Linux OS enter the following command:

• /opt/IBM/ITM/bin/itmcmd config –A lz

To use the command line to configure the Active Energy Manager Agent enter the following command:

• /opt/IBM/ITM/bin/itmcmd config –A e9

The configuration information required for each of the agents is identical. The values used in our environment are as follows:

• Will this agent connect to a TEMS? : YES
• TEMS Host Name : Specify the fully qualified hostname of your TEMS server
• Network Protocol : Specify ip.pipe to use a TCP/IP connection
• Network Protocol 2 : none
• IP.PIPE Port Number : 1918 (this is the default port for TEMS)
• Enter name of KDC_PARTITION : Accept the default
• Configure connection for a secondary TEMS : NO
• Enter Optional Primary Network Name or 0 for “none” : 0

The agent will then be configured and the following message should be displayed:

• Agent configuration completed… 

If you wish to view the current configuration of a given agent enter the following command:

• /opt/IBM/ITM/bin/itmcmd config –A –g e9

The above example will return the configuration for the Active Energy Manager agent. To obtain the configuration for a different agent use the appropriate product code in place of e9.

Once the agent configuration has been completed, use the following commands to start the agents with the appropriate product codes:

• /opt/IBM/ITM/bin/itmcmd agent start e9
• /opt/IBM/ITM/bin/itmcmd agent start lz

ITM

The following steps should be carried out on the systems where Tivoli Enterprise Monitoring Server and Tivoli Enterprise Server components of ITM are installed. These steps install and configure support for energy monitoring. Obtain the IBM Tivoli Monitoring for Energy Management Media (ITMfEM). Extract the installation media to a temporary directory and run the following command from the directory containing the extracted media:

• ./install.sh

Any components that are running need to be stopped for the installation to continue, the installer will stop and restart these components for you. As with the agent installations described above, you should to install products to the local host and accept any license agreements. You should select the following options for installation:

• Active Energy Manager Agent V06.20.01.00 @ Tivoli Enterprise Portal Browser Client support
• Active Energy Manager Agent V06.20.01.00 @ Tivoli Enterprise Portal Server support

Once the installation has completed, it is necessary to configure TEMS and TEPS to support the newly installed features.

To configure TEMS run the following command:

• /opt/IBM/ITM/bin/itmcmd support –t TEMS e9

To configure TEPS run the following command:

• /opt/IBM/ITM/bin/itmcmd –A cq

Assuming that you are using TEMS and TEPS that have been previously configured you should be able to accept the defaults presented by the configuration tools. These defaults will be the values previously used to configure those components.

Once you have completed these steps, you should restart TEMS if it was not restarted automatically. Energy usage data should now being collected in ITM. The final post in this trilogy will show the types of data collected by ITM and how this data can be used.

Monitoring Server Energy Usage (Part One)

This post covers the first steps to monitoring energy usage using IBM Tivoli Monitoring for Energy Management. This product uses IBM Director and the associated Active Energy Manager product to retrieve power information from systems. This data can then be provided to IBM Tivoli Monitoring for use alongside other enterprise monitoring data. This post covers the installation and configuration of the Active Energy Manager and IBM Director components. The IBM Tivoli Monitoring configuration will be covered in a later post.

For the purposes of this post, it is assumed that you do not currently use IBM Director. You can obtain a trial download of Active Energy Manager from here.

For this post, we used Active Energy Manager Standalone for Linux on x86 which is provided by the file ActiveEnergyManagerSA-3.1.1-2.i386.rpm. This package installs IBM Director and the appropriate plugins necessary to monitor and manage the power utilisation of your servers. This version was used as it is a supported configuration for energy monitoring with IBM Tivoli Monitoring for Energy Management.

To install the package, copy the installation file to a directory on the target machine and from that directory run the following command:

• rpm –ivh ActiveEnergyManagerSA-3.1.1-2.i386.rpm

The Active Energy Manager components will be installed in /opt/IBM/director. The following basic commands can be used against the server:

• To obtain the server status: /opt/IBM/director/bin/twgserver status
• To start the server: /opt/IBM/director/bin/twgserver start
• To stop the server: /opt/IBM/director/bin/twgserver stop

Once the server is started, you can use the IBM Director Console to discover systems and view the power usage of those systems. To start the console issue the following command:

• /opt/IBM/director/bin/twgcon

The IBM Director Console should start and display the following screen:

The first step is to add the systems you wish to monitor to Director. In our case we are going to monitor several IBM Power Systems servers. These servers are managed using a Hardware Management Console (HMC).

To make these systems visible to IBM Director, the HMC must be added as Managed Systems. To do this select the following menu options: Console –> New –> Managed Objects –> HMC. This is shown in the screenshot below.

On the next panel enter a descriptive name for the HMC and the hostname or IP address for the HMC then click OK.

The HMC should now be listed in the All Managed Object screen in the Director console. In the screenshot below you can see that the HMC object has a padlock icon, this means that authentication information is required before Director can communicate with the HMC.

To supply the authentication information, right click on the HMC object and select Request Access.. as shown below.

You will be prompted to supply a valid user ID and password that has access to the HMC. In the example below we use the default HMC root user which is hscroot.

The message below will be displayed if Director can successfully authenticate with the HMC.

Director will then query the HMC to discover all of the physical and logical systems managed by that HMC. This may take some time dependent on the number of systems managed by the HMC. Once this has completed, the view will be populated with the physical and logical systems and the console will be similar to the screenshot below.

At this point everything is in place to begin looking at the power usage of your servers. To look at the current power data select the following menu options: Console –> All Managed Objects –> Active Energy Manager. This will start the Active Energy Manager and will bring up a screen showing you the power overview of all of the physical systems that power data is available for. This screen is shown below and gives the average power usage for all managed systems and overview data for each individual system.

You can get more detail on an individual system by clicking on the system of interest from the list of systems.

 

There are other functions that are available through this user interface including the ability to set power management options and view the cost of the energy consumed.

Should you wish to add this functionality to an existing installation of IBM Director then you will need to ensure that you have IBM Director 5.20.2. You will need to install the Blade Center Management Extension as this is prerequisite to the Active Energy Manager extension. Once you have installed this, you can install the Active Energy Manager extension. Once you have these installed and configured, you should be able to follow the steps as detailed above.

The next post will explain how to configure the Active Energy Manager to work with IBM Tivoli Monitoring for Energy Management.

WebSphere Application Server 7.0 migration

Recently the team have been working on a project to migrate WebSphere Application Server to the latest release V7.0 on AIX. As part of this project we’ve produced a white paper that documents our experiences. There are already several excellent articles and documents relating to the migration process for WAS, so what’s different about this one?

As an integration test team, a big concern for us is the impact of additional products on the migration process.

Our WAS environment integrates with various other products including WebSphere MQ, DB2, Tivoli Directory Server and ITCAM for WebSphere.

The document covers the process of migrating development, test and production environments in detail. Finally, the document provides an extensive set of references to other documents that proved useful while performing the migration.

Although the document focuses on AIX, people who are using other platforms should still find the information relevant and we’re happy to talk about any questions that may arise.

You can find the document at IBM Techdocs.

We’re currently working on a similar document that will cover the migration of WAS to V7.0 on z/OS. As with the document mentioned in this post, the focus will be the impact of additional products such as WebSphere MQ and DB2. We’re currently aiming to release this document before the end of June. We’ll be sure to announce it as soon as it’s ready.

How we test

The testing carried out by our team is based around two fictional insurance companies called LGI and DC. LGI is an established insurance company with a long history. The technology behind their business is primarily mainframe based and makes use of products such as CICS and DB2.

DC is a recent entrant to the insurance market. Their primary channel is the internet and they have strong skills in web technologies on non-mainframe platforms.

The scenario concerns the merger of these two companies. The two companies are merging to gain the benefits of each others experience with different technology platforms and customer channels.

So why do we use a scenario in our testing? Why don’t we just connect the products together and see what happens?

The products we’re testing are used in conjunction with each other to achieve a business goal. We use a scenario to help us to focus on the business value of the products that we test. We’re interested in more than just the technology. Hopefully by anticipating the business ways in which people will use the products, we can try and address the technical concerns and make the integration of those products easier.

Full detail about the scenario we use can be found in the first chapter of the IBM Redbook: The Mixed Platform Stack Project: Deploying a Secure SOA Solution onto z/OS and Mixed z/OS and AIX Environments.

A common question we hear is: Why did you choose an insurance company?

The choice of scenario was in some ways relatively arbitrary. We picked a company that most people will interact with at some point in their lives. This makes the scenario easier to explain and allows us to show how a technology can solve a particular business problem. A key point is that the work we do isn’t specific to the insurance industry. The technologies we test can be applied to business problems in a variety of different industries.

We’d be very keen to hear how you use the products we work with  both from a business value perspective and the technical details.

The Beginning

This seems as good a place as any to start from so what’s this all about? This blog has come about as a way for us to talk about the integration testing that our team carry out. We use a customer-like scenario to ensure that the testing we perform is relevant to real-world usage of the products being tested. We test products from all of the IBM Software Group brands.

Our test environment has the following characteristics:

• Customer-like
• Highly available
• Secure
• Long running

We use only publicly available information to deploy and maintain our environment. We aim to resolve issues we find with the products through standard customer support channels.

The products that we test in our environment currently include:

• WebSphere Application Server V6.1 and V7.0
• WebSphere MQ V6.0 and V7.0
• WebSphere MQ File Transfer Edition V7.0
• WebSphere Message Broker V6.1
• WebSphere Portal Enable V6.1
• WebSphere Process Server V6.1
• WebSphere Service Registry and Repository V6.1
• Tivoli Composite Application Manager for WebSphere V6.1
• Tivoil Omegamon XE for Messaging
• Tivoli Directory Server
• CICS 3.2
• DB2 V9.1
• IBM HTTP Server V7.0
• IBM Tivoli Monitoring
• Rational Application Developer
• WebSphere Integration Developer
• WebSphere Message Broker Toolkit

Our testing covers several different platforms and we aim to show that these products can be deployed and successfully integrated regardless of the platform mix involved. The platforms that we cover in our testing include:

• AIX
• Linux for x86
• Linux for System z
• Windows
• z/OS

If you’re interested in more detail about our work you can read the IBM Redbook: The Mixed Platform Stack Project: Deploying a Secure SOA Solution onto z/OS and Mixed z/OS and AIX Environments.

We’re also really interested to hear any thoughts you may have about the kind of testing we’re carrying out. Are there additional products you’d like to see in our environment? Are there specific types of integration between products that interest you? Let us know, we’d love to hear from you.

Over time we aim to add (hopefully) useful hints, tips and experiences relating to our testing of these products to this blog.

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!