Administer > Integrate NNMi with a Directory Service through LDAP > LDAP Configuration File Reference

LDAP Configuration File Reference

nms-auth-config.xml

The nms-auth-config.xml file contains the settings for communicating with and building LDAP queries to the directory service in the XML format. This section prov ides a reference of only the elements that are relevant for LDAP configuration.

This file is located as follows:

  • Windows:%nnmdatadir%\nmsas\NNM\conf
  • Linux:$NnmDataDir/nmsas/NNM/conf

By default, the nms-auth-config.xml file available in this location does not contain the XML elements required for LDAP configuration.

You can manually add all the necessary XML elements to this file by following the instructions in this section.

NNMi places a sample nms-auth-config.xml file in a different location, which can be used for reference.

The sample nms-auth-config.xml file is available in the following location:

  • Windows:%nnminstalldir%\newconfig\HPOvNnmAS\nmsas\conf
  • Linux:$NnmInstallDir/newconfig/HPOvNnmAS/nmsas/conf

You can also copy the entire <ldapLogin> element from the sample nms-auth-config.xml file, and then make necessary modifications.

After editing the nms-auth-config.xml file (in the <NnmInstallDir>/nmsas/NNM/conf directory) , force NNMi to read the LDAP configuration again by running the following command:

  • Windows:%nnminstalldir%\bin\nnmldap.ovpl -reload
  • Linux:$NnmInstallDir/bin/nnmldap.ovpl -reload 
<ldapLogin>

<!-- This is the on/off switch for LDAP authentication. Set to true to use LDAP-based authentication--> 

	<enabled>true</enabled>

<!-- This element enables you to specify which users can assign incidents.--> 

	<userRoleFilterList>admin guest level2 level1</userRoleFilterList>

<!-- If <enabled> is set to true, define one or more <configuration> elements to specify LDAP parameters --> 

	<configuration>

<!-- The filter (optional) is matched against the user, that tries to log on, to determine if this is the right configuration to use. This is useful when multiple configurations are specified, to skip non-applicable LDAP servers to reduce log-on time. --> 

	<filter>
	<usernamePattern>.*@microfocus\.com</usernamePattern>
	</filter>

<!-- Time limit for performing searches against the LDAP server -->

	<searchTimeLimit>10000</searchTimeLimit>     
	<connectTimeLimit>10000</connectTimeLimit>

<!-- Define at least one server URL; multiple servers can be specified for High-Availability clusters.--> 

	<server>
	 <hostname>ldaps://ldap.domain1.com</hostname>
	 <secure>true</secure>
	</server>        
	<server>
	  <hostname>ldaps://ldap.domain2.com</hostname>
	 <secure>true</secure>
	</server>

<!---Optional. Bind credential and encrypted password for connecting to LDAP servers that do not support anonymous access.

Use "nnmldap.ovpl -encrypt" to create the encrypted password.--->

	<bindCredential>
                    
	 <bindDN>someUser@some.com</bindDN>
                    
	 <bindCredential>someEncryptedPassword</bindCredential>
                
	</bindCredential>

<!-- This element defines the rules to search for users in this LDAP configuration -->

	<users>

<!-- Optional. Filter that is matched against the user that attempts to log on. The intention is to skip non-applicable LDAP configurations to reduce the log-on time. Note that this is a Java regular expression.-->

	 <filter>
	  <usernamePattern>.*some\.com</usernamePattern>
	 </filter>

<!-- Optional. The display name expression to show in the NNMi console.-->

	 <displayName>${sn},${givenName} (Microfocus)</displayName>

<!-- Optional. Default roles that are given to all users that are authenticated against this configuration -->

	 <defaultRoles>
           <role>guest</role>
	 </defaultRoles>

<!-- One or more search configuration for locating user accounts. The pattern "{0}" in the string will be replaced with the log-on name entered by the user in the log-on screen. -->


	 <userSearch>
	  <base>uid={0}</base>
	  <baseContextDN>ou=People,o=domain.com</baseContextDN>
	 </userSearch>
	</users>

<!-- Defines the rules to search for user roles or groups in this LDAP configuration --> 

	<roles>

<!-- Optional. Filter that defines which users should be attempted for role lookup against this configuration. Note that this is a Java regular expression. --> 

	 <filter><usernamePattern>x</usernamePattern></filter>

<!-- One or more search configuration for locating LDAP groups that contain the authenticated user DN. Use the string "{1}" where the user's DN would appear. --> 

	 <roleSearch>

  	  <roleBase>member={1}</roleBase>
  	  <roleContextDN>ou=Groups,o=some.com</roleContextDN>
	 </roleSearch>
                    
	 <roleSearch>

   	  <roleBase>GroupMember={1}</roleBase>                      
   	  <roleContextDN>CN=Groups,DC=mycompany,DC=com</roleContextDN>
	 </roleSearch>
                
	</roles>	
</configuration>
 
</ldapLogin>

ldap.properties

Note The ldap.properties file is now deprecated.

The ldap.properties file contains the settings for communicating with and building LDAP queries to the directory service. This file is located as follows:

  • Windows: %NNM_SHARED_CONF%\ldap.properties
  • Linux: $NNM_SHARED_CONF/ldap.properties

Note You cannot configure NNMi to work with multiple LDAP servers in different domains if you use the ldap.properties file.

In the ldap.properties file, the following conventions apply:

  • To comment out a line, begin that line with a number sign character (#).

  • The following rules apply to special characters:

    • To specify a backslash character (\), comma (,), semicolon (;), plus sign (+), less than sign (<), or greater than sign (>), escape the character with a backslash character. For example: \\ or \+
    • To include a space character ( ) as the first or last character in a string, escape the space character with a backslash character (\).
    • To include a number sign character (#) as the first character in a string, escape the number sign character with a backslash character (\).

    Characters not mentioned here do not need to be escaped or quoted.

Note After editing the ldap.properties file, force NNMi to re-read the LDAP configuration by running the following command:

nnmldap.ovpl -reload

The following table describes the parameters in the ldap.properties file.

Note The initial ldap.properties file might not include all parameters that are listed in the following table. Add the parameters you need.

Parameters in the ldap.properties File

Parameter

Description

java.naming.provider.url

Specifies the URL for accessing the directory service.

The format is the protocol (ldap), followed by the fully-qualified host name of the directory server, optionally followed by the port number. For example:

java.naming.provider.url=ldap://ldap.example.com:389/

If the port number is omitted the following defaults apply:

  • For non-SSL connections, the default port is 389.
  • For SSL connections, the default port is 636.

If you specify multiple directory service URLs, NNMi uses the first directory service when possible. If that directory service is not accessible,NNMi queries the next directory service in the list, and so forth. Separate each URL with a single space character. For example:

java.naming.provider.url=ldap://ldap1.example.com/ ldap://  ldap2.example.com/

Configuring this parameter enables LDAP communication between NNMi and the directory service. To disable LDAP communication, comment out this parameter, and then save the file. NNMi ignores the configuration in the ldap.properties file.

java.naming.security.protocol

Specifies the connection protocol specification.

  • If the directory service is configured to use LDAP over SSL, set this parameter to ssl. For example:
    java.naming.security.protocol=ssl
  • If the directory service does not require SSL, leave this parameter commented out.

For more information, see Configuring an SSL Connection to the Directory Service.

bindDN

For a directory service (such as Active Directory) that does not permit anonymous access, specify the user name for accessing the directory service.

For example:

bindDN=region1\\john.doe@example.com
  • If you plan to add the password in plain text, specify a user name with read-only access to the directory service.
    For example:
    bindCredential=PasswordForJohnDoe
  • If you plan to specify an encrypted password, use the following command to encrypt the plain text password before adding it to the ldap.properties file:
    nnmldap.ovpl -encrypt <mypassword>
    For example: bindCredential={ENC}uaF22C+0CF9VozBVYj8OAw==

    This encrypted password only works for the NNMi instance you create it for. Do not attempt to use it for a different NNMi instance.
    For more information see the nnmldap.ovpl reference page, or the UNIX manpage.

bindCredential

When bindDN is set, specifies the password for the user name that bindDN identifies. For example:

bindCredential=PasswordForJohnDoe

baseCtxDN

Specifies the portion of the directory service domain that stores user records.

The format is a comma-separated list of directory service attribute names and values. For example:

  • baseCtxDN=CN=Users,DC=ldapserver,DC=example,DC=com
  • baseCtxDN=ou=People,o=example.com

For more information, see User Identification.

baseFilter

Specifies the format of user names for signing in to NNMi.

The format is the name of the directory service user name attribute and a string that relates the entered user sign-in name to the format of names in the directory service. The user name string contains the expression {0} (to denote the user name entered for sign in) and any other characters that are needed to match the directory service formatting of user names.

  • If the user name entered for NNMi sign in is the same as the user name stored in the directory service, the value is the replacement expression. For example:

    • baseFilter=CN={0}
    • baseFilter=uid={0}

  • If the user name entered for NNMi sign in is a subset of the user name stored in the directory service, include the additional characters in the value. For example:

    • baseFilter=CN={0}@example.com
    • baseFilter=uid={0}@example.com

For more information, see User Identification.

defaultRole

Optional. Specifies a default role that applies to any directory service user who signs in to NNMi through LDAP. The value of this parameter applies regardless of where user group mappings are stored (in the NNMi database or in the directory service).

If a user is directly configured for a predefined NNMi user group, NNMi grants the user the superset of privileges for the default role and the assigned user group.

Valid values are as follows: admin, level2, level1, or guest.

Note that although admin is a valid value, you should use caution and consider the implications of making admin a default role.

These names are the unique names of the predefined NNMi user group names.

For example:

defaultRole=guest

If commented out or omitted, NNMi does not use a default role.

rolesCtxDN

Specifies the portion of the directory service domain that stores group records.

The format is a comma-separated list of directory service attribute names and values. For example:

  • rolesCtxDN=CN=Users,DC=ldapserver,DC=example,DC=com
  • rolesCtxDN=ou=Groups,o=example.com

In other directory services (not Active Directory), for a faster search, you can identify one or more directory service groups that contain NNMi user groups. If the group names form a pattern, you can specify a wildcard. For example, if the directory service includes groups named USERS-NNMi-administrators, USERS-NNMi-level1Operators, and so forth, you could use a search context similar to:

rolesCtxDN=cn=USERS-NNMi-*,ou=Groups,o=example.com

Configuring this parameter enables directory service queries for NNMi user group assignments through LDAP.

To disable directory service queries for NNMi user group assignments through LDAP, comment out this parameter, and then save the file. NNMi ignores the remaining user group-related values in the ldap.properties file.

For more information, see User Group Identification.

roleFilter

Specifies the format of group member names in the directory service group definitions.

The format is the name of the directory service group attribute for user ID and a string that relates the entered user sign-in name to the format of user IDs in the directory service. The user name string contains one of the following expressions and any other characters that are needed to match the directory service formatting of group member names.

  • The expression {0} denotes the user name entered for sign in (for example, john.doe).
    An example role filter that matches on the (short) user name entered for sign in is:
    roleFilter=member={0}
  • The expression {1} denotes the distinguished name of the authenticated user as returned by the directory service (for example, CN=john.doe@example.com,OU=Users,OU=Accounts,
      DC=example,DC=com
    or
    uid=john.doe@example.com,ou=People,o=example.com).
    An example role filter that matches on the (full) authenticated user name is:
    roleFilter=member={1}

For more information, see User Group Identification.

uidAttributeID

Specifies the group attribute that stores the directory service user ID.

For example:

uidAttributeID=member

For more information, see User Group Identification.

userRoleFilterList

Optional. Limits the NNMi user groups whose associated users can be assigned incidents in the NNMi console.

The user groups in this list apply only to directory service user names authenticated through LDAP. This parameter provides functionality that is not available when NNMi user groups are assigned in the NNMi console and stored in the NNMi database.

The format is a semicolon-separated list of the unique names for one or more predefined NNMi user group names. 

userRoleFilterList=admin;globalops;level2;level1

searchTimeLimit

Optional. Specifies the timeout value in milliseconds. The default value is 10000 (10 seconds). If you are encountering timeouts during NNMi user sign in, increase this value.

For example:

searchTimeLimit=10000

Send Help Center feedback