Using ldapsearch tool to explore your LDAP/AD for integration with Allure TestOps

Modified on Mon, 24 Feb at 3:44 PM

Integration with LDAP is quite (actually it's very-very) tricky.

When setting up the integration with your LDAP/AD please consider having LDAP admin nearby, you won't be able to configure the integration without this guy, and it's better if you don't start groups configuration if you haven't LDAP admin nearby.

The sequence

In this manual we explain the configuration in the following sequence:

Exploring our (your) LDAP.
Configuring LDAP authentication.
[optionally]Configuring LDAP groups for role assignment.
1. this is to be done if you want to have automatic global role assignment (Admin, User, Guest) done based on the end user membership in an LDAP group.

We strongly recommend the said sequence, do not try to implement all together, it's hard to troubleshoot (based on the real events, at the request of the survivors, the names have been changed).

Exploring LDAP

Before incorporating the LDAP settings to Allure TestOps configuration, we need to check these settings are, indeed, correct.

To do so, we need to send a request to LDAP and get a sensible response.

ldapsearch -x -H "<LDAP URI>" -b "<Base DN>" -D "<User DN>" -w "<User Pass>" "<Search>"

Query parameters

To verify the settings we need to have the following data:

LDAP URI - this is the host where LDAP reside, e.g.ldap://localhost:389
Base DN - it is the starting point to search for user authentication within a directory, e.g. dc=springframework,dc=org
User DN - it is the distinguishable name of the user, we are going to use to send the requests towards LDAP, e.g. cn=admin,dc=springframework,dc=org, this User's DN will be used by Allure TestOps server. This can be (better be) a service account with read only rights to execute the request searches on LDAP/AD side.
UserPass - is is the password of the user from #3, say it will be allure.
Search - it is the search query we're going to send to LDAP server, say we're going to find a user with the uid bob, i.e. uid=bob (name is changed).

Final example of the search string:

ldapsearch -x -H "ldap://ldap.springframework.org:389" -b "dc=springframework,dc=org" -D "cn=admin,dc=springframework,dc=org" -w "allure" "(uid=bob)"

The command above will result in a result that will look something like the stuff shown below:

# extended LDIF
#
# LDAPv3
# base <dc=springframework,dc=org> with scope subtree
# filter: uid=bob
# requesting: ALL
#

# Bugs Bunny, People, springframework.org
dn: cn=Bugs Bunny,ou=People,dc=springframework,dc=org
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
loginShell: /bin/bash
homeDirectory: /home/bob
uid: bob
cn: Bugs Bunny
uidNumber: 10001
description: stuff
sn: Bunnny
givenName: Bugs
initials: BB
mail: [email protected]
gidNumber: 10001

Using the response

Now, what do we need from our response to configure Allure TestOps...

Defining LDAP user search base and users search filter

in the results we have

dn: cn=Bugs Bunny,ou=People,dc=springframework,dc=org

This string gives us the user search base:

ou=People,dc=springframework,dc=org

So, here we'll look for our users. Please also confirm this with LDAP admin, we receommended to invite them in the very beginning of our story.

As soon as we received the data from the LDAP/AD, we can start configuration of Allure TestOps instance for the integration.

Docker compose

First of all, there is a dedicated configuration files set for the integration with LDAP called testops-ldap.

The .env file has the following lines to be filled for simple authentication without the groups sync:

LDAP_URL="ldap://ldap.springframework.org:389"
LDAP_LOGIN_SA="cn=service-ro-account,dc=springframework,dc=org"
LDAP_LOGIN_SA_PASS=StrongestPassword-of-service-ro-account
LDAP_DEFAULT_ROLE=ROLE_GUEST
LDAP_USER_SEARCH_BASE="ou=People,dc=springframework,dc=org"
LDAP_USER_SEARCH_FILTER="(&(uid={0})(objectClass=person)"
LDAP_UID_ATTRIBUTE=uid

Here we assume uid is used by the end users to log-in to LDAP.

Helm chart

Helm chart deployment configuration is to be done in values.yaml file. Specifically we need to use the following lines

auth:
  primary: ldap
  # Allowed roles: ROLE_ADMIN, ROLE_USER, ROLE_GUEST
  defaultRole: ROLE_GUEST
  ldap:
    enabled: true
    auth:
      user: cn=service-ro-account,dc=springframework,dc=org
      pass: StrongestPassword-of-service-ro-account
    referral: follow
    url: ldap://ldap.springframework.org:389
    usernamesToLowercase: true
    passwordAttribute: userPassword
    user:
      # dnPatterns must not be used with searchFilter
      dnPatterns: "" #keep this empty
      searchBase: ou=People,dc=springframework,dc=org
      searchFilter: (&((objectClass=Person))(uid={0}))

Linux packages

In linux packages configuration happens in the file called testops.conf residing at /opt/testops/conf/testops.conf

ALLURE_LOGIN_PRIMARY=ldap
ALLURE_LOGIN_LDAP_ENABLED=true
ALLURE_LOGIN_LDAP_REFERRAL=follow
ALLURE_LOGIN_LDAP_URL=ldap://ldap.springframework.org:389
ALLURE_LOGIN_LDAP_USERSEARCHBASE='ou=People,dc=springframework,dc=org'
ALLURE_LOGIN_LDAP_USERSEARCHFILTER='(&(uid={0})(objectClass=person)'
ALLURE_LOGIN_LDAP_UIDATTRIBUTE=uid
ALLURE_LOGIN_LDAP_DEFAULTROL=ROLE_GUEST
ALLURE_LOGIN_LDAP_USERDN='cn=service-ro-account,dc=springframework,dc=org'
ALLURE_LOGIN_LDAP_PASSWORD=StrongestPassword-of-service-ro-account
ALLURE_LOGIN_LDAP_LOWERCASEUSERNAMES=true
ALLURE_LOGIN_LDAP_SYNCROLES=false

# these to be uncommented if we want to use the sync of LDAP groups with Allure TestOps global roles
# ALLURE_LOGIN_LDAP_GROUPSEARCHBASE=
# ALLURE_LOGIN_LDAP_GROUPSEARCHFILTER=
# ALLURE_LOGIN_LDAP_GROUPROLEATTRIBUTE=
# ALLURE_LOGIN_LDAP_GROUPAUTHORITIES_ROLEUSERGROUPS=
# ALLURE_LOGIN_LDAP_GROUPAUTHORITIES_ROLEADMINGROUPS=