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)`

Network Node Manager i Software10.30

Administer > Configure NNMi to Support Public Key Infrastructure User Authentication

Configure NNMi to Support Public Key Infrastructure User Authentication

This topic includes the following sections:

User Authentication Strategies
Configure NNMi for PKI User Authentication (X.509 Certificate Authentication)
Certificate Validation (CRL and OCSP)
Configure NNMi to Restrict Certificates Used for NNMi Logon Access
Example: Configure NNMi to Require a Smart Card Logon
Configure CLI Authentication for PKI User Authentication
Troubleshoot PKI User Authentication Issues

NNMi supports user authentication through Public Key Infrastructure (PKI) so that users must log on to NNMi using an X.509 client certificate without using a password. The information in this chapter explains how to configure NNMi (using PKI user authentication) to map certificates to NNMi user accounts.

PKI user authentication includes support for smart cards, such as Common Access Card (CAC) and Personal Identity Verification (PIV) cards.

After enabling NNMi to use PKI user authentication, NNMi users do not need to use an NNMi-specific user name and password to log on to NNMi.

Using this approach, NNMi reads your PKI certificate to obtain your user name. To obtain NNMi user roles, you need to define a user’s roles within NNMi or configure NNMi to use Lightweight Directory Access Protocol (LDAP).

PKI user authentication uses the HTTPS protocol.

PKI user authentication is a replacement for the Lightweight Single Sign-on (LW-SSO) functionality. Therefore, you cannot use them both.

User Authentication Strategies

NNMi provides several options for where the NNMi user access information is defined and stored.

The following table indicates the options available for PKI user authentication.

User Authentication Strategies
Option	Which Method for User Authentication?	User Account Definitions in NNMi	User Group Definitions in NNMi	Which Method for Group Membership
Mixed	X.509 Certificate	Yes	Yes	NNMi User Account Mappings
External	X.509 Certificate	No	Yes	LDAP

In the Mixed option, NNMi defines and stores the User Group assignments. For information about setting up all user information in NNMi, see Configuring User Accounts (User Account Form) in the NNMi help.

In the External option, NNMi uses the Lightweight Directory Access Protocol (LDAP) User Group assignments.

Configure NNMi for PKI User Authentication (X.509 Certificate Authentication)

Before configuring NNMi for PKI user authentication, note that user account names must match the user names contained in the certificates. Set roles using one of the following methods:

To use LDAP, see "Integrating NNMi with a Directory Service through LDAP".
To use the NNMi console to add a user account, select the Directory Service Account check box on the User Account form and leave the Password field blank. Then, use the user account name to match the previous mapping rule.

For NNMi, enable and customize PKI user authentication in the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml
Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml

To enable NNMi to require PKI user authentication, also referred to as X.509 Certificate Authentication:

Edit the following file:
- Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml
- Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml

Search for the following text block:

<realm name="console">

<mode>FORM</mode>

</realm>

Edit the located lines to read:

<realm name="console">

<mode>X509</mode>

</realm>

Search for the following text block:
```
<principalMapping>
```
Configure NNMi to extract (map) the principal by editing the items in the <principalMapping> section. You must know the format of your certificate to complete this step.

NNMi supports several options for extracting a principal and those options can be specified in any order and in any number.
- The attribute element extracts a field from the SubjectDN; for example, EMAILADDRESS.
  - If you are using LDAP, the extracted name must match the name the LDAP configuration expects. For more information, see Integrating NNMi with a Directory Service through LDAP.
  - If you use internal accounts, the name must match the NNMi user account name. If the account is used for PKI user authentication only, it should be created as a “Directory Service Account”, without a password (using the NNMiUser Account form. Select the Directory Service Account check box and leave the Password field blank). If the account is used for both PKI user authentication and password logon, it should be created as a standard account with a password.
- The regexp element runs the regular expression against the whole SubjectDN.
- The subjectAlternativeName (SAN) element can be used with type rfc822Name (which is an email address).
- The subjectAlternativeName element with type otherName and an additional oid attribute. This option is commonly used for the Microsoft Universal Principal Name (UPN) field.
In addition to the examples provided in the nms-auth-config.xml file’s <principalMapping> section, see the following examples:

Example 1: Edit the following lines to read as follows for using the EMAIL field:
```

```
```
<attribute>EMAILADDRESS</attribute>
```
Example 2: Edit the following lines as an example of using a more complex regular expression to extract part of the field, as in extracting just part of the EMAILADDRESS field. To extract just the name part of the EMAILADDRESS field, use the following regular expression:
```
 <regexp group="1">EMAILADDRESS=([^@]+).*</regexp>
```
Example 3: Edit the following lines as an example of using a more complex regular expression to match fields in the middle of the string:
```
 
```
```
<subjectAlternativeName type="rfc822Name" />
```
Example 5: Edit the following lines to read as follows to extract a particular OID from the Subject Alternative Name:
```

```
```
<subjectAlternativeName type="otherName" oid="1.3.6.1.4.1.311.20.2.3" />
```
```
The logging command to enable debug logging is as follows:
```
```
nnmsetlogginglevel.ovpl 
```
```
com.hp.ov.nms.as.server.auth.x509.NmsCertMapper FINEST
```
Save your changes.
If you have already installed your trusted CA certificates into the truststore, run the following script for the changes to the nms-auth-config.xml file to take immediate effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```
Otherwise, if you have not yet installed your certificates, proceed with the following steps.
Change to the directory on the NNMi management server that contains the nnm-trust.p12 file:

Windows: %NnmDataDir%\shared\nnm\certificates

Linux: $NnmDataDir/shared/nnm/certificates

Import your trusted CA certificate into the nnm-trust.p12 file. Suppose the example_ca.cer file contains the certificate you must use. Run the following command to import the CA certificate into the NNMi nnm-trust.p12 file:

Windows:

%NnmInstallDir%\bin\nnmkeytool.ovpl -import -alias myca -storetype PKCS12 -keystore nnm-trust.p12 -file example_ca.cer

Linux:

$NnmInstallDir/bin/nnmkeytool.ovpl -import -alias myca -storetype PKCS12 -keystore nnm-trust.p12 -file example_ca.cer

Restart the NNMi services.
1. Run the ovstop command on the NNMi management server.
2. Run the ovstart command on the NNMi management server.

When making file changes under HA, you must make the changes on both nodes in the cluster. For NNMi using HA configurations, if the change requires you to stop and restart the NNMi management server, you must put the nodes in maintenance mode before running the ovstop and ovstart commands.

NNMi is now configured to use PKI user authentication. You can no longer use passwords to log on NNMi. Check that your LDAP and NNMi user accounts are working correctly, and that the certificates and accounts are configured correctly for user access to NNMi.

Log on to NNMi using a Client Certificate

To log on to NNMi using a client certificate:

Ensure that your client certificate is accessible in your browser.
Point your browser to https://<hostname>/nnm.
NNMi permits you access and assigns user roles based on your NNMi or LDAP account configuration.

Revoke Access for a User Having a Client Certificate

To remove a user from accessing NNMi, do one of the following:

If you configured a user for access using an LDAP account, remove the user from all LDAP groups associated with NNMi.
If you configured a user for access using NNMi user accounts, remove the user from the user group and remove their user account.

In either case, the user can no longer log on to the NNMi console.

Special Considerations When PKI User Authentication in Global Network Management Environments

If you use NNMi in a Global Network Management configuration, configure PKI user authentication for all of the NNMi management servers included in the Global Network Management Configuration.

Certificate Validation (CRL and OCSP)

NNMi supports two methods of checking for revoked certificates:

Certificate Revocation List (CRL) - A CRL is a list of revoked certificates that is downloaded from the Certificate Authority (CA).
Online Certificate Status Protocol (OCSP) - OCSP is a protocol for checking revocation of a single certificate interactively using an online service called an OCSP responder.

CRL and OCSP validation are two different ways to achieve the same result: denying access to any user whose certificate is revoked. In a web browser, OCSP is generally considered superior because a browser is usually dealing with many different Certificate Authorities (CAs), and having to download an entire CRL to check one web site is inefficient.

However, for a server that is often dealing with many clients, all with certificates from the same CA, CRL checking can be significantly more efficient because the CRL can be downloaded once per day instead of needing to check OCSP for every connection.

When both OCSP and CRL are enabled,NNMi, by default, queries CRL first. CRL checking is performed first because the CRL usually has a much longer lifetime and, therefore, is more resilient to network outages. OCSP performs frequent requests so, if the network or the OCSP responder is down, users will be unable to log on. NNMi attempts to obtain a valid CRL first to use in continuing operations in the case the network or OCSP responder goes down.

In addition, CRL comparison is much faster than OCSP; that is, matching a certificate against a list that exists on the disk is faster than querying a separate server over the network to validate each certificate. So if a certificate has been signed by a trusted entity, and is not expired, the CRL is queried to see if the certificate has been revoked. If it has been revoked, there is no need to check OCSP. But if the certificate is still valid after checking the CRL, OCSP will also be queried to ensure that the certificate has not been revoked recently (and an updated CRL listing the certificate is not yet available).

When both OCSP and CRL are enabled, NNMi supports the following:

NNMi queries CRL first, followed by OCSP (this is the default behavior).
If the CRL is not available, OCSP is used as a backup.
If OCSP is not available, CRL is used as a backup.

General Configuration for Certificate Validation Protocols

You can configure how NNMi checks for revoked certificates. For example, you can configure the order in which protocols are used, and whether all the protocols are used.

NNMi uses the nms-auth-config.xml file to configure such settings.

Configure Protocol Order

By default, NNMi performs CRL checking, and then OCSP checking.

To configure the order in which the certificate validation protocols check for revoked certificates:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux:$NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <revocation> section of the file (find the <revocation> tag), search for the line that begins with the following text:
```
<ordering>
```
Do one of the following:
- To specify that CRL checking is to be used first, followed by OCSP, edit the line to read as follows:
```
<ordering>CRL OCSP</ordering>
```
- To specify that OCSP checking is to be used first, followed by CRL, edit the line to read as follows:
```
<ordering>OCSP CRL</ordering>
```
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Configure Protocol Requests

You can configure NNMi to do either of the following with regard to protocol requests:

Check all certificate validation protocols for each certificate
Check the protocol list in the preferred order and stop when a valid response is received

To configure protocol requests:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <revocation> section of the file (find the <revocation> tag), search for the line that begins with the following text:
```
<mode>
```
Do one of the following:
- To have NNMi check all protocols for each certificate, edit the line to read as follows:
```
<mode>CHECK_ALL</mode>
```
- To have NNMi check the protocol list in the preferred order and stop when a valid response is received, edit the line to read as follows:
```
<mode>FIRST_SUCCESS</mode>
```
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Validate Certificates Using CRLs

NNMi uses CRLs to properly deny access to clients using a certificate that is no longer trusted.

During authentication, when a certificate's serial number is found in a CRL, NNMi does not accept that certificate and authentication fails.

NNMi checks CRLs by default when using X.509 authentication mode; however, you can specify a CRL by editing the nms-auth-config.xml file, as described in the following sections:

NNMi stores the CRL configuration in the following location:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml
Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml

There is also a default version of the configuration file, which can be used for reference purposes to view new available options. The default configuration file is stored in the following location:

Windows: %NnmInstallDir%\newconfig\HPOvNnmAS\nmsas\conf\nms-auth-config.xml
Linux: $NnmInstallDir/newconfig/HPOvNnmAS/nmsas/conf/nms-auth-config.xml

Enable and Disable CRL Checking

By default, NNMi enables CRL checking.

To configure CRL checking:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <crl> section of the file (find the <crl> tag), search for the line that begins with the following text:
```
<enabled>
```
Do one of the following:
- To enable CRL checking, change the line to read as follows:
```
<enabled>true</enabled>
```
- To disable CRL checking, change the line to read as follows:
```
<enabled>false</enabled>
```
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Change the CRL Enforcement Mode

By default, NNMi is set to enforce CRLs.

To change the product’s enforcement of CRLs:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <crl> section of the file (find the <crl> tag), search for the line that begins with the following text:
```
<mode>
```
Change the line to read as one of the following:
```
<mode><value></mode>
```
where <value> is one of the following:
- ENFORCE: Enforce CRLs where specified in the certificates
- ATTEMPT: Check CRLs but allow access if the CRL is not available
- REQUIRE: Require and enforce CRLs in certificates
In REQUIRE mode, authentication will fail if there is no CRL specified or available for a user's certificate.
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Change How Often a CRL Should be Refreshed

To configure how often NNMi refreshes the CRL:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <crl> section of the file (find the <crl> tag), search for the line that begins with the following text:
```
<refreshPeriod>
```
Change the line to read as follows:
```
<refreshPeriod><value></refreshPeriod>
```
where <value> is the integer number of hours or days (the smallest value is 1h).

For example, enter 24h for 24 hours; enter 2d for 2 days.
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Change the Maximum Idle Time for a CRL

You can configure how long NNMi keeps a CRL after the CRL has been idle (has not been used or accessed).

To change the maximum idle time for a CRL:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <crl> section of the file (find the <crl> tag), search for the line that begins with the following text:
```
<maxIdleTime>
```
Change the line to read as follows:
```
<maxIdleTime><value></maxIdleTime>
```
where <value> is the integer number of hours or days (the smallest value is 1h).

For example, enter 24h for 24 hours; enter 2d for 2 days.
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

CRL Expiration Warnings

When CRL checking is enabled, if a CRL expires, users might be locked out of the NNMi console. To help avoid unwanted lockouts, NNMi provides health warning messages to alert administrators that a CRL has either expired or will be expiring soon.

The expired CRL warning (Major severity) occurs when one or more CRLs have expired.

The expiring CRL warning (Minor severity) occurs when one or more CRLs has less than 1/6th of its valid period remaining. For example, if a CRL is valid for 24 hours, NNMi displays a warning if the CRL expires in fewer than four hours.

Configure the refresh period such that CRLs are always kept fresh. A properly configured refresh period ensures that, if the CRL server is unavailable for a time, there is a sufficient valid period remaining for the downloaded CRLs. In this way, NNMi can continue normal operation until the CRL server is available. In this example, a refresh period of eight hours might be appropriate.

Change the Location for a CRL

By default, NNMi downloads CRLs from the HTTP location embedded in the certificate. If this location is not accessible to the NNMi management server, the administrator can obtain the required CRLs some other way and configure NNMi to load those CRLs from the local file system.

Only CRLs signed by the certificate issuer are considered when evaluating the certificate.

To configure NNMi to load CRLs from the local file system:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <crl> section of the file (find the <crl> tag), search for the following text block:
Insert a line after the --> tag, and enter the following, based on your operating system:

Windows: <location>file:///C:/CRLS/<crlname>.crl</location>

Linux: <location>file:///var/opt/OV/shared/nnm/certificates/<crlname>.crl </location>
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Validate Certificates Using Online Certificate Status Protocol (OCSP)

NNMi supports Online Certificate Status Protocol (OCSP) to check for revoked certificates interactively.

PKI user authentication uses OCSP to verify the revocation status of a certificate by querying an OCSP responder. An OCSP responder provides immediate and accurate revocation information on specific certificates as follows:

An OCSP client submits a certificate status request to an OCSP responder.
The OCSP client suspends acceptance of the certificate in question until the OCSP responder provides a digitally signed response.
The OCSP responder indicates the status of the certificate by returning one of the following values:
- Good (pass; user is granted access)
- Revoked (fail; user is denied access)
- Unknown (fail; user is denied access)

Because the OCSP responder is queried for every certificate, whereas the CRL is downloaded periodically (for example, once per day), OCSP responses might be more up-to-date than corresponding CRLs.

NNMi stores the OCSP configuration in the following location:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml
Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml

A default version of the configuration file can be used for reference purposes to view new available options. The default configuration file is stored in the following location:

Windows: %NnmInstallDir%\newconfig\HPOvNnmAS\nmsas\conf\nms-auth-config.xml
Linux: $NnmInstallDir/newconfig/HPOvNnmAS/nmsas/conf/nms-auth-config.xml

Enable and Disable OCSP Checking

To configure OCSP checking:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <ocsp> section of the file (find the <ocsp> tag), search for the line that begins with the following text:
```
<enabled>
```
Do one of the following:
- To enable OCSP checking, change the line to read as follows:
```
<enabled>true</enabled>
```
- To disable OCSP checking, change the line to read as follows:
```
<enabled>false</enabled>
```
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Change the OCSP Enforcement Mode

By default, NNMi is set to enforce OCSP.

To change the product’s enforcement of OCSP:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <ocsp> section of the file (find the <ocsp> tag), search for the line that begins with the following text:
```
<mode>
```
Change the line to read as one of the following:
```
<mode><value></mode>
```
where <value> is one of the following:
- ENFORCE: Enforce OCSP where specified in the certificates
- ATTEMPT: Check OCSP but allow access if OCSP is not available
- REQUIRE: Require and enforce OCSP in certificates
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Enable Nonce

For added security (to avoid replay attacks), an OCSP requester can add a nonce to the certificate validation request. A nonce is a random number, attached to each request, that alters the encryption. When the nonce feature is enabled, the OCSP responder computes an appropriate response using the nonce value.

Using a nonce puts more load on the OCSP responder because it cannot precalculate or cache responses. Some OCSP responders may not accept requests with a nonce.

The nonce feature is disabled by default.

To enable the OCSP nonce feature:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <ocsp> section of the file (find the <ocsp> tag), search for the line that begins with the following text:
```
<nonce>
```
Do one of the following:
- To enable the nonce feature, change the line to read as follows:
```
<nonce>true</nonce>
```
- To disable the nonce feature (and use a general request), change the line to read as follows:
```
<nonce>false</nonce>
```
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Specify the URL of the OCSP Responder

Optionally, you can specify the URL of the OCSP responder as follows:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Within the <ocsp> section of the file (find the <ocsp> tag), search for the line that begins with the following text:
```
<responder>
```
Edit the line to read as follows:
```
<responder><URL></responder>
```
where <URL> is the URL associated with the OCSP responder.
Save the nms-auth-config.xml file.
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

The OCSP URL must use the HTTP protocol.

If there is no OCSP URL specified in the nms-auth-config.xml file, NNMi attempts to obtain an OCSP responder from the certificate itself.
If there is no OCSP responder specified in the certificate, NNMi uses the <mode> setting to determine what action to take:
- If the mode is ENFORCE or ATTEMPT, NNMi passes the OCSP validation step for this certificate.
- If the mode is REQUIRE, NNMi rejects the certificate.

Configure NNMi to Restrict Certificates Used for NNMi Logon Access

If you are using NNMi with PKI user authentication, you might want to restrict which certificates are considered valid for NNMi logon access.

NNMi supports the following types of restrictions:

Restrictions on the certificate extended key usage, which can be used to restrict NNMi access to hardware-based certificates or other specific certificates.
Restrictions on the certificate issuer. These restrictions are intended to prevent a trusted certificate, which is loaded for purposes other than log on purposes, from being used to create log on certificates.

To configure NNMi to restrict certificates used for log on access:

Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml
Locate the text block containing the following:
```
<certificateConstraints>
```
Use the following examples as a guide to configure NNMi to restrict certificates used for logons (replace values as appropriate):

Example 1: To require client authentication, edit the following section:



<extKeyUsage>1.3.6.1.5.5.7.3.2</extKeyUsage>

Example 2: To require users to log on using a Microsoft smart card:



<extKeyUsage>1.3.6.1.4.1.311.20.2.2</extKeyUsage>

Example 3: To accept only certificates signed by a particular CA:



<trustedIssuer>CN=MyIssuer, OU=MyOrgUnit, O=MyOrg, ST=CO, C=US</trustedIssuer>

When multiple extKeyUsage entries are specified, the certificate must contain all of them (Boolean AND). When multiple trustIssuer entries are specified, only one must be the certificate trust issuer (Boolean OR).
Run the following command for the change to take effect:
```
nnmsecurity.ovpl -reloadAuthConfig
```

Example: Configure NNMi to Require a Smart Card Logon

The following example illustrates how to configure NNMi to use PKI user authentication to require a smart card logon.

This example uses the Mixed user authentication strategy.

This example makes the following assumptions:

The organization is using smart cards for logging on to NNMi.
The smart card contains a certificate with an email address in the Subject Alternative Name field.
The organization uses CRLs to check revocation for all certificates.

To complete the example configuration:

In the NNMi console, create a user called myusername@example.com with guest privileges.
1. From the User Accounts view, create the myusername@example.com user.
  
  On the User Account form, be sure to select the Directory Service Account check box and leave the Password field blank. For more information, see the NNMi help.
2. From the User Account Mappings view, create a new user account mapping to assign the myusername@example.com user to the NNMi Guest Users user group.
Edit the following file:

Windows: %NnmDataDir%\nmsas\NNM\conf\nms-auth-config.xml

Linux: $NnmDataDir/nmsas/NNM/conf/nms-auth-config.xml

Search for the following text block:

<realm name="console">

<mode>FORM</mode>

</realm>

To enable X.509 certificate authentication, edit the text to read as follows:
```
<realm name="console">
```
```
<mode>X509</mode>
```
```
</realm>
```
Search for the following text block:
```
<principalMapping>
```
In the <principalMapping> block, include the following line to extract the first match of type rfc822Name from the Subject Alternative Name field of the certificate:
```
<subjectAlternativeName type="rfc822Name" />
```
Within the <crl> section of the file (find the <crl> tag), search for the line that begins with the following text:
```
<enabled>
```
To enable CRL checking, change the line to read as follows:
```
<enabled>true</enabled>
```
Within the <crl> section of the file, locate the text block containing the following text:
```
<mode>
```
To require and enforce CRLs, change the line to read as follows:
```
<mode>REQUIRE</mode>
```
Locate the text block containing the following:
```
<certificateConstraints>
```

To require client authentication, edit the following section:

<!-- client authentication -->

<extKeyUsage>1.3.6.1.5.5.7.3.2</extKeyUsage>

To require users to log on using a Microsoft smart card, add the following lines:

<!-- Microsoft smart card logon -->

<extKeyUsage>1.3.6.1.4.1.311.20.2.2</extKeyUsage>

Save your changes to the nms-auth-config.xml file.
Change to the directory on the NNMi management server that contains the nnm-trust.p12 files:

Windows: %NnmDataDir%\shared\nnm\certificates

Linux: $NnmDataDir/shared/nnm/certificates
Import your trusted CA certificate into the nnm-trust.p12 file. Suppose the example_ca.cer file contains the certificate you must use. Run the following command to import the CA certificate into the NNMi nnm-trust.p12 file:

Windows: %NnmInstallDir%\bin\nnmkeytool.ovpl -import -alias myca -storetype PKCS12 -keystore nnm-trust.p12 -file example_ca.cer

Linux: $NnmInstallDir/bin/nnmkeytool.ovpl -import -alias myca -storetype PKCS12 -keystore nnm-trust.p12 -file example_ca.cer
Ensure that the user account’s name matches the user name contained in the certificate (myusername).
Restart the NNMi services:
- Run the ovstop command on the NNMi management server.
- Run the ovstart command on the NNMi management server.

NNMi is now configured to require a smart card logon.

The following text is similar to how the nms-auth-config.xml file might appear after making the configuration changes described in this example:

<methods>

   <X509>

      <principalMapping>

           <subjectAlternativeName type="rfc822Name" />

      </principalMapping>

      <certificateConstraints>

           <extKeyUsage>1.3.6.1.5.5.7.3.2</extKeyUsage>

           <extKeyUsage>1.3.6.1.4.1.311.20.2.2</extKeyUsage>

           <trustedIssuer>CN=MyIssuer, OU=MyOrgUnit, O=MyOrg, ST=CO, C=US</trustedIssuer>

      </certificateConstraints>

      <revocation>

         <ordering>CRL OCSP</ordering>

          <mode>CHECK_ALL</mode>

       </revocation>

       <crl>

          <enabled>true</enabled>

           <mode>REQUIRE</mode>

           <!-- refresh CRLs every 12 hours -->

           <refreshPeriod>12h</refreshPeriod>

            <!-- remove CRLs that have not been used for 36 hours -->

            <maxIdleTime>36h</maxIdleTime>

        </crl>

        <ocsp>

          <enabled>false</enabled>

          <mode>ENFORCE</mode>

          <nonce>false</nonce>

        </ocsp>

  </X509>

</methods>

<realms>

  <realm name="console">

  <mode>X509</mode>

   </realm>

</realms>

Configure CLI Authentication for PKI User Authentication

Authorized users can use the NNMi command line interface (CLI) to configure NNMi settings without having to navigate the NNMi console.

Public Key Infrastructure (PKI) user authentications depend on client-side operating system and web browser settings to perform user authentication. Therefore, CLI sessions cannot use PKI user authentication because the commands run outside the web browser environment. To enable CLI authentication as a non-root user, you can provide authorized users read access to the following file (root users already have read access to this file):

Windows: %NnmDataDir%\nmsas\NNM\conf\props\nms-users.properties

Linux: $NnmDataDir/nmsas/NNM/conf/props/nms-users.properties

This file contains the encrypted password for the NNMi “system” user. Any user who can read this file can invoke CLI commands as the “system” user.

Windows users who log on as a member of the Administrators group already have read access to the nms-users.properties file, so no further configuration is necessary for Windows users who belong to the Administrators group. For more information about configuring security, see the NNMi help .

Read access to the nms-users.properties file can be achieved using the normal Linux chmod command. However, it is recommended to configure operating system-based Access Control Lists (ACLs) to provide fine-grained access control to this file. For more information, see "Set ACLs to Enable Non-root Users to Run CLI Commands" .

Set ACLs to Enable Non-Root Users to Run CLI Commands

ACL commands differ widely among operating systems and file system types on the same operating system. In addition, you might need to configure the operating system to enable ACLs; for example, adding a ,acl entry to /etc/fstab on Linux.

This section provides an example using Linux (RHEL and SuSE) ACL commands with ext3 and ext4 file systems. If you are using a different file system type or operating system, see your operating system ACL documentation for more information.

This example gives the operating system user user1 read permission for the nms-users.properties file.

When setting ACL permissions, specify the complete set of permissions for the given file. The provided permissions overwrite the previous permissions.

Grant permission

Query the current ACLs using the following command:

chacl –l nms-users.properties

The output will look something like the following:

nms-users.properties [u::rw-,u:user2:r--,u:user3:r--,g::r--,m::r--,o::---]

Append the new permission (,u:user1:r--) to the list output in the square brackets ([ ]), and run the following command:

chacl <results from within square brackets in the ACL list>,u:user1:r-- nms-users.properties

ACLs provide user-level control, group-level control, or both. You could also create a Linux group; for example, nnmiadm, and then provide read access to the nms-users.properties file to the group. Then, by adding or removing Linux users to or from that group, you are also granting or removing access to the nms-users.properties file, thereby granting or removing authentication as “system” user to CLI commands.

Use caution when setting ACLs because incorrect settings that prevent permissions for the nmsproc user or nmsgrp group can cause NNMi to stop functioning.

List ACLs

Run the following command:

chacl -l nms-users.properties

Remove permission

Query the current ACLs using the following command:
```
chacl –l nms-users.properties
```
Identify and delete the user that you want to delete (user1): ,u:user1:r--
Paste the rest of the ACL listing into the chacl command:
```
chacl <list results minus user1> nms-users.properties
```

Each of the directories in the nms-users.properties file path must be accessible. Normally the permission for these folders is very restrictive, preventing access. This path includes the following directories:

$NnmDataDir/nmsas
$NnmDataDir/nmsas/NNM
$NnmDataDir/nmsas/NNM/conf
$NnmDataDir/nmsas/NNM/conf/props

You can use ACLs also on these folders, or regular Linux chmod to grant “search” access (in other words, the execute bit, or 0711 mode) to “other”.

Running the nnmrestore.ovpl command to restore from an NNMi backup, overwrites the existing ACLs. In this case, after restoring NNMi, recreate and apply your ACLs manually using the procedure for adding users to ACLs described earlier in this section.

In an application failover or high availability (HA) environment, you must set ACLs on both nodes manually by logging onto the primary node, running the appropriate ACL commands, and then repeating the process on the secondary node.

In a Global Network Management (GNM) environment, each separate node might have its own ACLs with different users. For example, a user that has CLI access on a regional manager may not have CLI access on the global manager.

Troubleshoot PKI User Authentication Issues

During PKI user authentication, a user might encounter an error. See the following table for a listing of errors and possible causes.

PKI User Authentication Errors and Possible Causes
Error Message	Possible Cause
401 Not Authenticated	Use of HTTP rather than HTTPS. See "Configure NNMi_Deployment to Require Encryption for Remote Access" for more information.
	User does not have a certificate. See "Manage Certificates" for more information.
	User certificate is not trusted by a CA in the `nnm-trust.p12`.
	User certificate is expired or not yet valid.
	User certificate has been revoked or revocation check failed.
	User certificate failed a constraint check. See Configure NNMi to Restrict Certificates Used for NNMi Logon Access for more information.
403 Not Authorized	Mapped user name does not exist in NNMi or the LDAP directory service. See Configure NNMi for PKI User Authentication (X.509 Certificate Authentication) for more information.
	Certificate principal to user name mapping is incorrect. See Configure NNMi for PKI User Authentication (X.509 Certificate Authentication) for more information.
	User is not in a user group that provides access to the NNMi console. See Configuring Security in the NNMi help for more information.

To troubleshoot, disable HTTP access and turn on logging to help identify issues.

Send Help Center feedback