Dell OpenManage Under 64 Bit Red Hat Linux

Table of Contents

1 Introduction

These instructions will show how to get an installed version of the Dell OpenManage Server Administrator (OMSA) to play nice with RSA SecureID (SecureID) on a 64 bit installation of Red Hat Linux.

It will also show how to correct the Secure Socket Layer (SSL) certificates so that security scanners such as Foundstone won't complain about the signature algorithm.

1.1 Some Notation

Our example server name is fake.server.com.

Lines that begin with SERVER# mean run this command, as root, on the server being set up.

Lines that begin with LINUX> mean any Linux machine, as any user, will get the job done.

code is usually a computer command.

Text in [[]]s are links.

2 OpenManage, SecureID RSA and 64 Bit Red Hat

When SecureID is installed on a 64 bit system, the 64 bit version of the RSA Pluggable Authentication Modules (PAM) is installed. This module is how the log in process talks to SecureID. No surprised there.

The problem is that OpenManage is a 32 bit application, and it wants to log in. This requires the 32 bit version of the PAM module. Fortunately the standard distribution of SecureID also comes with the 32 bit version of PAM. It just has to be installed.

2.1 Getting the 32 Bit Library

First, dig out the SecureID tar file that was used to install SecureID on the system. Details here are a bit specific to one release because different organizations use different packages.

Unpack the tar file into a temporary directory.

  LINUX> tar xvf RSA_100119.tar

Find the 32 bit version of the Linux libraries and extract it. In this example the file being looked for is pam_securid.so and it resides in aagent_60_PAM_96_060308/lnx32/sd_pam_agent.tar

  LINUX> cd aagent_60_PAM_96_060308/lnx32
  LINUX> tar xvf sd_pam_agent.tar pam/lib/pam_securid.so

2.2 Install the 32 Bit Library

Under Linux, 64 bit PAM modules are installed in /lib64/security. 32 bit PAM modules go into /lib/security.

Care must be taken to not overwrite the 64 bit pam_securid.so file. Make absolutely sure, before logging out, that logging in to the server works via normal channels after installing this library. If, somehow, the 64 bit library was clobbered, normal log ins will probably stop working unless you disable SecureID.

  SERVER# cp -i pam_securid.so /lib/security
  SERVER# chmod 644 /lib/security/pam_securid.so

2.3 Test It

Log in to OpenManage. Don't just connect to the server. Start with a fresh web browser so the log in won't be bypassed by a clever web browser. Log all the way in. Poke around to be absolutely sure before logging out of the install terminal.

3 Making Foundstone Happy

Web applications that use secure connections need an SSL certificate. Older applications or older versions of Red Hat create certificates that use "md5WithRSAEncryption" as the certificate signature algorithm. This is considered a security problem (Search the web for CVE-2004-2761 if you want more information). The solution is to generate a new certificate using a stronger signing algorithm. The current standard is "sha1WithRSAEncryption".

For self signed certificates it's not really a big deal, but it upsets some security scanners. Foundstone rates this as a "Medium" so it's easier to fix than to ignore.

3.1 OpenManage

One of the painful truisms is that graphic interfaces make some things trivial and other things imposable. Fixing the SSL certificate via the web interface falls into the "imposable" category. The interface can generate new certificates, but it won't change the signing algorithm. To do that an "out of band" solution is needed.

3.1.1 Check Out the Certificate

The first step is to verify that the application is using a questionable certificate. This is done by connecting to the server and querying the port.

By default the OpenManage port is 1311. Connect to it using the following command:

  LINUX> echo | openssl s_client -connect fake.server.com:1311 \
              | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \
              | openssl x509 -noout -text

Check for the first "Signature Algorithm:" line. If it reads "md5WithRSAEncryption" then Foundstone is unhappy and a new certificate must be generated. If it reads "sha1WithRSAEncryption" then the signature is good and nothing more needs to be done.

The certificate can also be checked using a web browser that allows you to view the certificate. Firefox allows this. Make a connection to the service with a URL like https://fake.server.com:1311. Click on the little lock icon in the lower right hand corner.

3.1.2 Where is the Certificate Kept

The certificate is kept on the server in a file called keystore.db. The command to access keystore.db is called keytool.

The default place for keystore.db is /etc/srvadmin/iws/config. keytool is in /opt/dell/srvadmin/jre/bin. If keystore.db isn't in the default location, use the locate command to find it.

To keep things readable, temporarily add /opt/dell/srvadmin/jre/bin to root's PATH variable.

  SERVER# PATH=/opt/dell/srvadmin/jre/bin:"$PATH"
  SERVER# cd /etc/srvadmin/iws/config

Make a backup and working version of the keystore.

  SERVER# cp -p keystore.db keystore_orig.db
  SERVER# cp -p keystore.db keystore_work.db

3.1.3 Verify the Keystore

A password is required to access the keystore. It's stored as plain text in the file keystore.ini. The default password is "password". The examples below assume that the default password is used.

Make sure that this is the right keystore. It should have a certificate with the alias "dell".

  SERVER# keytool -keystore keystore_work.db -list -alias dell

There should be an entry similar to:

  dell, Aug 26, 2010, PrivateKeyEntry,

3.1.4 Get the Certificate Issuer

The current issuer information can be used to minimize the impact of the certificate change.

  SERVER# keytool -keystore keystore_work.db -export -alias dell \
           -file /tmp/wc.cer
  SERVER# keytool -printcert -file /tmp/wc.cer
  SERVER# rm /tmp/wc.cer

There should be a line similar to this: (I've broken it up across multiple lines for readability)

  Issuer: CN=fake.server.com, O=Dell Inc, \
          OU=SA Enterprise Software Development, \
          L=Round Rock, ST=TX, C=US

There will probably be a line which reads:

  Signature algorithm name: MD5withRSA

The "correct" line will reads:

  Signature algorithm name: SHA1withRSA

3.1.5 Update the Certificate

The new certificate varies from the default in 2 ways. First it uses "SHA1withRSA" to sign the signature. That will shut up Foundstone. Second it makes the certificate valid for around 10 years (3650 days). Unless a server is an active target for spies, it doesn't need to have its keys updated yearly. Note: It the command below, the text after "-dname" is a single line of text.

  SERVER# keytool -keystore keystore_work.db -selfcert -alias dell \
            -keypass password -sigalg "SHA1withRSA" -validity 3650 \
            -dname 'CN=fake.server.com, O=Dell Inc, OU=SA Enterprise Software Development, L=Round Rock, ST=TX, C=US'

You can verify the new store with the technique used in the Get the Certificate Issuer section. Verify that the "Signature algorithm name" is "SHA1withRSA".

If all looks good, update the keystore.db file. It has been backed up, right?

  SERVER# mv keystore_work.db keystore.db

Restart all the services.

  SERVER# /usr/bin/srvadmin-services.sh restart

After about a minute everything should be back up.

Check the certificate via Check Out the Certificate.

Connect to OpenManage via the web browser to see if it's working.

3.2 OpenWsMan

The OpenWsMan project is intended to provide an open-source implementation of the Web Services Management specification (WS-Management). It may not always be installed with OpenManage, but, if it is, the certificate may need upgrading.

3.2.1 Is it Running

On the server run:

  SERVER# netstat -tulpn | egrep openwsmand

If nothing is printed then OpenWsMan isn't running. If this is printed:

  tcp  0  0  0.0.0.0:443  0.0.0.0:*  LISTEN  24411/openwsmand

then OpenWsMan is running on port 443 with a process id 24411.

3.2.2 Is the Certificate Upsetting Foundstone.

Check the certificate using the same technique used in the Get the Certificate Issuer section.

If the signature is "md5WithRSAEncryption" then it needs to be updated.

3.2.3 Finding the Certificate

Grepping for openmange in /etc/init.d shows the file /etc/init.d/openwsmand.

Checking /etc/init.d/openwsmand yields a reference to /etc/openwsman/owsmangencert.sh. The certificate is in /etc/openwsman.

3.2.4 Create a new Certificate

This certificate is created directly, without the intervention of keytool.

  SERVER# cd /etc/openwsman
  • Back up your Current state

    Back up the current certificate and the sever key. The server key wont be changed, but better safe than sorry.

      SERVER# cp -p servercert.pem servercert_orig.pem
      SERVER# cp -p serverkey.pem serverkey_orig.pem
    
  • Check the Old Key
      SERVER# openssl x509 -noout -text -in servercert_orig.pem
    

    If the first "Signature Algorithm: line reads "md5WithRSAEncryption" then a new certificate is required. If it reads "Sha1WithRSAEncryption" then no changes are needed.

    Also note the "Issuer:" line. Broken up on multiple lines, it will look something like:

      C=US, ST=New York, L=Buffalo,
      O=Company, OU=UNIX,
      CN=fake.server.com/emailAddress=someone@server.com
    

    This information can be used to generate a new certificate. Actually, there is no technical need to use the above information. Using it just minimizes the impact of the change. If there are more useful values feel free to use them.

  • Generate a New Certificate

    Because the certificate is being generated on the same machine the key resides on, a Certificate Signing Request (CSR) isn't needed. The generation can be done in one step.

    Note: Because a self signed certificate was generated for OpenManage earlier, care must be taken so that this new certificate has a different serial number than the OpenManage certificate. If they both have the same serial number, some web browser will kvetch. The -setserial flag solves this problem.

    The following command will ask you a series of questions. If you have no better values, then use the ones from the Check the Old Key section.

      SERVER# openssl req -set_serial 01 -sha1 -days 3650 \
                -new -key serverkey.pem -x509 -nodes -out servercert_new.pem
    

    The questions:

      Country Name (2 letter code) [GB]:US
      State or Province Name (full name) [Berkshire]:New York
      Locality Name (eg, city) [Newbury]:Buffalo
      Organization Name (eg, company) [My Company Ltd]:Company
      Organizational Unit Name (eg, section) []:UNIX
      Common Name []:fake.server.com
      Email Address []:someone@server.com
    
  • Check the New Key
      SERVER# openssl x509 -noout -text -in servercert_new.pem
    

    The Signature Algorithm: should read: "sha1WithRSAEncryption". The "Issuer:" line should look much like it did for the old certificate.

3.2.5 Update the Certificate

  SERVER# mv servercert_new.pem servercert.pem
  SERVER# /etc/init.d/openwsmand restart

Verify the certificate using the same technique used in the Get the Certificate Issuer section.

Author: Dale Wiles <dwiles@IgnoreMeModarnis.Com>

Date: 2010-08-29 15:05:08 EDT

HTML generated by org-mode 6.21b in emacs 23