Web Services

Use the following URL for details about securing a Windows server:

• For Windows Server 2012: https://technet.microsoft.com/en-us/library/jj898542.aspx

• For Windows Server 2016: https://blogs.technet.microsoft.com/secguide/2016/10/17/security-baseline-for-windows-10-v1607-anniversary-edition-and-windows-server-2016/

• For Windows Server 2019: https://docs.microsoft.com/en-us/archive/blogs/secguide/security-baseline-final-for-windows-10-v1903-and-windows-server-v1903

• For Windows Server 2022: https://www.microsoft.com/en-us/download/details.aspx?id=55319

In addition, it is recommended that you install and run security analyzer tools, for instance:

• Microsoft Baseline Security Analyzer 2.3: https://technet.microsoft.com/en-us/security/cc184924.aspx

• SCM for Windows 2016: https://technet.microsoft.com/en-us/solutionaccelerators/cc835245.aspx?f=255&MSPPError=-2147217396

Based upon the Microsoft generic hardening recommendations, it is recommended that you apply your own internal hardening process. However, the hardening process is outside the scope of this documentation.

To ensure that your ActivID CMS systems work properly in a newly-configured environment, it is imperative that you implement and use a comprehensive change control process. The purpose of this process is to fully test each new configuration or environment change in a dedicated test network before applying the change across your deployed ActivID CMS production systems.

This section assumes that you have implemented the recommendations in the previous section regarding securing your IIS Web server. To securely implement ActivID CMS within your IIS environment, apply the following guidelines:

• Make sure that the ActivID CMS Web site runs only on the ActivID CMS server. Remove all other Web sites (for example, the default Web Site and other services that might be enabled as part of the IIS service).

• Configure the IP address and Host header values for the ActivID CMS Web site.

• During ActivID CMS installation, change the default TCP port to 80 (for HTTP traffic) and the SSL TCP port to 443 (for HTTPS traffic).

• Using the Performance tab, configure the IIS maximum number of connections to match your requirements (in general, 150 concurrent sessions is typically sufficient).

• Configure the IIS default setting to match your longest page return time (this assumes that your ActivID CMS deployment is fast enough to return any query faster than 120 seconds).

• Configure your IIS server to use certificates issued from your own CA The Certificate Authority (CA) issues and manages security credentials and public keys for message encryption in a networks environment. rather than the self-generated certificates deployed during ActivID CMS installation. If you use ActivID CMS in peered mode, use different certificates for each server. Make sure that any soft certificates issued during the build process of ActivID CMS are revoked and the CRL is updated.

• Change IIS application protection to High for the ActivID CMS Web site, Operator Portal, and User Portal Web instances.

• Make sure that the ActivID CMS Web site, Operator Portal, and User Portal Web instances are configured with only Log Visits and Read Access. These Web sites must have Execute permissions for scripts and executions.

• Improve audit traceability by assigning different domain users to run the Operator Portal and User Portal. Make sure that both domain users are members of the local user group that was suggested in Observing ActivID Credential Management System-Related Security Considerations.

• Make sure that the users that run the Operator Portal and User Portal Web instances are not local administrators on the ActivID CMS system(s), or administrators in the domain.

• Disable Web access to the ActivID CMS Web site root.

• Configure the Apache Tomcat memory assignment to match your server specifications.

ActivID CMS runs under an Apache Tomcat Web instance (called “CMS Server”) and in some circumstances, it is possible that the memory allocation for the Apache Tomcat service is too limited, and this can cause a server failure or slow response times. To minimize this risk, it is recommended that you modify the workers.properties file so that a larger amount of memory is allocated to this process.

Although recommendations will differ per customer, an initial allocation of a minimum of 256 megabytes (MB) and a maximum of 512 MB is recommended for the Apache Tomcat services. The worker.inprocess.ms entry specifies the minimum allocated memory, and the worker.inprocess.mx entry specifies the maximum allocated memory. Modify the values of these entries as shown:

• For 256 MB of minimum memory:  worker.inprocess.ms=268435456

• For 512 MB of maximum memory: worker.inprocess.mx=536870912

For specific security recommendations regarding the Apache Tomcat services, refer to the following site for details:

https://cwiki.apache.org/confluence/display/TOMCAT/Security

Apache Tomcat uses the AJP13 connector between the ActivID CMS front-end and the Apache Tomcat back-end services. The following figure illustrates this connection between ActivID CMS and the Apache Tomcat.

Apache Tomcat AJP13 Configuration

To harden the security of the Apache Tomcat AJP13 link, use one or more of the following methods:

1. Put the Apache Tomcat service behind the DMZ.

2. Define a specific firewall rule that only permits access of the AJP13 port from an IIS server front-end.

3. Configure the shared secret on both sides of the connector. The AJP13 protocol supports a simple shared secret-based authentication mechanism: both the AJP connector and the AJP13 worker can define a shared secret in their configuration files.

   The Apache Tomcat connector only accepts requests from users that send the correct secret in the command. The secret is stored in clear (unencrypted) text in the workers.properties (entry secret) and server.xml files (entry requiredSecret). The secret is sent over between the client and server in clear text.

4. Configure the Tomcat server.xml file with a request filter that only accepts requests from the IIS server front-end.

5. Disable any other unused connectors in the Apache Tomcat container server.xml file (specifically, the HTTP connector to avoid having Apache Tomcat listen on ports other than AJP13 from allowed systems).

6. Depending on the security policy of the deployment, the TCP traffic might be further encrypted between the front-end and the Apache Tomcat server using IPsec or SSH tunnels.