Search for	Example	Results
A single word	`cat`	Topics that contain the word "cat". You will also find its grammatical variations, such as "cats".
A phrase. You can specify that the search results contain a specific phrase.	`"cat food"` (quotation marks)	Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase.

Search for	Operator	Example
Two or more words in the same topic	`AND` `and` `+` (plus symbol) `&` (ampersand)	`cat AND dog` `"cat food"+milk` `"cat food"&"dog food"`
Either word in a topic	`OR` `or` `\|` (pipe)	`cat OR dog` `cat \| dog`
Topics that do not contain a specific word or phrase	`NOT` `not` `!` (exclamation point)	`NOT cat` `! dog`
Topics that contain one string and do not contain another	`^` (caret)	`cat ^ mouse`
A combination of search types	`( )` parentheses	`cat + (dog \| mouse)` `cat \| dog + (! mouse)`

Service Manager9.50

Administer > System Security > Common Access Card (CAC) sign-on > Example: enabling CAC sign-on

Example: enabling CAC sign-on

This example assumes that you are using Tomcat as your web application server and Apache as your web server.

Prerequisites

Before you proceed, make sure you have met the following prerequisites:

Your organization has already a Common Access Card (CAC) security system in place; each Service Manager user owns a CAC card that stores the user's personal certificate ("user certificate") and you have downloaded your organization's CAC root CA certificate.

Your CAC root CA certificate refers to the root CA certificate that signs the user certificates stored in the CACs. Later, you will need to:
- copy it to your web tier host and specify its location in the RootCertPath parameter. See Task 3. Configure the web tier to use CAC sign-on.
- import it to your Tomcat trust store (this is required only when you have Tomcat deployed without Apache). See Task 6. Configure your web application server to use SSL.
- copy it to your Apache server and configure it in your Apache's SSL configuration file. See Task 7. Configure the web server to use SSL.
- let users import it to their web browser. See Task 9. Configure web browsers to enable web client users to use CAC.
You have Keytool and OpenSSL installed on a machine on which you will generate SSL certificates.

Configuration Tasks

To enable CAC sign-on in your Service Manager system, complete the following tasks.

Task 3. Configure the web tier to use CAC sign-on.

Stop the web application server running the web tier.
Copy your CAC root certificate (s) to a directory on your web tier host. For example: <webtier>/WEB-INF/

Set the following parameter values in the web tier's web.xml file.

Parameter	Value
`isCustomAuthenticationUsed`	`false`
`CACLogin`	`true`

Configure your web application server to use CAC as the trusted authentication source.
1. Navigate to the <web tier installation direcotry>\WEB-INF\classes folder, and open the application-context.xml file in a text editor.
2. Search for the following string:
  <sec:filter-chain pattern="/**" filters="securityContextPersistenceFilter,anonymousAuthFilter"/>
3. Replace the search string with the following text to use CAC authentication as your trusted authentication source:
  <sec:filter-chain pattern="/**" filters="securityContextPersistenceFilter,cacFilter,anonymousAuthFilter"/>
  Note If you also want to enable lightweight single sign-on (LW-SSO) for integrations, add cacFilter followed by lwSsoFilter, as shown in the following:
  <sec:filter-chain pattern="/**" filters="securityContextPersistenceFilter,cacFilter,lwSsoFilter,anonymousAuthFilter"/>
  Be aware that CAC sign-on can only work with outgoing LW-SSO (LW-SSO from SM to another product). For information about how to enable LW-SSO in the web tier, see Configure LW-SSO in the Service Manager Web tier.
  Note If you enable both TSO and CAC sign-on in the same web tier, CAC sign-on takes precedence.
4. Uncomment the following lines:
```
<bean id="cacFilter" class="com.hp.ov.sm.client.webtier.cac.CACPreAuthenticationFilter">
```
```
    <property name="authenticationManager">
```
```
       <ref bean="authenticationManager"/>
```
```
    </property>
```
```
    <property name="defaultRole">
```
```
       <value>ROLE_PRE</value>
```
```
    </property>
```
```
    <property name="cacProps">
```
```
       <ref bean="cacConfiguration"/>
```
```
    </property>
```
```
</bean>
```
```
<bean id="cacConfiguration" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
```
```
    <property name="location"><value>classpath:cacconf.properties</value></property>
```
```
</bean>
```
5. Save the file.

Configure CAC authentication in the web tier's cacconf.properties file.

Open <web tier installation path>\WEB-INF\classes\cacconf.properties in a text editor.

Specify the following parameters.

Parameter	Default	Description
`certificateFieldExtractDN`	`Subject.CN`	This parameter specifies a unique attribute in the user certificate that the web application server extracts as a Distinguished Name (DN) and sends to the SM server as the user's user name. You can specify a Subject attribute in this parameter. By default, the Subject CN attribute (the certificate owner’s Common Name) is extracted as the user's DN. You can also specify this parameter as one of the following Subject Alternative Name (SAN) sub-attributes: RFC822 Name, and Other Name (see the figure below). If using a sub-attribute of Other Name, specify the parameter in this format: `SAN_OTHERNAME.<Alias>`, where `<Alias>` is a name that you specify for the sub-attribute. The user certificate's SAN Other Name value that binds to the OID will be extracted as the DN. For example, if you use Other Name's Principal Name sub-attribute (also known as UPN, which should be mapped to OID "1.3.6.1.4.1.311.20.2.3"), you can specify the following value (where PrincipalName is an alias for Principal Name): `certificateFieldExtractDN=SAN_OTHERNAME.PrincipalName` Tip As a best practice, avoid including white spaces in alias names. For example, for Principal Name, specify `PrincipalName` or `PN` as an alias. Note Next, you will specify a mapping between the alias and object ID (OID) of the specified sub-attribute of SAN Other Name, by using the certificateOIDMapping parameter. If using the RFC822 Name sub-attribute, specify the following value: `certificateFieldExtractDN=SAN.RFC822` Examples: `certificateFieldExtractDN=Subject.E` `certificateFieldExtractDN=SAN_OTHERNAME.PrincipalName`
`certificateOIDMapping`	(empty)	This parameter specifies a mapping between the `<Alias>` you specified in `certificateFieldExtractDN` and an OID. Specify the parameter in this format: `<Alias>:<OID>`. For example, for SAN's Principal Name, specify this mapping: certificateOIDMapping=PrincipalName:1.3.6.1.4.1.311.20.2.3
`validationStrategy`	(empty)	This parameter specifies how the web application server verifies each user certificate. You can specify a combination of the following values, each of which represents a checking method: `1`: Check the revocation status of the user certificate using a local Certificate Revocation List (CRL). `2`: Check the revocation status of the user certificate using an online CRL. `3`: Check the revocation status of the user certificate using the Online Certificate Status Protocol (OCSP). `4`: Check if the user certificate is of the Smart Card type. Pay attention to the following: You cannot leave this parameter empty. If you specify more than one value, separate them with a comma. In this case, all specified checking methods are used in the sequence they are listed in the parameter. You must specify at least one of the following values: 1, 2, and 3. If you do not do so, users will not be able to log in; instead, they will see a message in their browser that states "An error has occurred"; in the meantime, an error message will occur in the web application server's `sm.log` file. Smart Card checking (value 4) is mandatory for CACs, because CACs are smart cards. You can configure CRL or OCSP checking either in your web server or in this parameter, but not in both. Example: `validationStrategy=3,4`
`RootCertPath`	(empty)	This parameter specifies the file path (either absolute or relative) to the issuer's CA certificate. Note The issuer's CA certificate refers to the root CA certificate that signs the user certificates stored in the CACs (also referred to as the "CAC root CA certificate" in this document). If you need to specify multiple CAC root CA certificates, use a comma to separate them. Example: `RootCertPath=/WEB-INF/HPCAB.cer,/WEB-INF/HPCA.cer`
`CRLDownloadURL`	(empty)	Specifies the URL that identifies the location of your online certificate revocation list (CRL). You can leave this parameter empty, and then the CRL Distribution Point from the user certificate being validated is retrieved at runtime, which might cause a slightly slower performance; however, if FIPS mode is enabled in the web client (see FIPS mode), you must explicitly specify this parameter (cannot leave it empty). If your root CA has multi-level intermediate CAs: If your root CA certificate specified in `RootCertPath` has multi-level intermediate CA certificates, you should either specify the multi-level CRLs of the root CA and intermediate CA certificates (comma-separated), or leave the parameter empty. Examples: `CRLDownloadURL=http://onsitecrl.example.com/LatestCRL.crl` CRLDownloadURL=http://onsitecrl.example.com/LatestCRL.crl,http://onsitecrl.example.com/IntermediateCRL.crl
`OCSPResponderURL`	(empty)	Specifies the URL that identifies the location of the OCSP responder. By default, this parameter is not specified, and the OCSP responder location is retrieved from the user certificate being validated. If you specify multiple root CA certificates: If you specify multiple root CA certificates in `RootCertPath`, you must leave `OCSPResponderURL` empty. In this case, the OCSP Responder URL stored in the user certificate being validated is retrieved instead during runtime. Example: `OCSPResponderURL=http://ocsp.example.net:80`
`CRLStoreLocation`	(empty)	Specifies the location of your local CRL. Note This parameter also supports multi-level intermediate CRLs (comma-separated). Examples: CRLStoreLocation=/WEB-INF/classes/LatestCRL.crl CRLStoreLocation=/WEB-INF/classes/LatestCRL.crl,/WEB-INF/classes/IntermediateCRL.crl

Specify other parameters as needed.

Note The validation strategy you specified determines which parameters are required, recommended or optional (see the following table).

Method	How to Enable	Parameters
Local CRL checking	`validationStrategy=1`	`RootCertPath` (Mandatory) `CRLStoreLocation` (Mandatory)
Online CRL checking	`validationStrategy=2`	`RootCertPath` (Mandatory) `CRLDownloadURL` (Recommended): If it is not specified, the default URL stored in the user certificate is used. `CRLRefreshScheduler` (Optional): This parameter specifies an interval at which the online CRL stored in the browser cache is refreshed. The default is 1440 minutes.
OCSP checking	`validationStrategy=3`	`RootCertPath` (Mandatory) `OCSPResponderURL` (Recommended): If it is not specified, the default URL stored in the user certificate is used. `OCSPServerCertPath` (Optional): This parameter specifies the file path to the OCSP server CA certificate. If it is not specified, the `RootCertPath` is used as the certificate for the OCSP server.
Smart Card checking	`validationStrategy=4`	No other parameters are required. To ensure greater security, Smart Card checking is required for CAC cards, which are smart cards.

Save the file.

The following is an example configuration of the cacconf.properties file.

certificateFieldExtractDN=Subject.CN

certificateOIDMapping=PrincipalName:1.3.6.1.4.1.311.20.2.3

validationStrategy=2

RootCertPath=/WEB-INF/CA.cer

CRLRefreshScheduler=1440

CRLDownloadURL=http://onsitecrl.verisign.com/myCompany/LatestCRL.crl

CRLStoreLocation=

OCSPResponderURL=

OCSPServerCertPath=

If a proxy is needed to access your OCSP responder URL or online CRL URL, configure a proxy in your web application server (in this example, Tomcat). You can use either of the following approaches depending on your Tomcat installation.

To configure a proxy using the Configure Tomcat shortcut:
1. From your operating system's Start menu, click All Programs > <Apache Tomcat> > Configure Tomcat.
2. On the Java tab, append your proxy configuration lines to the Java Options text box. For example:
```
-Dhttp.proxyHost=<Proxy Server FQDN>
```
```
-Dhttp.proxyPort=<Proxy Server Port, for example, 8080>
```
```
-Dhttp.nonProxyHosts="<Service Manager Server Host FQDN>|<Tomcat Server Host FQDN>"
```
To configure a proxy using the catalina.bat file:
1. Open the <Tomcat>/bin/catalina.bat file in a text editor.
2. Add the following lines:
```
set JAVA_OPTS=%JAVA_OPTS% 
```
```
-Dhttp.proxyHost=<Proxy Server FQDN>
```
```
-Dhttp.proxyPort=<Proxy Server Port, for example, 8080>
```
```
-Dhttp.nonProxyHosts="<Service Manager Server Host FQDN>|<Tomcat Server Host FQDN>"
```
3. Save the catalina.bat file.

Task 6. Configure your web application server to use SSL.

Note This task is required only when you do not have a web server (Apache or IIS) deployed; if your web application server is connected to a web server , skip to Task 7. Configure the web server to use SSL.

CAC sign-on requires two-way SSL connection between the web application server and the user's browser. For information on configuring two-way SSL on your web application server, see your web application server documentation.

Example: Configure Tomcat 7 to Use SSL

The following example assumes that you already have one root CA certificate that signs the user certificates stored in CACs and the root CA certificate is available (this root CA certificate is also referred to as the "CAC root CA certificate").

Generate a truststore file (for example, truststore.jks) for the Tomcat server.

Caution Be sure to use the web tier host's fully qualified domain name (FQDN) as the Common Name (CN).
Import your CAC root CA certificate to the Tomcat server truststore file.

The CAC root CA certificate (CAC_ca.crt) is the root CA certificate that signs the user certificates stored in the CACs. Run the following command to perform the import:
```
keytool -import -v -file CAC_ca.crt -alias rootca -keystore truststore.jks –storepass  123456
```
Generate a server certificate (server.p12) for the Tomcat server.
1. Generate a key pair (public and private keys).
2. Create a certificate signing request (.csr) from the key pair.
```
openssl req -new -out server-req.csr -key server.key –config openssl.cnf
```
3. Send the request to an external CA to get it signed.
  Note You can also create a private CA and self-sign the request.
  For example, suppose you have installed and set up a Microsoft Active Directory Certificate Service (ADCS). You can send the request to this CA as described in the following:
  1. Open your ADCS URL in your browser: http://<host>/certsrv.
  2. Select the Request a certificate task, and then click the advanced certificate request link.
  3. Select the Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file... option.
  4. Open the server-req.csr in a text editor, and copy its entire content.
  5. Paste the request content to the Base-64-encoded certificate request box, and then click Submit.
  6. After the CA signs the request, download the signed server certificate and save it as server.crt.
  7. Download the ADCS root CA certificate, and save it as root.crt. Users will need to import this root CA certificate into their browser.
4. Convert the signed server certificate to PKCS12 type (from server.crt to server.p12).
```
openssl pkcs12 -export -clcerts -in server.crt -inkey server.key -out server.p12
```
Copy the Tomcat server truststore (truststore.jks) and certificate (server.p12) to a local folder, for example, Tomcat's /conf/ssl folder.

In the Tomcat configuration file (/conf/server.xml), configure SSL for CAC sign-on.

Uncomment the following lines.

<!--

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"

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

clientAuth="false" sslProtocol="TLS" />

-->

Change clientAuth="false" to clientAuth="true".

Add the keystoreFile and truststoreFile settings.

This section now should look like the following:

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"

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

clientAuth="true" sslProtocol="TLS"

keystoreFile="../conf/ssl/server.p12" keystorePass="changeit" keystoreType="PKCS12"

truststoreFile="../conf/ssl/truststore.jks" truststorePass="123456" truststoreType="JKS"/>

Save your changes.

Restart Tomcat.

Task 7. Configure the web server to use SSL.

CAC sign-on requires two-way SSL authentication between the web server/web application server and the user's browser.

For more information on configuring two-way SSL on your web server (Apache or IIS), see your web server documentation.

Example: Configure Apache 2.2 to Use SSL

The following steps assume that you have already established a connection between Apache (the web server) and Tomcat (the web application server). See Task 5. Connect your web application server to the web server.

Create a certificate and a key for the Apache server (server.crt, and server.key).
1. Generate a key pair (public and private keys).
2. Create a certificate signing request (.csr) from the key pair.
```
openssl req -new -out server-req.csr -key server.key –config openssl.cnf
```
3. Send the request to an external CA to have it signed.
  Note You can also create a private CA and self-sign the request.
  For example, suppose you have installed and set up a Microsoft Active Directory Certificate Service (ADCS). You can send the request to this CA as described in the following:
  1. Open your ADCS URL in your browser: http://<host>/certsrv.
  2. Select the Request a certificate task, and then click the advanced certificate request link.
  3. Select the Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file... option.
  4. Open the server-req.csr in a text editor, and copy its entire content.
  5. Paste the request content to the Base-64-encoded certificate request box, and then click Submit.
  6. After the CA signs the request, download the signed server certificate and save it as server.crt.
  7. Download the ADCS root CA certificate, and save it as root.crt. Users will need to import this root CA certificate into their browser.
When this step is complete, you have got the Apache server certificate (server.crt) and server key (server.key), as well as the external CA root certificate (root.crt). Users will need to import the root.crt to their browser (see Task 9. Configure web browsers to enable web client users to use CAC.).
Copy your Apache server.crt and server.key to a folder. For example: <Apache installation folder>/conf/ssl.
Copy your CAC root CA certificate (CAC_ca.crt) to the same folder.
Uncomment the following line in the httpd.conf file.
```
#LoadModule ssl_module modules/mod_ssl.so
```

Configure the \extra\httpd-ssl.conf file as follows:

SSLEngine On

SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

SSLCertificateFile "<Apache installation folder>/conf/ssl/server.crt"

SSLCertificateKeyFile "<Apache installation folder>conf/ssl/server.key"

SSLCertificateChainFile "<Apache installation folder>conf/ssl/CAC_ca.crt"

SSLCACertificatePath "<Apache installation folder>/conf/ssl"

SSLCACertificateFile "<Apache installation folder>/conf/ssl/CAC_ca.crt"

SSLVerifyClient require

SSLVerifyDepth 2

Task 8. Create operator records for CAC users.

The web server extracts information from the user certificate based on the certificateFieldExtractDN value defined in the <web tier installation path>\WEB-INF\classes\cacconf.properties file.

You must create an operator record for each CAC user. The configuration varies depending on whether Lightweight Directory Access Protocol (LDAP) is enabled on the SM server or not.

If LDAP is not enabled for the SM server

For each CAC user certificate, create an operator record whose Login Name (operator.name) field has the same value as the distinguished name (DN) value in the certificate.

See the following table for an example, which indicates that you need to create an operator record whose Login Name is the email address stored in the user certificate.

In the cacconf.properties file	In the user certificate	In the operator record
certificateFieldExtractDN=Subject.E (DN=certificate owner's email address)	Subject.E=jack.smith@mycompany.com	Login Name=jack.smith@mycompany.com

In the cacconf.properties file

In the user certificate

In the operator record

certificateFieldExtractDN=Subject.E

(DN=certificate owner's email address)

Subject.E=jack.smith@mycompany.com

If LDAP is enabled for the SM server

Configure LDAP mapping for the operator and contacts tables, and make sure that the operator.name and contacts.operator.id fields are mapped to the same LDAP attribute that corresponds to the certificate attribute defined in certificateFieldExtractDN.

The following table lists the fields in the operator and contacts tables that you must map to an LDAP attribute.

Note The LDAP attribute names here are provided only as an example, which may differ from your actual mappings. In this example, both of the name field in the operator table and the operator.id field in the contacts table are mapped to the sAMAccountName attribute, which corresponds to the user certificate attribute defined in certificateFieldExtractDN.

File Name	Field Name	LDAP Attribute Name
`operator`	`contact.name`	`cn`
	`full.name`	`cn`
	`name`	`sAMAccountName`
`contacts`	`contact.name`	`cn`
	`first.name`	`givenName`
	`full.name`	`cn`
	`last.name`	`sn`
	`operator.id`	`sAMAccountName`

For details about LDAP configuration, see the Service Manager LDAP Best Practices Guide, available at:

https://softwaresupport.hpe.com/group/softwaresupport/search-result/-/facetsearch/document/KM1010774

Now, your CAC sign-on setup is complete.

Send Help Center feedback