How to configure DevTest with LDAP/LDAPS?

Document ID : KB000100974
Last Modified Date : 09/10/2018
Show Technical Document Details
Introduction:
You can configure access control (ACL) so that user authentication is based on the information in an LDAP server, multiple LDAP servers, the database, or LDAP servers and the database. The ACL administrator should consult with your LDAP administrator for configuration and implementation that is based on the following properties used with the authentication-providers.xml and ldap-mappings.xml files delivered with DevTest.
Question:
How to configure DevTest to use LDAP/LDAPS?
Answer:
This is configured on the machine where the Registry is running.

* Users must be a member of at least one LDAP group.


* The authentication-providers.xml file and ldap-mappings.xml file are used when connecting to LDAP.

  We provide templates for both files, they are _authentication-providers.xml file and _ldap-mappings.xml.

  To use these templates copy each one in the DEVTEST_HOME folder with the _ in front of each file name to one without a _.

* authentication-provders.xml is used to configure all the LDAP/LDAPS servers you would to search for users that will be authenticated in order to use DevTest.

* The ldap-mappings files can be used to define DevTest roles for the authenticated users to use. 

*These are descriptions of the options in the authentication-providers.xml file:

Example we provide:

    <authentication-provider
            name="Corp. Active Directory Server"
            autoAddUsers="false"
            authenticateOnly="false"
            enabled="true"
            type="ActiveDirectory"
            defaultRole="SV Power"
            rejectUnmappedUsers="true">
            <url>ldaps://server.example.com:3269</url>
            <user-dn>cn=readOnlyUser,ou=users,dc=example,dc=com</user-dn>
            <user-password>drowssap</user-password>
            <user-dn-pattern>cn={0},ou=users,dc=example,dc=com</user-dn-pattern>
            <user-search-base>dc=example,dc=com</user-search-base>
            <user-search-filter>(&amp;(objectClass=user)(sAMAccountName={0}))</user-search-filter>
            <group-search-base>ou=groups</group-search-base>
            <group-search-filter>(member={0})</group-search-filter>
     </authentication-provider>

LDAP:    The provider (case sensitive)

cn    Common Name
ou    Organizational Unit
dc    Domain Component

name:                 
The label for this authentication provider

type:                 
The kind of system the provider is for.  Valid case-sensitve values are ActiveDirectory, LDAP,  Legacy, Custom and Embedded

  Active Directory is a directory services implemented by Microsoft, and it supports Lightweight Directory Access Protocol (LDAP). A server running Active Directory Domain Services (AD DS) is called a domain controller. It authenticates and authorizes all users and computers in a Windows domain type network—assigning and enforcing security policies for all computers and installing or updating software
                      
  LDAP (Lightweight Directory Access Protocol) is an application protocol for querying and modifying items in directory service providers like Active Directory, which supports a form of LDAP.

  Legacy is provided for retro compatibility. The legacy LDAP authentication method uses Oracle Business Intelligence session variables that you define using the Variable Manager in the Oracle BI Administration Tool

  Custom as directory type and not one of the predefined LDAP servers, you must define manually the mapping of entity types to corresponding object classes and the attribute name that is used to determine group membership.

  Embedded LDAP server is the default security provider database for the WebLogic Authentication, Authorization, Credential Mapping and Role Mapping providers

enabled:             
Controls whether this authentication provider is available for authenticating users

autoAddUsers:         
Controls whether successfully authenticated users are automatically added to the ACL database.  When enabled, DevTest administrators will need to manually remove users from the DevTest database as users are removed from the system.

defaultRole:          
The role to assign to new users upon successful log in if they have no other roles assigned
    
rejectUnmappedUsers: 
Prevent users with no ldap groups mapped to DevTest roles from logging in
    
authenticateOnly:     
Controls whether the authentication provider is only used for authenticating users while their respective accounts are loaded from the ACL database and not generated from LDAP group to role mappings

url:                 
The url of the server

user-dn:              
The distinguished name of the ldap user used to connect to the server
 
user-password:       
The password of the ldap user used to connect to the server
  
user-dn-pattern:      
A pattern which will be used to generate a distinguished name for the LDAP/AD user used to bind to the server.   This element may be specified 0 or more times and the patterns will be tried in the order in which they occur in the <authentication-provider> element.  The pattern argument {0} will contain the username. An example would be "cn={0},ou=users,dc=example,dc=com".
    
user-search-base:     
The relative name to searching for uses

user-search-filter:   
The LDAP filter used to find user entries.  The search filter can include the placeholder '{0}' which will contain the username of
 the user attempting login. As an example, if the filter  '(&(objectClass=user)(sAMAccountName={0}))' used and a user with username, demoUser, then the filter will return only entries that have the objectClass of user and a sAMAccountName attribute value of 'demoUser'. The user-search-filter should ONLY return a single entry.
    
group-search-base:    
The relative name to start searching for groups

group-search-filter:  
The LDAP filter used to find group entries. The search filter can include the placeholder '{0}' which will contain the username of the user attempting login.  As an example, if the filter  '(member={0})' used and a user with username, demoUser, then the filter will return only entries that have an attribute entry with 'member' as the attribute name and demoUser as the value. The group-search-filter can return 0 or more entries.

    
factory-class:
The fully qualified name of a java class that implements the com.ca.dts.security.authentication.AuthenticationProviderFactory interface.

* These are descriptions of the options in the ldap-mappings.xml file:

A <mapping/> element has a required 'role' attribute.  The value of a 'role' attribute is the name of a DevTest role that will contain child
 <groupDN/> elements.  The body of a <groupDN/> element will be the distinguished name of a LDAP/Active Directory group.  Each <mapping/>
 element may contain 0 or more <groupDN/> child elements.

If there are any custom roles created, then they would also need to be specified here as well (see role "Custom"):

    <mapping role="Super User">
    </mapping>
    <mapping role="DevTest Administrator">
    </mapping>
    <mapping role="Test Administrator">
    </mapping>
    <mapping role="System Administration">
    </mapping>
    <mapping role="PF Power">
    </mapping>
    <mapping role="SV Power">
    </mapping>
    <mapping role="Test Power">
    </mapping>
    <mapping role="Runtime">
    </mapping>
    <mapping role="Test Runner">
    </mapping>
    <mapping role="Test Observer">
    </mapping>
    <mapping role="Load Tester">
    </mapping>
    <mapping role="User">
    </mapping>
    <mapping role="Guest">
    </mapping>
    <mapping role="Custom">
    </mapping>

Any custom roles will also have to be defined in the Portal.

* Get the LDAP information from your LDAP Admin, determine the type (ActiveDirectory, LDAP,  Legacy, Custom or Embedded), your admin should also be able to provide all the information you need.

* If you are doing LDAPS (secured LDAP), then all (root, intermediate) the needed certificates must be imported into the DEVTEST_HOME/jre/lib/security/cacerts truststore of where the Registry is running.  
Additional Information:
Troubleshooting:

Make sure all of the users that need access to DevTest have been setup on your LDAP server and are a member of at least one LDAP group.

Make sure your user-dn and user-password are valid.

acl.log and registry.log will show LDAP errors at execution time.

Below are the the most common LDAP authentication issues and these will show in the acl.log file:

Reference below information: (https://www-01.ibm.com/support/docview.wss?uid=swg21290631)

"The exception is [ LDAP: error code 49 - 80090308: LdapErr: DSID-0Cxxxxxx, comment: AcceptSecurityContext error, data xxx, vece ]."

However, there are several values that can indicate what LDAP function is causing the issue. Here are some general references for errors: 

The AD-specific error code is the one after "data" and before "vece" or "v893" in the actual error string returned to the binding process 

525    user not found
52e    invalid credentials
530    not permitted to logon at this time
531    not permitted to logon at this workstation
532    password expired
533    account disabled
534    The user has not been granted the requested logon type at this machine
701    account expired
773    user must reset password
775    user account locked

We allow multiple providers in the authentication-providers.xml file, but do not support a provider in this file calling another provider if it is not configured in the authentication-providers file.

JXplorer - an open source LDAP browser, this is a very good tool for debugging LDAP issues (http://jxplorer.org/downloads/).  If you can access jxplorer with your options, then you should be able to authenticate with DevTest as well.