Integrate an LDAP account database with Taiga

[TuringTux]

Step 1: Choose the right (fork of the) plugin

LDAP authentication is only possible using a plugin. There are two plugins I want to mention

1. ensky/taiga-contrib-ldap-auth
2. Monogramm/taiga-contrib-ldap-auth-ext

The go-to plugin for LDAP authentication is the Monogramm plugin, it is for example mentioned in the community contributions post in this forum. For some time, my own fork of the plugin existed (the “TuringTux plugin”), however, all contributions there have been merged into the Monogramm plugin, so I am happy to say my fork is no longer relevant.

For the rest of the post, I will work with the Monogramm plugin.

Further resources

• Some Community Contributions
• taiga-contrib-ldap-auth-ext on PyPI
• Comment by the Monogramm plugin maintainer: How mergeability of contributions is ensured

Step 2: Install and configure the plugin in taiga-back

I used the dockerized 30 min setup as described in the forum. In this case, you need to adjust the taiga-back and taiga-front images. We start with the installation and configuration of the plugin in taiga-back.

They are described in more detail in the plugin’s README, please refer to this document:

Plugin installation and configuration of taiga-back

Use the Monogramm plugin directly from Git instead

If you want to use the Monogramm plugin directly from Git (latest, but maybe unstable builds), you can also follow the guide mentioned above, but need to make the following changes to the Dockerfile:

• Replace the following line:

  RUN pip install taiga-contrib-ldap-auth-ext
  

  with:

  RUN pip install git+https://github.com/Monogramm/taiga-contrib-ldap-auth-ext.git
  

• Before the RUN pip install line, insert:

  RUN apt-get update \
      && apt-get install -y git \
      && rm -rf /var/lib/apt/lists/*
  

• After the RUN pip install line, insert:

  RUN apt-get purge -y git \
      && apt-get autoremove -y
  

Further resources

• Taiga 30 min Setup

Step 3: Configure taiga-front

taiga-front needs to be configured to use the ldap installation method. This is also described in the README.

Configuration of taiga-front

(Even) further reading

While writing this post and installing LDAP, I stumbled upon the following resources that might be helpful:

• Taiga 6: How to enable LDAP based login? on Google Groups
• Feature request for LDAP support in the official images on GitHub

[TuringTux]

It took me a day or so to figure this out, so I thought I’d share my progress with the community. If it is not fitting here, please let me know, and I happily take the post somewhere else

[TaigaTeam]

Thank you so much for being so proactive, TurningTux. We’re in the process of properly announcing this new space, so apologies if you don’t receive a quick answer. We do appreciate very much that you’re already contributing though!

[Zohaib09]

Hi

Thankyou @TuringTux for your post, i have been struggling to integrate openldap with taiga 6.1.5 since last week. As you mentioned above i have tried a lot with these two old plugin but no success. I just viewed your code in github. I have installed taiga from source. Can i install your plugin with pip command? And need to configure common.py or config.py in settings. I need your support to integrate taiga with ldap. Thank you

[TuringTux]

Yes, I think it should also be possible to install the plugin when you’ve installed Taiga from source.

The following pip command should still work to install the plugin:

pip install git+https://github.com/TuringTux/taiga-contrib-ldap-auth-ext-2.git

Note: You probably have to be careful about where execute it: I believe one of the older repositories mentioned that virtual environments are used when installing from source. If this is the case (e.g. if you had to execute something like python3 -m venv venv during installation), you need to activate this virtual environment before installing the plugin, using a command similar to:

source venv/bin/activate

(the actual command might differ depending on the name of your virtual environment).

You can configure the plugin either in common.py or config.py, both methods should work. I would recommend to just append the configuration to your config.py file.

[Zohaib09]

Thank you @TuringTux , i try it today and will update here.

[Zohaib09]

Hi

I have installed plugin as per your instruction as below

Following is my config.py appended configuration

INSTALLED_APPS += [“taiga_contrib_ldap_auth_ext”]

LDAP_SERVER = “ldap://192.168.182.144”
LDAP_PORT = 389

LDAP_BIND_DN = “CN=admin,DC=mylab123,DC=com”
LDAP_BIND_PASSWORD = “123456789”

LDAP_SEARCH_BASE = ‘OU=people,mylab123,DC=com’

LDAP_USERNAME_ATTRIBUTE = “uid”
LDAP_EMAIL_ATTRIBUTE = “mail”
LDAP_FULL_NAME_ATTRIBUTE = “givenName”

LDAP_SAVE_LOGIN_PASSWORD = False

LDAP_MAP_USERNAME_TO_UID = None

Following is conf.json

systemctl restart “taiga*”

Sitill i am not able to login with ldap user.

Following is my ldap structure

SMTP is configured and working properly as i can invite users via email.

In ldap i have defined email attribute for users. I guess there is only minor issue in configuration which i am missing to understand, you may advice please what i am missing

[TuringTux]

At first glance, that looks okay. We probably need to consult the logs now:

1. What do you see when you try to login in the Network pane of Chrome Dev Tools? There should be a POST request to /api/v1/auth. What is the HTTP response code and what is the response JSON?
2. What to the taiga-back logs say? In a build from source, you can probably access them using:

   journalctl -u taiga
   

   The log will probably contain an LDAP related error message, so if you could post that, that would be very helpful. If the logs are long, you might want to export them to a file and share them using e.g. GitHub Gist or a similar service (do note, however, that they might contain secrets).

• Network Pane of the Chrome Dev Tools
• Export journalctl logs to a file
• GitHub Gist

[Zohaib09]

Thank you @TuringTux

Below are the required logs related information

journalctl -u taiga # Please download from below link. In case of issue let me know please

https://www.swisstransfer.com/d/cc867699-ad52-4da8-aa1c-f90b38f5be21

@TuringTux

What is the HTTP response code and what is the response JSON?

I don’t understand this, if it is still required let me know bit more how can i drive it .

Thank you for your support and advices.

[TuringTux]

I think I just spotted the problem: You say your LDAP search base is:

LDAP_SEARCH_BASE = 'OU=people,mylab123,DC=com'

This is missing a DC= part before mylab123. Try replacing the line with:

LDAP_SEARCH_BASE = 'OU=people,DC=mylab123,DC=com'

I suppose it should work after that.

Note that nevertheless you should probably update the plugin to fix another bug, for more details, see the section below (I wrote that one before I noticed the small typo in the code).

Detailed analysis

Thanks for providing the logs. The HTTP response code and response JSON are no longer relevant, the back-end logs are sufficient.

Two exceptions seem to occur in your log, which I’ve listed below for future reference:

Error messages from the log

Sep 25 11:18:10 taiga2 gunicorn[4802]: ERROR:2022-09-25 11:18:06,876: Internal Server Error: /api/v1/auth
Sep 25 11:18:10 taiga2 gunicorn[4802]: Traceback (most recent call last):
Sep 25 11:18:10 taiga2 gunicorn[4802]:   File "/home/taiga/taiga-back/.venv/lib/python3.8/site-packages/taiga_contrib_ldap_auth_ext/services.py", line 58, in ldap_login_func
Sep 25 11:18:10 taiga2 gunicorn[4802]:     username, email, full_name = connector.login(
Sep 25 11:18:10 taiga2 gunicorn[4802]:   File "/home/taiga/taiga-back/.venv/lib/python3.8/site-packages/taiga_contrib_ldap_auth_ext/connector.py", line 125, in login
Sep 25 11:18:10 taiga2 gunicorn[4802]:     raise LDAPUserLoginError({"error_message": "LDAP login not found"})
Sep 25 11:18:10 taiga2 gunicorn[4802]: taiga_contrib_ldap_auth_ext.connector.LDAPUserLoginError: {'error_message': 'LDAP login not found'}

And:

Sep 25 11:18:10 taiga2 gunicorn[4802]: During handling of the above exception, another exception occurred:
Sep 25 11:18:10 taiga2 gunicorn[4802]: Traceback (most recent call last):
Sep 25 11:18:10 taiga2 gunicorn[4802]:   File "/home/taiga/taiga-back/.venv/lib/python3.8/site-packages/django/core/handlers/exception.py", line 34, in inner
Sep 25 11:18:10 taiga2 gunicorn[4802]:     response = get_response(request)
Sep 25 11:18:10 taiga2 gunicorn[4802]:   File "/home/taiga/taiga-back/.venv/lib/python3.8/site-packages/django/core/handlers/base.py", line 115, in _get_response
Sep 25 11:18:10 taiga2 gunicorn[4802]:     response = self.process_exception_by_middleware(e, request)
Sep 25 11:18:10 taiga2 gunicorn[4802]:   File "/home/taiga/taiga-back/.venv/lib/python3.8/site-packages/django/core/handlers/base.py", line 113, in _get_response
Sep 25 11:18:10 taiga2 gunicorn[4802]:     response = wrapped_callback(request, *callback_args, **callback_kwargs)
Sep 25 11:18:10 taiga2 gunicorn[4802]:   File "/home/taiga/taiga-back/taiga/base/api/viewsets.py", line 95, in view
Sep 25 11:18:10 taiga2 gunicorn[4802]:     return self.dispatch(request, *args, **kwargs)
Sep 25 11:18:10 taiga2 gunicorn[4802]:   File "/home/taiga/taiga-back/.venv/lib/python3.8/site-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
Sep 25 11:18:10 taiga2 gunicorn[4802]:     return view_func(*args, **kwargs)
Sep 25 11:18:10 taiga2 gunicorn[4802]:   File "/home/taiga/taiga-back/taiga/base/api/views.py", line 449, in dispatch
Sep 25 11:18:10 taiga2 gunicorn[4802]:     response = self.handle_exception(exc)
Sep 25 11:18:10 taiga2 gunicorn[4802]:   File "/home/taiga/taiga-back/taiga/base/api/views.py", line 447, in dispatch
Sep 25 11:18:10 taiga2 gunicorn[4802]:     response = handler(request, *args, **kwargs)
Sep 25 11:18:10 taiga2 gunicorn[4802]:   File "/home/taiga/taiga-back/taiga/auth/api.py", line 77, in create
Sep 25 11:18:10 taiga2 gunicorn[4802]:     data = auth_plugins[login_type]['login_func'](request)
Sep 25 11:18:10 taiga2 gunicorn[4802]:   File "/home/taiga/taiga-back/.venv/lib/python3.8/site-packages/taiga_contrib_ldap_auth_ext/services.py", line 67, in ldap_login_func
Sep 25 11:18:10 taiga2 gunicorn[4802]:     return get_auth_plugins()[FALLBACK]["login_func"](request)
Sep 25 11:18:10 taiga2 gunicorn[4802]: KeyError: 'normal'

The second problem seems to have been fixed just now in the Monogramm plugin, I’ve also incorporated the changes into my fork. Try updating the plugin. The following command should work:

pip install --upgrade git+https://github.com/TuringTux/taiga-contrib-ldap-auth-ext-2.git

I am not exactly certain if upgrading a plugin from Git works that way, so keep an eye on pip’s output: If it tells you something like “Already up to date” (or similar), updating probably didn’t work. In this case, you might need to pip uninstall the plugin first and then reinstall it.

• Merged Pull Request in the Monogramm plugin

I think, however, that this won’t solve your problems entirely. The LDAP error message is “LDAP login not found”. This is thrown if the LDAP search for the user didn’t yield any results…

…and that is probably the case because of the typo in LDAP_SEARCH_BASE, which I just noticed and mentioned above.

Hope that could help

[Zohaib09]

Hi Thank you

It seems like upgrade didn’t work so i have reinstalled plugin as below.

I have corrected it "LDAP_SEARCH_BASE = ‘OU=people,DC=mylab123,DC=com’ and restarted taiga as systemctl restart “taiga*”

It woked!!!

Thank you for your prompt help & support

[TuringTux]

From the screenshot, I think the update already worked without uninstalling, but it can of course never hurt to do so.

I’m happy to hear everything worked!

[Zohaib09]

Hi

Thank you @TuringTux , today i have deployed it in my production enviorment. works well. Now i have another question, Once ldap user logged, ldap user received welcome email. Now When i try to search that ldap user from my another (local) taiga account, i am not able to search ldap based user to assign him project etc. is there need any config change anymore ?

Thank you for your support

[TuringTux]

I’m afraid I probably can’t help you with this issue: I just checked it and in my instance, everything works fine.

As the welcome mail is correctly sent, it seems to me as the user should be correctly registered within the system – searching for them should therefore be possible.

Maybe one question: Do you search for the user by their email or by their uid? I did a quick check and it seems like the user is not found when you search for the email address.

[Zohaib09]

I am searching LDAP user with email, shud i search it with uid?

But its ok, you have already helped a lot. it seems minor issue. my boss can assign task to this ldap user, i don’t know how did he search it. user successfully received assigned task email.

Thanks a lot @TuringTux once again

[TuringTux]

Hi @Zohaib09,

I just checked in the network monitor and yes, it seems like searching a user by the email address is just generally not possible in Taiga. You can search by uid or givenName.

If you want to invite a user by email, you have to do this differently:

1. Enter the complete email address in the search field (you should get no results)
2. Press on the button that appears to the right of the search field (containing a silhouette of a person and a plus icon)
3. Select a role
4. Optionally, enter a message
5. Press “Invite”

If the user is already known to Taiga, then they will be immediately added to the list of members (you can see they get a status of “Active”, their name and their profile picture are shown). Otherwise, the status will be “Resend”, the profile picture will be in gray, no name will be shown and there will be a red “Pending” next to the mail address).

I therefore think your LDAP setup is working just as it should

You’re welcome, I’m glad I could help!

[Zohaib09]

Hi @TuringTux

Hope you are doing great. I am again here with a new Question

Can we configure Multiple Openldap (atleast two) for failover mechanism? in case if one openldap server is down then user can be authenticated from secondary openldap?

Thank you !

[TuringTux]

Hi @Zohaib09,

I am afraid this is not possible: The Monogramm plugin still has an open issue requesting exactly this feature: Multiple LDAP Server Array · Issue #16 · Monogramm/taiga-contrib-ldap-auth-ext · GitHub

As my fork currently only provides documentation changes, it is also not possible to do this in the TuringTux fork.

I am sorry to disappoint you on this issue The issue mentions using DNS to get something similar to a failover, but that is probably not an ideal solution either…

[Zohaib09]

Thank you @TuringTux . I got it, we can change ldap url to replica in config.py in such scenario.

Also, i have another question, can we migrate local user to ldap? Is there some procedure?

sorry for asking so many questions. Currently we have 10 to 15 local users on taiga, we want to move their credentials to LDAP.

[TuringTux]

I got it, we can change ldap url to replica in config.py in such scenario.

Note that you might need to restart Taiga after changing the URL, I am not sure if Taiga automatically loads the new configuration after change.

I do not know if there is a procedure to migrate a local user to LDAP, sorry. I would honestly doubt it, because something like this would probably have to be implemented in the plugin and would likely require further configuration (which I see no evidence of existing).