That is part of the jTDS driver download. Step "e" is a link to sourceforge, to download the driver files. The build.bat file is in the root directory of that download.
Interesting, because it's not in the file I downloaded.
I'm installing on a DoD system that is thoroughly STIG, though, and I'm wondering if there are policies in place that may have stripped out the .bat from the directory.
Just to follow up, the tech doc that BMC has is wrong on this. There is a specific jtds-1.2.8.jar file you must use that BMC can provide.
Here are the actual steps I took to get this to work.
- Gather information from SQL Server.
- Open SQL Server Configuration Manager on the SQL Server. Expand SQL Server Network configuration. Right-click on Protocols for MSSQLSERVER. Choose Properties.
- On the Flags tab, there is an option to Force Encryption. This can be changed to Yes to require all connections to SQL be encrypted. If this is an instance dedicated to Footprints, select Yes. Otherwise, keep it to No if there are other applications using the server that don’t use encryption.
- On the Certificate tab, there is an option to choose a certificate. Make a copy of the certificate used. If there is no certificate, then SQL will use its own self-signed certificate.
- Update the JTDS driver
- Open …\Program Files\BMC Software\Footprints\web\WEB-INF\lib folder in Windows Explorer.
- Make a backup copy of the jtds-1.2.x.jar file, making sure to change its extension.
- Replace it with the BMC supplied jtds-1.2.8.jar file.
- Adjust Tomcat parameters
- Run Tomcat7w.exe
- Click on the Java tab
- Add the following line to the Java options: -jsse.enableCBCProtection=false
- Click Apply, then OK.
- Add the certificate to the keystore. Note: This step is optional, depending on what certificate the SQL Server is using. With or without this step, all communication with the SQL Server will be encrypted. The benefit of this step is to force Footprints to verify the identity of the SQL Server.
Per Step 1.c above, you made note of any certificate used by SQL Server.
- If no certificate was selected, then SQL is using its own self-signed certificate and Step 4 does not apply.
- If the certificate was from a well-known, trusted Certificate Authority such as Thawte or Verisign, this step can probably be skipped. Tomcat has a built-in set of trusted certificates from many CAs.
- If a self-signed certificate is being used, or if the certificate is signed by a local CA, then follow this step so Tomcat can know it can trust the certificate.
- Obtain a copy of the certificate that SQL Server is using, or the CA public certificate. This will be a .pem, .cer, or .pfx file. The example below will use the filename mycert.cer.
- Download the Portecle app from http://portecle.sourceforge.net/projects/portecle.
- Unzip the file into its own folder. In this example, we’ll use C:\portecle-1.7.
- Run the following command, including the double-quote characters. Be sure to point to the version of Java you have installed:
“C:\Program Files\Java\jre1.8.0_51\jre\bin\java” –jar C:\portecle-1.7\portecle.jar
- Choose File | Open CA Certs Keystore
- The password is: changeit
- Choose Tools | Import Trusted Certificate
- Select your certificate file
- Click OK at the “Could not establish a trust path…” prompt
- Click OK on the certificate details
- Click Yes when prompted to trust the certificate
- The certificate can be given an alias, or you can accept the default value
- Choose File | Save Keystore
5. Edit the Footprints Service Core configuration
- Open Program Files\BMC Software\Footprints\conf\footprints-environment.properties in Notepad or another text editor.
- Find the following line (“sqlserver” should be replaced with your actual database server name). Note: if your SQL Server name is shown as “localhost”, it should be changed to the actual server name in order to match the server name specified in the certificate:
- At the end of the line, insert the text “;ssl=require”. The line should now look like this:
- Alternately, if it’s desired to force verification of the SQL Server’s identity, use “ssl=authenticate” instead, so the line reads as follows:
- Save the footprints-environment.properties file
6. Restart Tomcat
7. Verify Secure Connection. If the SQL Server is configured to force encryption for all connections, simply log in to Footprints to confirm the secure connection is working. If the SQL Server allows some secure, and some unsecure, connections, the following steps can be used to verify Footprints is using a secure connection:
- Log into Footprints
- Open SQL Server Management Studio and connect to the database housing the Footprints database and run this query: exec sp_who2;
- Find the result rows with:
DBName = fpscdb001
ProgramName = jTDS
Note the SPID values from those rows.
- Run this query:
Select session_id, encrypt_option from sys.dm_exec_connections;
- Confirm that the rows with the SPIDs noted above have encrypt_option=TRUE.
- Gather information from SQL Server.