Preparing to install Remedy SSO with the Remedy installer
This topic provides information that you can use to prepare your environment for installing the Remedy Single Sign-On (Remedy SSO) product by using the Remedy installer.
If you have installed an earlier version of Remedy SSO, for example, 9.1.00, and want to upgrade it to 9.1.03.001, do the following:
- Skip this installation section
- Review the system requirements and perform all preinstall steps mentioned in this section before upgrading Remedy SSO
- Proceed to upgrading Remedy SSO before upgrading the Presentation Server.
For more information, click the Planning the Remedy SSO deployment and Upgrading Remedy SSO links in the Related topics section.
Preinstallation requirements for Remedy Single Sign-On
Before installing Remedy SSO, you must have:
- Downloaded the zipped Remedy SSO files through the Electronic Product Download (EPD) or the Remedy SSO DVD.
- All the required hardware and software are available to install Remedy SSO. For more information on the system requirements, see System requirements.
- Downloaded latest stable version of Tomcat server 7.x or above installed. Remedy SSO installer does not include bundled Tomcat.
- Performed the installation and configuration of the Tomcat server outside Remedy SSO and before the installing Remedy SSO.
- Connected to the available database from the server where you install Remedy SSO.
- Configured the required security level for the installation environment. For more information about security requirements, see Security planning.
- Configured the sticky session on the load balancer or session replication enabled on the Tomcat instances if you are planning to use the Remedy SSO Admin console in HA mode, else the system displays the login page when the load balancer redirects the requests between different nodes.
Security Planning for Remedy SSO
Review the following sections to understand the security requirements:
For standalone installations, HTTPS has to be configured on the Tomcat server in the server.xml file. After the configuration, the interactions between the user and Remedy SSO node happens through HTTPS only. But the interactions between the supported BMC application and Remedy SSO node happens through either HTTP or HTTPS, depending on the relevant configuration.
For High Availability installations, HTTPS has to be configured on the load balancer. After configuration, while the interactions between the user and the load balancer happen through HTTPS connections, the interactions between the load balancer and the Remedy Single SSO nodes and the supported BMC applications happens through HTTP only.
Preventing Tomcat version exposure
Tomcat, by default, displays its current version number on an error page. An exposed Tomcat version can be used by an attacker to search for known exploits specific to that version. With this information, an attacker can develop a scenario that can exploit the vulnerabilities of the specific version that is being used by a target host. To secure the system from such an attack, you must configure the Tomcat settings to hide the version display.
You can use one of the following methods to hide the version number of Tomcat:
Also, for security reasons, ensure that the latest stable version of Tomcat server 7.x or later is installed.
Configuring the web.xml file
You can use the web.xml file to display a custom error page that does not contain the Tomcat version. If you have deployed multiple web apps into the ROOT folder, you need to update the web.xml for each of the applications. Consider that:
- Your web app is deployed into the Tomcat ROOT context.
- You already have custom error pages Errorpage_500.html and Errorpage_404.html for errors 500 and 404 respectively.
Perform the following steps to display the custom error pages:
- Go to the $CATALINA_HOME/webapps/ROOT/ directory.
Open the web.xml files and add the following code in the file.
<error-page> <error-code>500</error-code> <location>/errors/Errorpage_500.html</location> </error-page> <error-page> <error-code>404</error-code> <location>/errors/Errorpage_404.html</location> </error-page>
Test by sending a request for a non-existent file to your tomcat instance verify that your custom error page is displayed.
Configuring the ServerInfo.properties file
You can use the ServoInfo.properties file to display a custom error page that does not contain the Tomcat version.
- Go to $CATALINA_HOME/lib.
- Create the org/apache/catalina/util directory.
- Create a ServerInfo.properties file.
- Open the ServerInfo.properties file and the server.info parameter and set it to a value that you want the error page to display.
- Restart the Tomcat server.
- Test by viewing an error page and verify that the error page displays the value that you had set instead of the Tomcat version.
For example, consider that CATALINA_HOME is set to /home/tomcat. Run the following commands.
1. cd /home/tomcat/lib 2. mkdir -p org/apache/catalina/util 3. cd org/apache/catalina/util 4. $ vi ServerInfo.properties 5. Add the following parameter. server.info=Apache Tomcat Version X 6. cd $CATALINA_HOME/bin 7. ./catalina.sh stop 8. ./catalina.sh start
Securing session cookie for the Admin console of Remedy SSO
To secure the session cookie of the Admin console, modify the web.xml file located in the path <TOMCAT>/webapps/rsso/WEB-INF/ after installing Remedy SSO. Add the following code in the <session-config> element.
<cookie-config> <secure>true</secure> </cookie-config>
Database permissions for Remedy SSO
Ensure that you have database user credentials with permissions to create tables and read/write data to them or you have admin credentials to create such a user during installation. You can use the following script examples for creating such permissions:
Use a new database name for Remedy SSO to prevent the table name conflict for the Configuration table. If you are using Oracle, create a new schema for Remedy SSO before running the Remedy installer. At the time of installation select the new database.
CREATE DATABASE <database> CREATE LOGIN user WITH PASSWORD = <pwd>, DEFAULT_DATABASE = <database> USE <database> CREATE USER <user> FOR LOGIN <user> WITH DEFAULT_SCHEMA = dbo EXEC SP_ADDROLEMEMBER DB_OWNER, <user>
CREATE USER <user> IDENTIFIED BY <pwd> GRANT CONNECT, RESOURCE TO user IDENTIFIED BY <pwd> If you have Oracle 12c on the system, you must run the following script to provide a quota for a user on the tablespace. ALTER USER <user> quota unlimited on <tablespace name>
CREATE DATABASE "<database>"; CREATE ROLE "<user>" WITH LOGIN PASSWORD '<pwd>'; GRANT ALL PRIVILEGES ON DATABASE "<database>" TO "<user>"; GRANT ALL ON ALL TABLES IN SCHEMA public TO "<user>";
Sticky session for Remedy SSO HA load balancer
Starting from version 9.1.03.001, the Remedy SSO Admin UI does not need sticky sessions to function in an HA environment.
For earlier versions, the Remedy SSO Admin UI requires sticky session/Session Persistence in an HA environment. This is accomplished by enabling sticky session/Session Persistence on the load balancer. Different load balancers have different configurations to enable a sticky session/Session Persistence. Refer to the specific load balancer documentation or ask the vendor for detais about the configuration.
Note that when sticky session/Session Persistence is not enabled for the Remedy SSO Admin UI, the admin user behind the firewall can use a specific Remedy SSO server hostname to access admin UI instead of using the load balancer URL.