Skip navigation
Share This:

In this post we'll take a look at configuring Kerberos for authentication for with Remedy Single Sign-On & troubleshooting any errors we may come across along the way.


Versions used in this blog

RSSO 18.02 build 9 (load balanced

Active Directory Windows 2012

Remedy Midtier 9.1.0 (load balanced

The servers are in a domain called, the users in Active Directory will be in a different domain called


Why are we configuring users in a different domain to the servers?

There has been a few support calls raised with BMC support with this type of configuration, so we'll run through this as the configuration in this post. If the users and servers are in the same domain, it will be configured in exactly the same way.


Creating the Service Principle Name for RSSO on the KDC

There are a few ways to creating service principles on the KDC to use with RSSO. But the format of the creation will ultimately be the same. To start with we need to create a user in Active Directory. We can either create a standard user or a managed service account, either one will be valid, in this post we'll cover creating a user in the normal manner and map a service to it. This procedure a function of the domain administrators and should be sent to them to action.


In our case we'll be creating a user account called "MYRSSOPRINCIPLE" as a standard user in active directory. We'll set the password options "User Cannot Change Password" and "Password Never Expires" The password expiry will be dictated by domain policies (fig1)




The default group of "Domain Users" will be added to this user (fig2). Since the user will never actually physically log in to any machines this can be removed, but you will need to have another group created (perhaps with no login control) since all users require a primary group. In this instance we will leave it as a member of "Domain Users". Normally no other permissions are needed. You may need to add some other permissions for this user depending how the AD & KDC are configured, we'll cover this at a later on in the troubleshooting section.




The next step is to create the HTTP service class and map it to our user.


The HTTP service class

The HTTP service class differs from the HTTP protocol. Both the HTTP protocol and the HTTPS protocol use the HTTP service class. The service class is the string that identifies the general class of service. Well-known service class names include "www" for a Web service and "ldap" for a directory service. Generally, the service class name can be any string that is unique to the service class. Be aware that the SPN syntax uses a forward slash character  to separate elements. Therefore, the forward slash character  cannot appear in a service class name.


To map the service (which in this case will be used by our RSSO server) we'll need to run the "setspn" command from the KDC server command line, with the following format


setspn -S HTTP/severFQDN USER


-S : add arbitrary SPN after verifying no duplicates exist

HTTP/ : Service Class

ServerFQDN : The computer that is going to be using this service or the LB FQDN

USER : The user that we want to map the service to


So in our example we will run the following setspn command


setspn -S HTTP/ MYRSSOPRINCIPLE  (fig3)  So this command is saying map the HTTP service class, for use by to my user called MYRSSOPRINCIPLE, but before doing this check that there is no other service called mapped to any other user. If running in an LB environment as in our case, there is no need to also map the individual server names since everything will be going through the load balancer, but in some instances depending how the the KDC is configured you may need to do this, we'll cover what log messages to look at when this is needed in the troubleshooting steps below. If you do need to do this then add the invidividual severs in the same way as before by running the setspn -S command, doing this won't cause any issues even if you don't need it. Run the following command to add the individual servers





So now we will have three services mapped to our user called MYRSSOPRINCIPLE



Running the setspn command in this case has thrown a "duplicate SPN found, aborting operation!" message Fig(3)  . This often occurs especially when a Managed Service Account has already been created and the service mapped



We can see above that we can't map our service to our user MYRSSOPRINCIPLE because this service is has already been mapped/registered with another user called "RSSOPRINCIPLE"

as we want to use the user "MYRSSOPRINCIPLE" we will need to delete/unregister the service to the user, to do this we'll need to run setspn with the  -D parameter (fig4). Sometimes you will see that there are multiple users that this services is registered to, this should not happen but it does and will need to be deleted.





Once the delete command has been run, we can continue to map the service with our use again and should not get the duplicate SPN message (fig5)


setspn -S HTTP/ MYRSSOPRINCIPLE  For completeness we've also added the individual server names ( &




You can view the registered service by using setspn with the -L parameter (fig6)




Now we have our SPN created and services mapped. Normally this is enough and you would then continue to configure on the RSSO admin console. On the RSSO admin console there are two options to have RSSO connect to the KDC with the service principle user. One method is password, if the KDC allows SPN accounts to connect with a username and password then we are pretty much done. The second option on the RSSO admin console is to use a keytab file. A keytab file is generally for SSO when the KDC denies direct login with username and password. The keytab is a file containing pairs of Kerberos principals and encrypted keys. You will still need to run create the user and run the setspn command above before creating the keytab file.


Createing A Keytab File

This is an domain administrator function and these instructions should be action by the domain administrator, along with the create user and setpn commands above.


Open a command prompt and run the following command to create the keytab file



ktpass -out <outfile> -mapuser <PRINCIPLEUSER>  -princ <servicename> -pass PasswordOfMappedUser -ptype KRB5_NT_PRINCIPAL -crypto <cryptography type>


-out theoutput : file, the path and filename of the keytab file you want created

-mapuser :  The username you want to map the service to

-princ : The service class name

-password: password of the mapped user

-ptype:  Specifies the principal type.Type include

              KRB5_NT_PRINCIPAL is the general principal type (recommended).

                   KRB5_NT_SRV_INST is the user service instance.

                   KRB5_NT_SRV_HST is the host service instance.


-crypto: cryptography type to be used. Includes

              DES-CBC-CRC is used for compatibility.

               DES-CBC-MD5 adheres more closely to the MIT implementation and is used for compatibility.

               RC4-HMAC-NT employs 128-bit encryption.

               AES256-SHA1 employs AES256-CTS-HMAC-SHA1-96 encryption.

               AES128-SHA1 employs AES128-CTS-HMAC-SHA1-96 encryption.

               All states that all supported cryptographic types can be used. Note: The default settings are based on older MIT versions. Therefore, /crypto should always be specified.


In our case we are going to run the following ktpass command


ktpass -out c:\rssokeytab -mapuser MYRSSOPRINCIPLE -princ HTTP/ -pass Secret&c0mplex -ptype KRB5_NT_PRINCIPAL  -crypto all

The command will do the following:  map MYRSSOPRINCIPLE user to a service called HTTP/ served by domain with a principle type of KRB5_NT_PRINCIPLE with all available cryptography and create the keytab file called c:\rssokeytab  (fig7)




Some issues that might occur when running the keytab command is using complex passwords with the username, the solution try a simpler password. When pasting the command from

a text editor some unseen characters might be pasted, this will make the keytab command fail, the solution is to type it directly into the the command prompt.


Once the keytab command is run successfully, two things will happen 1. The keytab file will be created in the path and name specified (fig8).



2. When viewing the user properties account details you will see instead of the userID the service name (fig9) take a note of the User Logon name and and the @ domain portion you will need this later on in RSSO configuration (in the same format)




The next step is to configure RSSO. If you created a keytab file copy it to the rsso sever if in an LB environment copy it to all RSSO servers.


Configuring Kerberos on the RSSO Admin Console


On the RSSO admin console, go to realm --->Add Realm and select Kerberos from the dropdown list and fill in the information.


KDC Server: The KDC server name where procedures above was carried out on. If in a KDC farm, first use the actual KDC server name. Do the test of successful try with the KDC farn name

                      Sometimes it takes a while for all KDC's to sync

Service Principle Name: Either the user name created for RSSO SPN or the service name if using keytab file

Kerberos Realm: The domain the KDC is on, if using password you will need to fill this in, if using keytab file it will be filled in automatically

SPN Password: If not using keytab file enter the password of SPN user created. If using keytab file this option is greyed out

UserID format: The format the username will be in when RSSO send the token and userID to the calling application for example in AR server the user can exists as JCKERDIFF and not                                    DIFFDOM/JCKERDIFF


User ID transformation: If the KDC/AD send the username to RSSO in a particular format, use this option to change the user format to work with the calling application


After filling in the information click the "Test" button if successful you will see a "Kerberos Connection Successful" message, if it fails review the troubleshooting portion below.


Configuring with password (fig10)



Configuring with Keytab file (fig11)

After the successful test, save the configuration.


Testing Kerberos Login

You will to make sure web browsers are configured to use kerberos. Generally this is done by group policies and is not changable, but if you are testing you should be able to change the web browser configuration.


Configuring Internet Explorer

Navigate to Tools > Internet Options > Advanced.

On the Advanced tab and in the Security section, select Enable Integrated Windows Authentication (requires restart).

On the Security tab, select Local Intranet.

Click Custom Level.

In the User Authentication/Logon section, select Automatic logon only in Intranet zone.

Click OK.

Click Sites and select all check boxes.

Click Advanced and add the Remedy SSO service website to the local zone (the website might be already added). For example,

Click Add.

Click OK for all pop-ups.


Configuring Mozilla Firefox

Enter the following URL: about:config.

Click I'll be careful, I promise!

Double-click the Preference Name: network.negotiate-auth.trusted-uris.

Add the Fully Qualified Domain Name (FQDN) of the host, for example,

Double-click the Preference Name:  network.automatic-ntlm-auth.trusted-uris.

Add the fully qualified domain name (FQDN) of the host, for example,

Click OK.


Configuring Chrome: Chrome will piggy back the setting from internet explorer, so configure IE on the PC.


When the browser configuration is done, test the login.


Troubleshooting Kerberos

There a a few things that can error out when configuring kerberos for Authentication. The troubleshoot these review the following docs url Troubleshooting authentication issues  We'll cover some further troubleshooting in this post, this troubleshooting section will be updated as and when new issues are found.


When pressing the Testing Tab On the RSSO console we get a failure to connect to the KDC

The first place to look at when this issue occurs is the RSSO server logs. Set the RSSO server to "Debug" mode got to General--->Basic setting and set "Server Log Level" to "DEBUG" wait for about 15 seconds, reproduce the problem. Then take a look at the RSSO server log on the RSSO server in tomcat/logs/rsso.0.log


In each of these section, we'll take a look at what a good log should look like first we can use that as a baseline to compare with a log that shows errors.


Pressing the "TEST" button on the RSSO admin console and getting a "Connect to KDC Successful" message


28 Feb 2018 23:41:51.454 INFO Thread_41 com.bmc.rsso.core.kerberos.KerberosHelper.testServiceLogin(): Checking Kerberos service login ...

28 Feb 2018 23:41:51.454 INFO Thread_41 com.bmc.rsso.core.kerberos.KerberosHelper.getSubject(): Getting Kerberos subject ...


28 Feb 2018 23:41:51.459 INFO Thread_41 com.bmc.rsso.core.kerberos.KerberosHelper.getSubject(): Starting login context,, realm:DIFFDOM.COM, user:MYRSSOPRINCIPLE, initiator:true



28 Feb 2018 23:41:52.140 DEBUG Thread_41 com.bmc.rsso.core.kerberos.KerberosHelper.logSubject(): Kerberos subject obtained: Subject:


Private Credential: Ticket (hex) =

0000: 61 82 04 48 30 82 04 44   A0 03 02 01 05 A1 0D 1B  a..H0..D........


The above log shows successful connection to the KDC server from RSSO using the SPN user (MYRSSOPRINCIPLE) and shows the HEX value of the ticket the principle gets from the KDC



28 Feb 2018 23:45:34.330 INFO Thread_43 com.bmc.rsso.core.kerberos.KerberosHelper.getSubject(): Starting login context,, realm:DIFFDOM.COM, user:MYRSSOPRINCIPLE, initiator:true

28 Feb 2018 23:45:34.330 INFO Thread_43 com.bmc.rsso.core.kerberos.KerberosHelper.getSubject(): Login using password

28 Feb 2018 23:45:34.360 SEVERE Thread_43 com.bmc.rsso.core.kerberos.KerberosHelper.testServiceLogin(): Could not obtain Kerberos subject

Details: Pre-authentication information was invalid (24)


The above shows a failed connection to the KDC in this instance the SPN password has been changed but not updated on the RSSO admin console The RSSO admin console will give you a message also saying this "Invalid SPN password. Check if SPN account password has been changed". However you might also see the message when


1. The SPN user is found on the KDC and the password is correct, but the KDC does not allow the connection

2. When specific user permissions are needed for the SPN user to connect to the KDC


In which case the above two point will need to be checked on the KDC side. You will need to speak to the doman admin to take a look at the windows event logs for kerberos messages.

By default kerberos related messages are not logged in windows event viewer it will need to specifically be enabled. This will need a registry change


Enabling Kerberos Event Logging on a Specific Computer

  1. Start Registry Editor.
  2. Add the following registry value:
    Registry Value: LogLevel
    Value Type: REG_DWORD
    Value Data: 0x1

    If the Parameters subkey does not exist, create it.

    Note Remove this registry value when it is no longer needed so that performance is not degraded on the computer. Also, you can remove this registry value to disable Kerberos event logging on a specific computer.
  3. Quit Registry Editor. The setting will become effective immediately on Windows Server 2003 and newer, and on Windows XP and newer. For Windows 2000, you must restart the computer.
  4. You can find any Kerberos-related events in the System & Security log.


Don't forget to remove this registry entry when done troubleshooting. See How to enable Kerberos event logging



When  trying to  run the KTpass command we get a message "KTPASS Getting error "Failed to retrieve user info for <UserName>: 0x5"

This is a KDC configuration issue. Running the following on the KDC powershell resolves this issue "add-kdsrootkey -EffectiveTime (Get-Date).AddHours(-10)" see Add-KdsRootKey


When logging into an application i.e. Midtier, MyIT  ADDM we get a pop-up prompting for username and password. This is either due to either the browser not configured correctly (see above) or the domain you are login in from is not the same domain as the users domain, or an issue with the application or the agent on the application. If the userID is seen in the RSSO user sessions list, this generally means the kerberos Authentication has been done, the next troubleshooting steps should be done on the application side. Check the application log and the rssoagent log found in tomcat/logs directory.


The tomcatX-stdout.<date>.log file on the RSSO server also provides useful information when troubleshooting kerberos, include this file in the troubleshooting log review. Messages like the below are logged in this file.


>>> KdcAccessibility: remove

>>> KDCRep: init() encoding tag is 126 req type is 11


sTime is Thu Mar 01 00:00:36 GMT 2018 1519862436000

suSec is 121556

error code is 25

error Message is Additional pre-authentication required


eData provided.

msgType is 30


We can see the SPN ticket in the rssoserver log, but users are not able to login. Use the klist command from the command prompt and see if a user can request a ticket directly from the KDC outside of RSSO see Klist


Share This:

In this post we'll take a look at locking down Tomcat Web Server. We'll be specifically looking at locking down the Tomcat that runs the RSSO server application, some of these configurations can also be used to configure other applications that run on Tomcat Web Server such as Remedy Midtier.


BMC Software is engaged in an ongoing process to continually improve the security of the applications it develops. If you have encounter any security issues with BMC products the first thing to do is to contact the BMC Appication Security team. DO NOT disclose any suspected vulnerabilities publicly. For information on how to contact the BMC Application Security team see


Report any suspected Vulnerabilities of Tomcat Webserver to Apache see


This is a collaborate post between BMC Support, Engineering/Dev , Apps Security team and Customers. So we'll encourage you to post comments, questions and suggestions you may have, make them public if possible so everyone can benefit from your experiences (Do Not Disclose any unknown or suspected vulnerabilities publicly see above on how to contact the BMC Application Security team).


Locking down the Tomcat Server is only one of your security measures along with securing the network and all assets within it.  The security of the system will only be as secure as the weakest link in the environment and your applications as secure as the container that hosts it (Tomcat).


To start off with the first thing you will need to do is use the latest supported version of Tomcat (at the writing of this post Tomcat 8) see the following post Migrating Remedy Single Sign-On To A New Version Of Tomcat for information on migrating to the latest version and also the BMC Compatability matrix for information on which versions are supported. Along with TC its a good idea to also update to the latest supported level of java.


Versions Used in the examples in this post

Remedy Single Sign-On 9.1.04

Apache Tomcat 8.5.23

Java JRE 8.0_151


Apache provides a report of which security  has been fixed in each version it releases go to Apache Tomcat® - Reporting Security Problems to see what has been found and fixed in each version. Another good resource from Apache is Apache Tomcat 8 (8.0.48) - Security Considerations some of the information from that doc page we'll cover in this post along with RSSO specific information.


Locking down a TC server is a balancing act, we don't won't to overdo the securing to a point where users experience a slowdown in performance or not able to access the applications altogether. This portion is going to be determined by many factors, mainly to do with a particular environment, what works well for one environment will not necessarily work for another, there are too many factors which dictates this that it would be impossible for a one rule suites all configuration, so its important when making these changes that they are tested before making them in a live production system.


Tomcat Out Of the Box

By default tomcat can be installed and configured very quickly to start publishing web applications. The default install can and should be made more secure, if the TC server is accessible over the web this is more imperative. The default tomcat is configured in none SSL mode (HTTP) and also deploys its standard applications, An attacker could use these applications to gain access to other portions of the system.


We'll start by removing these default applications and get TC into secure SSL mode.


Tomcat Default Applications

By default TC deploys the following applications Docs, Examples, Host-manager, Manager, ROOT. All these applications serves some purposes for TC, but we won't need them for running RSSO. A brief summary of what these applications are and why they can be removed.


ROOT - This is the deault TC application when going to http://severname:8080, this will show the tomcat "is running" page along with the version of Apache Tomcat being used. For RSSO we won't need this page to do any configuration, you can change the default web page to something custom to your environment either a disclaimer or even just a blank page, This should be deleted.


Examples - Apache recommends removing these applications, these example applications can be used to gather more information  about the system and other applications. This should be deleted


Host Manager - This application is not accessible by default to anyone, unless you are creating an virtual hosts on this TC server you generally won't ever need to use this, certainly not to get RSSO configured. If you do intend to use this see Apache Documentation to secure this application.  This should be deleted.


Manager - This is used to allow remote deployment of web applications, its frequently used by attackers to gain information and access to the system. If there is a need to do remote deployment of applications then make sure you secure this application by following guidance from Apache on the docs page, for RSSO we don't need this. This should be deleted


Docs - Holds the doc pages of Apache and also hold version information. You can get the latest docs information at so we really don't need this. This can be deleted


If deleting or removing these applications is not possible for some reason, then move them into another location on the system away from the publishing area in TC /webapps. After moving or deleting the the default applications restart Tomcat to make sure it comes up correctly, with no errors in the apache-tomcat8.5.23\logs\catalina.log file. Going to any page on on the TC server should return a "Page can't be found HTTP ERROR 404" or a custom message. You should not redirect the default page to the RSSO admin console by default.


SSL Mode

The advantages of using SSL has long been documented and should be one of the first things you do when installing TC in a secure configuration. SSL certificates are used to protect sensitive information as it crosses notworks by way of encryption and provides a framework of Trusted and Trustees.  SSL is configured by enabling in the tomcat /conf/server.xml file. We'll take a look at some of these entries to enable SSL for TC in the server.xml file.


By default tomcat is installed in HTTP mode deafult port 8080. To enable SSL mode we need to add the correct entries in the server.xml file.


The format of the connector port in server.xml will look something like the below


<Connector port="8080" protocol="HTTP/1.1"


               redirectPort="https_port" />


   <Connector port="<https_port>"

                      protocol="org.apache.coyote.http11.Http11NioProtocol" SSLEnabled="true"

                       maxThreads="150" scheme="https" secure="true"



                       sslEnabledProtocols="TLSv1.1, TLSv1.2"

                       ciphers= "<list of ciphers to use> "

              keystoreFile="<path to keystore location>"

                      keystorePass="<keystore password>"

                      keyAlias="<key alias name in the keystore>"

                      truststoreFile="<trusstore location optional>"

                      truststorePass="<truststore password" />


The above entries need to be in the server.xml file to enable SSL mode. See Creating a keystore From Tomcat Webserver Video for instructions on how to create thge keystore, sign the request and import the certificate onto the tomcat web server (Video shows the TSPS tomcat server, but is valid for RSSO tomcat web server also)


SSL Offloading

The best way to manage SSL certificates in the environment is to use SSL Offloading. SSL Offloading/Termination allows the Load Balancer to deal with any certificates exchanges on behalf of the server and client.  See Remedy SSO Managing SSL Certificates with SSL Offloading video for more information and configuration.


Redirects & HTTPS Only

In some instances you may not want the port of the Tomcat server to be published along with the URL. The best method to do this is to have a Load Balancer rewrite the url and remove the port from the url. If you don't have or use a Load Balancer you will have to make some to the tomcat server.xml & web.xml files. You may also want to only allow HTTPS connections, again this best done at the Load Balancer, but it can also be achieved using Tomcat's configuration files.  The configurations below uses Tomcat auto redirect ports (80 & 443), which have the affect of removing the ports from the URL, this is done in the server.xml file


in the server.xml file change the Connector port to 80, redirect port to 443 & HTTPS connector port to 443


<Connector port="80" protocol="HTTP/1.1"


               redirectPort="443" />    


    <Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol" SSLEnabled="true"            

                       maxThreads="150" scheme="https" secure="true"



                      sslEnabledProtocols="TLSv1.1, TLSv1.2"


              keystoreFile="C:/Program Files/Apache Software Foundation RSSO/apache-tomcat8.5.23/conf/keystore.p12"



                      truststoreFile="C:\Program Files\Apache Software Foundation RSSO\apache-tomcat8.5.23\conf\TrustStore.jks"




Ciphers: Usually there is a long list of ciphers you can list to be available (The first acceptable cipher found will the one used)



Tomcat also accept OpenSSL syntax for the list for ciphers e.g ciphers="HIGH:!aNULL:!RC4:!MD5:@STRENGTH" as above. By not naming ciphers explicitly this makes it easier to use stronger ones automatically as new Tomcat & Java versions are released.


HTTPS Only &  HTTP Strict Transport Security (HSTS)

To have the TC server to only accept HTTPS secure connections put the following in the web.xml file (only use when communicating withe the server directly, if using an LB or a reverse proxy have the LB or proxy do the HTTP/HTTPS conversion)


<!-- Force HTTPS, required for HTTP redirect! -->



   <web-resource-name>Protected Context</web-resource-name>




   <!-- auth-constraint goes here if you require authentication -->






The configurations above will take effect once the TC service is restarted. Now if you go to it will redirect to HTTPS://


NOTE: Check that no other process is using port "80" on the system run "netstat -ano" to see if the port is opened and used by another process.



If a website is accessed through HTTP and there is a redirect to HTTPS, this creates an opportunity for a man in the middle attack, the redirect (HTTP) can be used to redirect to a malicious site. The HTTP Strict Transport Security header informs the browser that it should never load a site using HTTP and should automatically convert all attempts to access the site using HTTP to HTTPS requests instead. To configure HSTS edit the /tomcat/conf/web.xml file, uncomment the httpHeaderSecurity filter definition and add the hstsMaxAgeSeconds & hstsIncludeSubDomains parameters


  <filter-name>HTTP Header Security Filter</filter-name>
  <filter-name>HTTP Header Security Filter</filter-name>


See the HTSTS Parameters for information of available parameters.



Tomcat User for service/Process

Running the Tomcat Service/Process as a privileged user should be avoided i.e. any user that has Administrator or Root permissions. Create a dedicated user to start the Tomcat service/process.



Create a user with "Log on as service". On the file system set the following permissions on the Tomcat Directory for the user "Modify", "Read & Excute", "List Folder Content", "Read" and "Write" (Fig1)





For security purposes, you need to create a dedicated non-root user "tomcat" who belongs to the "tomcat" group. From the shell:

sudo groupadd tomcat

sudo mkdir /opt/tomcat
sudo useradd -s /bin/nologin -g tomcat -d /opt/tomcat tomcat


This creates a user "tomcat" who belongs to the group "tomcat". You cannot use this user account to log into the system. The home directory is /opt/tomcat, which is where the Apache Tomcat program will reside (change the location to where you want to install Tomcat)



Tomcat Auto Deploy Feature

One feature Tomcat has out of the box is the ability to deploy .war files on startup. This should be disabled. Not only will this stop unauthorised applications from deploying it will also make startup quicker.  If you are using Tomcat as a shared web Server , ensure that no other applications needs this auto deployment feature. Auto deployment can be turned off in the server.xml file


<Host name="localhost"  appBase="webapps"

            unpackWARs="true" autoDeploy="false">



Tomcat Shutdown Port

Disable the tomcat shutdown port by setting the shutdown port value to "-1" in the server.xml file . This prevents malicious actors from shutting down Tomcat's web services.  If the port can not be disabled then set a strong password for shutdown. You can still shutdown tomcat directly on the server itself with the "-1" entry but not remotely with something like telnet


e.g. Disable port

<Server port="-1" shutdown="SHUTDOWN">


e.g. Strong Password

<Server port="8005" shutdown="5hu!dOwN!\">



By default Tomcat publishes two connector types HTTP & AJP


non-SSL/TLS HTTP/1.1 8080

AJP xx Connector 8009


In most configurations Tomcat request/responses will go over HTTP/HTTPS.  The AJP connector is generally used for parsing requests through reverse proxies, although still slightly more efficient than HTTP over reverse proxies it's often not needed and should be disabled in the server.xml file (though test that connections still work if you are using a reverse proxy)




<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />




<!-- <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> -->



Clear Text Password In Server.xml file

Clear text passwords is never a good idea. In Tomcat Because there is no good way to "secure" them. When Tomcat needs to connect to a database, it needs the original password. While the password could be encoded, there still needs to be a mechanism to decode it. And since the source to Tomcat is freely available, the attacker would know the decoding method. So at best, the password is obscured see FAQ/Password - Tomcat Wiki



Its important not to specify any weak ciphers to be used in the server.xml file some ciphers along with SSL versions have been deemed not to be secure and should not be used.


SSL v2 is insecure and must not be used. This protocol version can be used to attack RSA keys and sites with the same name even if they are on an entirely different servers (the DROWN attack).


SSL v3 is insecure when used with HTTP (the POODLE attack) and weak when used with other protocols. It’s also obsolete and shouldn’t be used.


TLS v1.0 is a legacy protocol that shouldn't be used.


TLS v1.1 and v1.2 are both without known security issues, but only v1.2 provides modern cryptographic algorithms.


TLS v1.2 should be your main protocol because it's the only version that offers modern authenticated encryption (also known as AEAD)


Choosing which ciphers to use will depend on the requirements from the security team. You can use the below as a starting point




The recommendation here though is to use the OpenSSL syntax for the list for ciphers e.g ciphers="HIGH:!aNULL:!RC4:!MD5:@STRENGTH". By not naming ciphers explicitly this makes it easier to use stronger ones automatically as new Tomcat & Java versions are released.


Which Ciphers gets used? By default Tomcat will use the first acceptable cipher presented by the client browser. But often this selection is not the strongest cipher available. This behavior can be changed by using useServerCipherSuitesOrder="true" in the server.xml file. By enabling useServerCipherSuitesOrder Tomcat will probe the client using this ordered sequence until a supported cipher is matched making sure the most secure connection available is always used.


NOTE: Always test your TLS configuration in a testing/dev/ environment, transferring the changes to the production environment only when certain that everything works as expected



Other Tomcat Configurations

Out of the Box the following tomcat parameters are disabled with Tomcat (version 8.0 ), its good to be aware of them in case you need to enable them for reasons of troubleshooting etc. be sure to disable them after. Most of these entries are configured in the server.xml file they are not there by default, you will have to specifically add them in.


allowTrace - The allowTrace attribute may be used to enable TRACE requests which can be useful for debugging. Due to the way some browsers handle the response from a TRACE request (which exposes the browser to an XSS attack), support for TRACE requests is disabled by default.


xpoweredBy  - The xpoweredBy attribute controls whether or not the X-Powered-By HTTP header is sent with each request. If sent, the value of the header contains the Servlet and JSP specification versions, the full Tomcat version (e.g. Apache Tomcat/8.0), the name of the JVM vendor and the version of the JVM. This header is disabled by default. This header can provide useful information to both legitimate clients and attackers.


SSL V2,V3 - SSLv2 and SSLv3 are inherently unsafe (Poodle Attack), there is no reason to have this protocol enabled. Search the server.xml file for enabled protocols "sslProtocol=" and remove it from the protocol list


deployXML - In a hosted environment where web applications may not be trusted, set the deployXML attribute to false to ignore any context.xml packaged with the web application that may try to assign increased privileges to the web application. Note that if the security manager is enabled that the deployXML attribute will default to false.


Listings - The DefaultServlet is configured with listings set to false. This isn't because allowing directory listings is considered unsafe but because generating listings of directories with thousands of files can consume significant CPU leading to a DOS attack.


DefaultServlet - This applies to the default conf/web.xml file and WEB-INF/web.xml files in web applications if they define the components mentioned here.

The DefaultServlet is configured with readonly set to true. Changing this to false allows clients to delete or modify static resources on the server and to upload new resources. This should not normally be changed without requiring authentication.The DefaultServlet is configured with listings set to false. This isn't because allowing directory listings is considered unsafe but because generating listings of directories with thousands of files can consume significant CPU leading to a DOS attack. The DefaultServlet is configured with showServerInfo set to true. When the directory listings is enabled the Tomcat version number is included in the response sent to clients. To avoid this, you can explicitly configure a DefaultServlet and set its showServerInfo attribute to false.


Host Header Attack

A Host Header Attack is a common way for an attacker to manipulate the host header to launch a Web-Cache Poisoning or a Password Reset Poisoning attack. Host header attack vulnerability have been identified an fixed in version of Tocat 8.x see Apache Tomcat 8.x vulnerabilities


Java Security

Always use the later version of Java with Tomcat and ensure your applications supports the new version of Java version, for information on the supported version of Java for RSSO see the BMC Compatibilty Matrix To configure the security settings for Java open the java control panel-->Security tab and set the security level


Java 8u20 control panel Security tab


Security levels in the Java Control Panel


Very High

This is the most restrictive security level setting. All the applications that are signed with a valid certificate and include the Permissions attribute in the manifest for the main JAR file are allowed to run with security prompts. All other applications are blocked.



This is the minimum recommended (and default) security level setting. Applications that are signed with a valid or expired certificate and include the Permissions attribute in the manifest for the main JAR file are allowed to run with security prompts. Applications are also allowed to run with security prompts when the revocation status of the certificate cannot be checked. All other applications are blocked.


Medium (removed from Java 8 Update 20 and later versions)

Only unsigned applications that request all permissions are blocked. All other applications are allowed to run with security prompts. Selecting the Medium security level is not recommended and will make your computer more vulnerable should you run a malicious application.


Java JCE (Java Cryptography Extension) Unlimited Strength

Its advisable to install Java unlimited strength policy files. Java run time environment out of the box enforces a limitation on certain key length parameters the length is limited to 128 bits. To use a key length higher that 128 bits (192 or 256 bits) you will need to download and install the JCE unlimited strength policy files. Download the unlimited strength files for your version of java from Oracle Java Download site.


NOTE:  From Java 8 u162 the unlimited policy is enabled by default. You no longer need to install the policy file in the JRE or set the security property crypto.policy

Some countries restrict the use of encryption key lengths, check the local country laws.



Application Security

Each application on the TC webserver has its own Deployment Descriptor file (web.xml) which normally will be in /webapps/application_name/WEB-INF. The configuration discussed above is the general configuration for TC, if there are multiple applications on the TC server, each application can be configured individually using its own web.xml file. Its best to make configuration changes globally and then if a specific configuration is needed for a particular application then make the changes to its web.xml file.


Remedy Single Sign-On

RSSO provides the function to use secure cookies. If you are using HTTPS  only then there is really no need to set this flag (doing so won't cause any issues) since all the trafffic from the server to the client will be encrypted. However if the tomcat is also configured to use HTTP then that can pose a security risk of cookies being intercepted and used in an impersonation attack.  We can use a secure flag for cookies even if HTTP is being used on the server, this will encrypt the cookie. The option to enable secured cookie in RSSO (fig1). If this option is selected then all applications must also run on HTTPS and the application servers must be accessed through HTTPS only. Otherwise, it causes a redirection loop.





Limiting access to the RSSO Admin Console

You should limit access to the RSSO admin console to either a single IP address or a subset of IP address. Use the Remote Address filter in tomcat's server.xml file  to configure this, this is especially necessary if you are exposing the apps over the internet.



    <filter-name>Remote Address Filter</filter-name>



        <param-name>allow</param-name> <!-- or deny -->

        <param-value>IPADDRESSESofAllowedServers</param-value> <!-- regexp for your ip addresses -->




    <filter-name>Remote Address Filter</filter-name>

    <url-pattern>/admin/*</url-pattern> <!-- the url of your admin page or login page, etc -->



(IPV6 environments)


   <filter-name>Remote Address Filter</filter-name>



   <param-name>allow</param-name> <!-- or deny -->

   <param-value>10\.10\.1[12]\..*</param-value> <!-- regexp for your ip addresses -->




   <filter-name>Remote Address Filter</filter-name>

   <url-pattern>*/admin</url-pattern> <!-- the url of your admin page or login page, etc -->




Scanning For Vulnerabilities

After going through the TC & RSSO hardening before, ask the Network/Security team to run a vulnerability.  The scan will provide a detailed report of any vulnerabilities identified on the system, check the report and follow the recommendations of the report.


Reporting Vulnerabilities

BMC Software is engaged in an ongoing process to continually improve the security of the applications it develops. If you have encounter any issues with BMC products the first thing to do is to contact the BMC Appication Security team. DO NOT disclose any suspected vulnerabilities. For information on how to contact the BMC Application Security team see


Report any suspected vulnerability to Apache see

Filter Blog

By date:
By tag: