Enabling LDAP server authentication

LDAP is a standards-based, cross-platform, extensible protocol that runs directly on top of TCP/IP. It is used to access specialized databases called directories.

To avoid maintaining multiple user credentials, you can use the company LDAP server to authenticate user IDs and passwords.

As a prerequisite, the LDAP server must contain user groups that correspond to the required user roles. For more information, see Managing users.

1. From the Header area, click > LDAP > Enable LDAP for Authentication.

2. From the Connection section, configure the following:

   • Server—Type the IP address or the host name of the LDAP server where the authentication occurs. If you want to use encrypted communication between the MVE server and the LDAP server, then do the following:

     1. Use the fully qualified domain name (FQDN) of the server host.

     2. Access the network host file, and then create an entry to map the server host name to its IP address.

        Notes:

        • In a UNIX or Linux operating system, the network host file is typically found at /etc/hosts.
        • In a Windows operating system, the network host file is typically found at %SystemRoot%\system32\drivers\etc.
        • The TLS protocol requires the server host name to match the name of the “Issued To” host specified in the TLS certificate.

   • Port—Enter the port number that the local computer uses to communicate with the LDAP community server. The default port number is 389.

   • Root DN—Type the base distinguished name (DN) of the root node. In the LDAP community server hierarchy, this node should be the direct ancestor of the user node and group node. For example, dc=mvptest,dc=com.

     

     Note: When specifying the Root DN, make sure that only dc and o are part of the Root DN. If ou or cn is the ancestor of the user and group nodes, then use ou or cn in User Search Base and Group Search Base.

3. Configure the search settings.

   • User Search Base—Type the node in the LDAP community server where the user object exists. This node is under the Root DN where all the user nodes are listed. For example, ou=people.

     

     If the users are at multiple-directory hierarchical levels in the LDAP community server, then do the following:

     1. Calculate any common upstream hierarchy of all the possible locations in the user node.

     2. Include the configuration in the User Search Base field.

     Note: To let MVE search for users starting at the Base or Root DN, select Enable Nested User Search and clear the User Search Base field.

   • User Search Filter—Type the parameter for locating a user object in the LDAP community server. For example, (uid={0}).

     

     The User Search Filter function can accommodate multiple conditions and complex expressions.

     Log in using	In the User Search Filter field, type
     Common name	(CN={0})
     Login name	(sAMAccountName={0})
     User principal name	(userPrincipalName={0})
     Telephone number	(telephoneNumber={0})
     Login name or common name	(|(sAMAccountName={0})(CN={0}))

     
     

     Notes:

     • These expressions apply only to the Active Directory® server.
     • For User Search Filter, the only valid pattern is {0}, which means that MVE searches for the MVE user login name.

   • Group Search Base—Type the node in the LDAP community server where the user groups corresponding to the MVE roles exist. This node is also under the Root DN where all the group nodes are listed. For example, ou=group.

     

     Note: A search base consists of multiple attributes separated by commas, such as cn (common name), ou (organizational unit), o (organization), c (country), and dc (domain).

   • Group Search Filter—Type the parameter for locating a user within a group that corresponds to a role in MVE.

     Note: You may use the patterns {0} and {1}, depending on the configuration of your back-end LDAP community server. If you use {0}, then MVE searches for the LDAP user DN. The user DN is retrieved internally during the user authentication process. If you use {1}, then MVE searches for the MVE user login name.

   • Group Role Attribute—Type the attribute that contains the full name of the group. For example, cn.

     

   • Enable Nested Group Search—Search for nested groups within the LDAP community server.

4. Click Binding Information, and then configure the settings.

   • Anonymous Bind—If there is no LDAP configuration stored in MVE, then this option is selected by default. The MVE server does not produce its identity or credentials to the LDAP server to use the LDAP server lookup facility. The follow-up LDAP lookup session uses only unencrypted communication.

   • Simple Bind—Uses unencrypted communication between the MVE server and the LDAP server. If you want the MVE server to use the LDAP server lookup facility, then do the following:

     1. In the Bind DN field, type the bind DN.

     2. Type the Bind Password, and then confirm the password.

        Note: The Bind Password depends on the Bind User settings in the LDAP server. If the Bind User is set as Non-Empty, then a Bind Password is required. If the Bind User is set as Empty, then a Bind Password is not required. For more information, contact your LDAP administrator.

   • TLS—Uses encrypted communication between the MVE server and the LDAP server. The MVE server fully authenticates itself to the LDAP server using the MVE server identity (Bind DN) and credentials (Bind Password).

     For self-signed certificates, the TLS fingerprint must be made available to the system-wide Java Virtual Machine keystore named cacerts. This keystore exists in the [mve.home]/jre/lib/security folder, where [mve.home] is the installation folder of MVE. To configure the settings, do the following:

     1. In the Bind DN field, type the bind DN.

     2. Type the Bind Password, and then confirm the password.

        Note: The Bind Password is required.

   • Kerberos—Uses encrypted communication between the MVE server and the LDAP server. The Kerberos security protocol is supported only in an Active Directory that has GSSAPI implementation. For more information, see the documentation for Kerberos. To configure the settings, do the following:

     1. In the Kerberos Config File field, browse to the krb5.conf file.

        Sample configuration:

        [libdefaults]
            default_realm=ABC.COM
        
        [realms]
            ABC.COM = {
              kdc = abc1.abc.com
            }
        
        [domain_realm]
            .abc.com=ABC.COM

     2. In the Encryption Method menu, select whether to use SSL encryption.

     3. In the KDC Username field, type the Key Distribution Center (KDC) name.

     4. Type the KDC password, and then confirm the password.

     Note: If you want to enable Kerberos Authentication, then see Enabling Kerberos authentication.

5. Click Role Mapping, and then configure the following:

   • Admin—Type the existing role in LDAP that has administrative rights in MVE.

   • Assets—Type the existing role in LDAP that manages the Assets module in MVE.

   • Configurations—Type the existing role in LDAP that manages the Configurations module in MVE.

   • Service Desk—Type the existing role in LDAP that manages the Service Desk module in MVE.

   • Event Manager—Type the existing role in LDAP that manages the Event Manager module in MVE.

   Notes:

   • MVE automatically maps the specified LDAP group to its corresponding MVE role.
   • You can assign one LDAP group to multiple MVE roles, and you may also type more than one LDAP group in a role field.
   • When typing multiple LDAP groups in the role fields, use the vertical bar character (|) to separate multiple LDAP groups. For example, if you want to include the admin and assets groups for the Admin role, then type admin|assets in the Admin field.
   • If you want to use only the Admin role and not the other MVE roles, then leave the fields blank.

6. Click Apply > Close.