OpenSSO Enterprise 8.0 Update 1 Patch 3 (and later) includes the OpenSSO Diagnostic Tool, which allows you to run a number of diagnostic tests to verify configuration settings and to identify potential installation or deployment problems. This chapter describes how to run the Tamper Detection test on your OpenSSO Enterprise configuration settings and server bits.
After you unzip the OpenSSO Enterprise 8.0 Update 1 Patch 4 (or later) ZIP file, the Diagnostic Tool is in the ssoDiagnosticTools.zip file in the zip-root/opensso/tools directory, where zip-root is where you unzipped the Patch 3 ZIP file.
Create a directory for the Diagnostic Tool and its related files and then unzip the ssoDiagnosticTools.zip file in the new directory. The tool is available for these platforms:
Solaris and Linux systems: ssodtool.sh
Windows: ssodtool.bat
In this guide, diagnostic-tool-zip-root represents the directory where you unzipped the ssoDiagnosticTools.zip file.
The Diagnostic Tool requires JDK 1.5 or later. Before you run the tool, set your JAVA_HOME environment variable to a JDK 1.5 or later installation.
Note: Embedded quotes are not supported in the JAVA_HOME environment variable.
You can invoke the Diagnostic Tool in either CLI or GUI mode. First, change to the diagnostic-tool-zip-root directory and then invoke the tool as follows:
GUI mode (default):
Solaris and Linux systems: ./ssodtool.sh
Windows: ssodtool.bat
CLI mode, using the --console option:
Solaris and Linux systems: ./ssodtool.sh --console
Windows: ssodtool.bat --console
The default mode for the Diagnostic Tool is GUI. To change the default mode to CLI before you invoke the tool, set the following property in the diagnostic-tool-zip-root/config/DTConfig.properties configuration file:
odt.application.runmode=CLI
The Tamper-Detection test detects any changes made to the OpenSSO Enterprise server configuration settings or the deployed OpenSSO Enterprise server bits on the file system. To run the Tamper-Detection test, follow these general steps:
Run the Create Checksum test to create checksum files for the following:
OpenSSO Enterprise server configuration files and the OpenSSO Configuration Data Store
Note. The Tamper Detection test does not report configuration changes made if your configuration data store is remote in Sun Java System Directory Server.
Deployed OpenSSO Enterprise server bits on the file system
As a general guideline, run the Create Checksum tests after your OpenSSO Enterprise deployment is properly configured and functional. You must run the test twice, once for the configuration files and then again for the server bits.
Run the Detect Tamper test periodically to detect any changes made since the checksum files were created.
You must have unzipped the ssoDiagnosticTools.zip file and set your JAVA_HOME environment variable, as described in Getting Started With the OpenSSO Diagnostic Tool.
Log in to the system where OpenSSO Enterprise is deployed and change to the directory where you unzipped the ssoDiagnosticTools.zip file.
Invoke the Diagnostic Tool. For example, in GUI mode on Solaris Systems: ./ssodtool.sh
Under Category, select Tamper-Detection.
In Configuration Directory, specify one of the following paths:
OpenSSO Enterprise server configuration path. For example: /opensso
or
Web container directory path where the OpenSSO Enterprise server bits are deployed. For example, for Sun Java System Application Server 9.1:
/opt/SUNWappserver/domains/domain1/applications/j2ee-modules/opensso
Under Select Test, specify Create Checksum.
Click Run Selected.
The Diagnostic Tool creates a checksum file named _configdir-pathname.checksum in the diagnostic-tool-zip-root/services/tamperdetection/backup directory.
For example:
_opensso.checksum
_opt_SUNWappserver_domains_domain1_applications_j2ee-modules_opensso.checksum
Caution. The Tamper Detection test relies on the operating system security permissions to protect the checksum files. Depending on the requirements of your deployment, you might need to copy these files to a more secure location.
To save the results as an HTML file, click Save All Results.
The Diagnostic Tool logs all test results in the diagnostic-tool-zip-root/ssodtool.log file. Optionally, as required by your deployment, check and save this log file.
Repeat this procedure to create a checksum file for the other path in Step 4.
You must have unzipped the ssoDiagnosticTools.zip file and set your JAVA_HOME environment variable, as described in Getting Started With the OpenSSO Diagnostic Tool.
Important: The Tamper Detection test expects the checksum files to be in the diagnostic-tool-zip-root/services/tamperdetection/backup directory, where they were generated when you ran the Create Checksum tests. Therefore, make sure that the checksum files are in this same directory before you run the Tamper Detection test.
Log in to the system where OpenSSO Enterprise is deployed and change to the directory where you unzipped the ssoDiagnosticTools.zip file.
Invoke the Diagnostic Tool. For example, in GUI mode on Solaris Systems: ./ssodtool.sh
Under Category, select Tamper-Detection.
In Configuration Directory, specify one of the following paths:
OpenSSO Enterprise server configuration path. For example: /opensso
or
Web container directory path where the OpenSSO Enterprise server bits are deployed. For example, for Sun Java System Application Server 9.1:
/opt/SUNWappserver/domains/domain1/applications/j2ee-modules/opensso
Under Select Test, specify Create Detect Tamper.
Click Run Selected.
The Diagnostic Tool uses the checksum file in the diagnostic-tool-zip-root/services/tamperdetection/backup directory to determine if any files have changed since the checksum file was created. The tool determines if a file:
Existed and was changed
Existed and was deleted.
Did not exist and was added
To save the results as an HTML file, click Save All Results.
The Diagnostic Tool logs all test results in the diagnostic-tool-zip-root/ssodtool.log file. Optionally, as required by your deployment, check and save this log file.
Repeat this procedure to run the test for the other path in Step 4.
Examine the results to determine if your OpenSSO Enterprise deployment has been tampered with since you created the checksum files.