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 > Use Single Sign-On (SSO) with NNMi

Use Single Sign-On (SSO) with NNMi

This topic includes the following sections:

SSO Access for NNMi
Enable SSO for a Single Domain
Enable SSO for NNMi Management Servers Located in Different Domains
SSO Access for NNMi and the NNM iSPIs
Disable SSO
SSO Security Notes

All content in this chapter is customer visible.

You can configure Network Node Manager i Software (NNMi) single sign-on (SSO) to facilitate access to NNM iSPIs from the NNMi console. With SSO, when you log on to the NNMi console, you receive access to NNM iSPIs and other applications without needing to log on again. SSO provides easier access to NNM iSPIs and other applications while maintaining a secure level of access. After you sign out of the NNMi console (or the NNMi console session times out), you must re-enter your sign-in credentials to access NNM iSPI and other application URLs outside the NNMi console.

SSO is not enabled during installation. If it was, browsing from one NNMi management server to another logs you out of the first one, providing little benefit. To keep this from happening, SSO is initially disabled so you can coordinate setting the initString and protectedDomains parameter among the NNMi management servers. as explained in this chapter.

SSO Access for NNMi

To browse among several NNMi management servers, you must do one of the following:

When making file changes under High Availability (HA), you must make the changes on both nodes in the cluster. 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. See "Maintenance Mode" for more information.

Edit the nms-ui.properties file and make the parameter values for com.hp.nms.ui.sso.initString and com.hp.nms.ui.sso.protectedDomains the same among the NNMi management servers. Make sure to set the com.hp.nms.ui.sso.domain parameter to match the domain an NNMi management server resides in.
- If you have NNMi management servers residing in only one network domain, follow the instructions show in Enable SSO for a Single Domain.
- If you have NNMi management servers residing in more than one network domain, follow the instructions shown in Enable SSO for NNMi Management Servers Located in Different Domains for more information.
Edit the nms-ui.properties file and make sure you have SSO disabled. See Disable SSO for more information.

If you choose to not complete one of these actions, each time you browse to a different NNMi management server, you will be automatically signed out of the previous NNMi management server.

There are special considerations for using SSO with the NNMi global network management feature.

If the domain name of the NNMi management server is short, as in mycompany, without any period (.), the NNMi console will immediately sign you out. The restrictions for SSO browser cookies require a domain name to contain at least one period, such as mycompany.com. To remedy this situation:

Open the following file in a text editor:
- Windows: %NNM_PROPS%/nms-ui.properties
- Linux: $NNM_PROPS/nms-ui.properties
For this example, search for the following string:
```
com.hp.nms.ui.sso.domain = mycompany
```
and replace it with the following string:
```
com.hp.nms.ui.sso.domain = mycompany.com
```
Run the following command to commit the changes:
```
nnmsso.ovpl -reload
```
See the nnmsso.ovpl reference page, or the Linux manpage, for more information.

Enable SSO for a Single Domain

To enable SSO for use in a single domain, complete the following steps:

Open the following file:
- Windows: %NNM_PROPS%\nms-ui.properties
- Linux: $NNM_PROPS/nms-ui.properties
Look for a section in the file that resembles the following:
```
com.hp.nms.ui.sso.isEnabled = false
```
Change this as follows:
```
com.hp.nms.ui.sso.isEnabled = true
```
Look for a section in the file that resembles the following:
```
com.hp.nms.ui.sso.domain = mycompany.com
```
Change mycompany.com to the domain the NNMi management server resides in. Make sure there is only one domain listed when enabling SSO in a single domain.
Look for a section in the file that resembles the following:
```
com.hp.nms.ui.sso.protectedDomains = mycompany.com
```
Change mycompany.com to the domain the NNMi management server resides in. Make sure there is only one protected domain listed when enabling SSO in a single protected domain.
Run the following command to commit the changes:
```
nnmsso.ovpl -reload
```
See the nnmsso.ovpl reference page, or the Linux manpage, for more information.

Enable SSO for NNMi Management Servers Located in Different Domains

You can configure two or more NNMi management servers for SSO. This example explains how to configure SSO for three NNMi management servers located in different domains. If you must configure two or more NNMi management servers for SSO and these systems reside in different domains, complete the following steps:

Open the following file:
- Windows: %NNM_PROPS%\nms-ui.properties
- Linux: $NNM_PROPS/nms-ui.properties
Look for a section in the file that resembles the following:
```
com.hp.nms.ui.sso.isEnabled = false
```
Change this as follows:
```
com.hp.nms.ui.sso.isEnabled = true
```
Look for a section in the file that resembles the following:
```
com.hp.nms.ui.sso.domain = group1.mycompany.com
```
Make sure the domain name contains at least one dot.

Look for a section in the file that resembles the following:

com.hp.nms.ui.sso.protectedDomains=group1.mycompany.com

Change this as follows:

com.hp.nms.ui.sso.protectedDomains=group1.mycompany.com, group2.yourcompany.com, group3.yourcompany.com

Look for a section in the file that resembles the following:
```
com.hp.nms.ui.sso.initString =Initialization String
```
NNMi management servers must share the same initialization string to work in an SSO configuration. Change the initialization string the same value on all NNMi management servers included in the SSO configuration.
Run the following command to commit the changes:
```
nnmsso.ovpl -reload
```
See the nnmsso.ovpl reference page, or the Linux manpage, for more information.
Repeat step 1 through step 6 two more times, configuring the remaining two NNMi management servers. For each remaining NNMi management server, substitute group2 or group3 for group1 during step 3.

SSO Access for NNMi and the NNM iSPIs

After SSO is enabled, SSO between NNMi and the NNM iSPIs does not require initString configuration.

To use SSO, access NNMi as follows:

Use the correct URL in the following form:

<protocol>://<fully_qualified_domain_name>:<port_number>/nnm/ <protocol> represents either http or https.

<fully_qualified_domain_name> represents the official fully-qualified domain name (FQDN) of the NNMi management server.

<port_number> is the port for connecting to the NNMi console, is assigned during NNMi installation, and is specified in the following file:
- Windows: %NnmDataDir%\conf\nnm\props\nms-local.properties
- Linux: $NnmDataDir/conf/nnm/props/nms-local.properties
Log on to NNMi using a valid account.

For SSO to work, URL access to NNMi and the NNM iSPIs must share a common network domain name. Additionally, the URL must not include an IP address. If you do not have a FQDN for the NNMi management server, you can substitute the IP address of the NNMi management server. However, doing so disables single sign-on for NNM iSPIs, and you must log on again the next time you access any NNM iSPI.

To determine the official FQDN of the NNMi management server, use one of the following methods:

Use the nnmofficialfqdn.ovpl command to display the value of the official FQDN set during installation. See the nnmofficialfqdn.ovpl reference page, or the Linux manpage, for more information.
In the NNMi console, click Help > System Information. On the Server tab, look for the official FQDN statement.

If you must change the official FQDN set during installation, use the nnmsetofficialfqdn.ovpl command. See the nnmsetofficialfqdn.ovpl reference page, or the Linux manpage, for more information.

After installation, the system account is still valid. Use the system account only for command-line security and for recovery purposes.

SSO to NNM iSPIs require that users access the NNMi console through a URL that contains the official FQDN. You can configure NNMi to redirect NNMi URLs to the official FQDN when the NNMi console is accessed through a non-official domain name, such as an IP address or a shortened version of the domain name. Before configuring NNMi to redirect URLs, an appropriate official FQDN must be configured. For information, see the NNMi help.

After you enable NNMi to redirect URLs, note the following:

You can log on to the NNMi console using any hostname that is valid for the NNMi management server you want to access.
If you cannot access the NNMi console using http://host.mydomain.com/nnm., use the following to directly access the NNMi console:

<protocol>://<fully_qualified_domain_name>:<port_number>launch?cmd=showMain.
<protocol> represents either http or https.

<fully_qualified_domain_name> represents the official fully-qualified domain name (FQDN) of the NNMi management server.

<port_number> is the port for connecting to the NNMi console, is assigned during NNMi installation, and is specified in the following file:
- Windows: %NnmDataDir%\conf\nnm\props\nms-local.properties
- Linux: $NnmDataDir/conf/nnm/props/nms-local.properties

Disable SSO

If you have a need to disable SSO, complete the following steps:

Open the following file:
- Windows: %NNM_PROPS%\nms-ui.properties
- Linux: $NNM_PROPS/nms-ui.properties
Look for a section in the file that resembles the following:
```
com.hp.nms.ui.sso.isEnabled = true
```
Change the isEnabled property to false:
```
com.hp.nms.ui.sso.isEnabled = false
```
Run the following command to commit the changes:
```
nnmsso.ovpl -reload
```
See the nnmsso.ovpl reference page, or the Linux manpage, for more information.

SSO Security Notes

The initString parameter in SSO security is used as follows:

SSO uses Symmetric Encryption to validate and create an SSO token. The initString parameter within the configuration is used for initialization of the secret key. An application creates a token, and each application that uses the same initString parameter validates the token.

The following information is very important:
- It is not possible to use SSO without setting the initString parameter.
- The initString parameter is confidential information and should be treated as such in terms of publishing, transporting, and persistency.
- Applications that integrate with each other can share the initString using SSO.
- The minimum length of the initString is 12 characters.
Disable SSO unless it is specifically required.
The application that uses the weakest authentication framework, and issues an SSO token that is trusted by other integrated applications, determines the level of authentication security for all the applications.

recommends that only applications using strong and secure authentication frameworks issue an SSO token.
Symmetric encryption implication:

SSO uses symmetric cryptography for issuing and validating SSO tokens. Therefore, any application using SSO can issue a token to be trusted by all other applications sharing the same initString.

This potential risk is relevant when an application sharing the initString either resides or is accessible in an untrusted location.
User roles:

SSO does not share user roles between integrated applications. Therefore, the integrated application must monitor user roles. recommends you share the same user registry (as LDAP/AD) among all integrated applications.

Failure to manage user roles might cause security breaches and negative application behavior. For example, the same user name might be assigned to different roles in the integrated applications.

There could be situations when a user logs on to application A, then accesses application B that uses container or application authentication. The failure to manage the user role will force the user to manually log on to application B and enter a username. If the user enters a different user name than the one used to log on to application A, the following unexpected behavior can arise: If the user subsequently accesses a third application, application C, from application A or application B, then the user will access it using the user names that were used to log on to application A or application B respectively.
Identity Manager is used for an authentication:

All unprotected resources in the Identity Manager must be configured as nonsecure URL settings in the SSO configuration.
SSO demonstration mode:
- Use the SSO demonstration mode for demonstrative purposes only.
- Only use the demonstration mode in unsecured networks.
- Do not use the demonstration mode in production. Any combination of the demonstration mode with the production mode should not be used.

Send Help Center feedback