Taiga 6 : LDAP accounts are not created

Troubleshooting Self hosted Taiga
,
1

Hello,

I’m trying to update my instance from taiga 5 to taiga 6.
My taiga 5 server is connected to my openldap server and is working fine.
Users are authenticated on the ldap server and if they exist they are created at first login.

Before migrate the media and the database, I installed a new taiga 6 server from sources, and installed the Monogram plugin using this documentation :

I see on the ldap side that the server search for the user and bind with it.

But the server don’t create the user even if the authentification is successful on the ldap side. It keeps saying that the password/user is incorrect.

Log from the ldap side (succesful search and bind ):

un 10 11:14:35 indiana slapd[1758]: conn=572020 fd=25 ACCEPT from IP=193.49.132.200:34687 (IP=0.0.0.0:389)
Jun 10 11:14:35 indiana slapd[1758]: conn=572020 op=0 BIND dn="" method=128
Jun 10 11:14:35 indiana slapd[1758]: conn=572020 op=0 RESULT tag=97 err=0 text=
Jun 10 11:14:35 indiana slapd[1758]: conn=572020 op=1 SRCH base="ou=Users,dc=mri.cnrs,dc=fr" scope=2 deref=3 filter="(|(uid=miquel)(mail=miquel))"
Jun 10 11:14:35 indiana slapd[1758]: conn=572020 op=1 SRCH attr=uid mail givenName
Jun 10 11:14:35 indiana slapd[1758]: conn=572020 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 10 11:14:35 indiana slapd[1758]: conn=572021 fd=27 ACCEPT from IP=193.49.132.200:37315 (IP=0.0.0.0:389)
Jun 10 11:14:35 indiana slapd[1758]: conn=572021 op=0 BIND dn="uid=miquel,ou=Users,dc=mri.cnrs,dc=fr" method=128
Jun 10 11:14:35 indiana slapd[1758]: conn=572021 op=0 BIND dn="uid=miquel,ou=Users,dc=mri.cnrs,dc=fr" mech=SIMPLE ssf=0
Jun 10 11:14:35 indiana slapd[1758]: conn=572021 op=0 RESULT tag=97 err=0 text=

My LDAP Plugin configuration :

INSTALLED_APPS += ["taiga_contrib_ldap_auth_ext"]
LDAP_SERVER = "ldap://someserverurl.domain.fr"
LDAP_PORT = 389
LDAP_BIND_DN = ''
LDAP_BIND_PASSWORD = ''
LDAP_SEARCH_BASE = 'OU=Users,DC=mri.cnrs,DC=fr'
LDAP_USERNAME_ATTRIBUTE = "uid"
LDAP_EMAIL_ATTRIBUTE = "mail"
LDAP_FULL_NAME_ATTRIBUTE = "givenName"
LDAP_SAVE_LOGIN_PASSWORD = False
LDAP_MAP_USERNAME_TO_UID = None
LDAP_FALLBACK = "normal"

Where could i look to fix that?

Thanks.

2

Just to ensure it is not a frontend problem: Could you try manually logging in to the API, e.g. using the following Python script? (needs the requests package installed)

import requests
from getpass import getpass

TAIGA_BASE="https://yourtaigaurl.example"

r = requests.post(
    f"{TAIGA_BASE}/api/v1/auth",
    json={
        "type": "ldap",
        "username": input("Username: "),
        "password": getpass(),
    },
)

print(r.status_code)
3

Hello,

Thanks you for the answer.

Here are the results with the correct password :

miquel@imoteph:~/tmp$ python3 taiga_auth.py 
Username: miquel
Password: 
500

with an incorrect password :

miquel@imoteph:~/tmp$ python3 taiga_auth.py 
Username: miquel
Password: 
401

Hope this helps…

4

Hello,

With your script i see that there is an error 500 ( Internal server error ).
I struggled to get the exact error but no error seems to be forwarded from gunicorn to nginx.

Finally we stopped the taiga services, launch the server via this command :

DJANGO_SETTINGS_MODULE=settings.config python manage.py runserver

Made the request to the authentication API using your script and get details about the error :

ValueError: EMAIL_USE_TLS/EMAIL_USE_SSL are mutually exclusive, so only set one of those settings to True.

=> In the default email configuration those two parameters are enabled.

Because it could’nt send an email the server crashes.

So we configured the mail settings in settings/config.py and now the account are correctly created.

Thanks for the help.

5

Hi @Oliviermi,

glad to hear you found the solution to your problem (and sorry I didn’t reply earlier, I must have missed the notification).

For anyone visiting this in the future: LDAP was a red herring here, the problem was that Taiga could not send invite emails, because only one of the config parameters EMAIL_USE_TLS and EMAIL_USE_SSL is allowed to be set. This caused the server to crash on successful login.

1 Like