Integrate an LDAP account database with Taiga

Contribution
1

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

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

  1. :computer: ensky/taiga-contrib-ldap-auth
  2. :computer: Monogramm/taiga-contrib-ldap-auth-ext
  3. :computer: TuringTux/taiga-contrib-ldap-auth-ext-2

The Monogramm plugin is a fork of the ensky plugin, the TuringTux plugin is a fork of the Monogramm plugin.

The go-to plugin for LDAP authentication is the Monogramm plugin, it is for example mentioned in the community contributions post in this forum. I created the TuringTux plugin when it was not clear if the Monogramm plugin was still maintained, however, there has been recent activity so as of now the only difference of the TuringTux plugin is an updated README.

Note however that currently, the version of the plugin deployed to the Python Package Index (PyPI) is not up to date. If you want to use an up-to-date version of the Monogramm plugin, install it directly from Git or use the TuringTux plugin, which currently can only be installed directly from Git anway.

For the rest of the post, I will work with the TuringTux plugin, but indicate which places you need to change to use the Monogramm plugin.

Further resources

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 TuringTux pluginā€™s README, please refer to this document:

:link: Plugin installation and configuration of taiga-back

Use the Monogramm plugin directly from Git instead

If you want to use the Monogramm plugin instead of the TuringTux plugin, 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 git+https://github.com/TuringTux/taiga-contrib-ldap-auth-ext-2.git

    with:

    RUN pip install git+https://github.com/Monogramm/taiga-contrib-ldap-auth-ext.git
Use the Monogramm plugin from PyPI instead

You can also install the Monogramm plugin from the Python Package Index. Note that currently, this will get you an outdated version with a potential LDAP injection vulnerability, so Iā€™d recommend using the plugin directly from Git until this is updated.

Follow the guide mentioned above, but make the following changes to the Dockerfile:

  • Remove all the RUN apt-get ... instructions (they were only to install Git, which is only needed if you want to install e.g. the TuringTux plugin directly from Git instead of the normal Python Package Index)

  • Replace the following line:

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

    with:

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

Step 3: Configure taiga-front

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

:link: Configuration of taiga-front

(Even) further reading

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

1 Like
2

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 :slight_smile:

3

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!

1 Like
4

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

5

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.

6

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

7

Hi

I have installed plugin as per your instruction as below

image
image690Ɨ598 21.6 KB

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

image
image501Ɨ639 11.4 KB

systemctl restart ā€œtaiga*ā€

Sitill i am not able to login with ldap user.

Following is my ldap structure

image
image1334Ɨ502 29.6 KB

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

8

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).
9

Thank you @TuringTux

Below are the required logs related information

image
image1358Ɨ467 24.3 KB

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

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.

10

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.

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 :slight_smile:

11

Hi Thank you

It seems like upgrade didnā€™t work so i have reinstalled plugin as below.

image
image1346Ɨ679 70.8 KB

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

12

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!

1 Like
13

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

14

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.

1 Like
15

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

16

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 :slight_smile:

Youā€™re welcome, Iā€™m glad I could help!

17

Hi @TuringTux

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

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 !

:smiley:

18

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 :frowning: The issue mentions using DNS to get something similar to a failover, but that is probably not an ideal solution eitherā€¦

1 Like
19

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.

20

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).