Integrate an LDAP account database with Taiga

Hi there!

Taiga does not hot-reload configuration changes. It is indeed needed to restart after a change in the config files.

Regarding migrating users to LDAP I don’t think Monogramm’s plugin can do that, but if I remember correctly, if the user/email/whichever field you specify in the config matches an existing user on Taiga, I believe it does overwrite it (speaking from memory though, I just checked the plugin but couldn’t find a thing).

Hi

Thank you so much.

Today I have tested taiga for migration local user to LDAP credentials with this plugin. It worked. Simply made ID with same email attribute in LDAP as taiga have. Then logged in with LDAP password and all perfect.

Now if ldap downs credentials no longer work. To handle such scenario we have deployed Ldap replica.

Now i am lookinto situation if we want migrate ldap users back to local credentials. How it be done? I wondering to do it by removing ldap configuration from config.py and its plugin. Then click on forget password, will it work? Will test…

1 Like

Hi again!

Glad it worked!

The last scenario you mention should probably work, but please do report back with your findings.

Another option would be, after removing the LDAP integration, to use either Taiga’s API or the admin page to manually reset the passwords to some temporary value and then ask the users to change it.

I’m not sure 100% sure, though, but since you mention that credentials no longer work when LDAP is down, maybe the old passwords are still on the database? You could try setting a password for yourself, use the LDAP integration, check it works, then remove the integration and try to login with your old password?

Hope this helps!

Regards!

Unfortunately, my theory does not work. after removing integration and clicking of forget my password, old ldap user (Which is now consider to be local user) received email, and he reset the password. But he no longer able to login.

Once LDAP down, or ldap integration removed old password does not work.

How to use this? Can you advice?

Hi @TuringTux

I have deployed this plugin to my another taiga instance, I am unable to authenticate with LDAP credentials but strange is that taiga logs (journalctl -u taiga) does not show any relevant LDAP logs

Config.py

INSTALLED_APPS += [“taiga_contrib_ldap_auth_ext”]
LDAP_SERVER = “ldap://sso.mydomain.tech”
LDAP_PORT = 389
LDAP_BIND_DN = “CN=admin,DC=mydomain,DC=com”
LDAP_BIND_PASSWORD = “mypassword”
LDAP_SEARCH_BASE = ‘OU=people,DC=dcorp,DC=tech’
LDAP_USERNAME_ATTRIBUTE = “uid”
LDAP_EMAIL_ATTRIBUTE = “mail”
LDAP_FULL_NAME_ATTRIBUTE = “cn”
LDAP_SAVE_LOGIN_PASSWORD = False
LDAP_MAP_USERNAME_TO_UID = None

Chrome Dev Tools:

POST https://taigadomain/api/v1/auth 401 (Unauthorized)

That is strange, few months ago we used same procedure it worked well, now having issue. can you please help ?

This Taiga VPS is behind the ngnix reverse proxy (NGINX reverse proxy is on anther VPS).

I direct it without VPS, then LDAP Credentials work. There is something need to add in configuration of nginx reverse proxy.

Following is reverse proxy configuration of NGINX

image

Above configuration works well for local credentials.

Any advice please

Hm, I don’t really see how the reverse proxy put in front of Taiga should matter, because to my understanding Taiga will talk to LDAP only in the back.

Can the VPS you’re hosting Taiga on talk to sso.mydomain.tech (using ping or maybe even ldapsearch or something like this?)

1 Like

Thank you,

Yes i can ping from taiga to LDAP VPS. I checked by removing reverse proxy and accessed taiga directly then LDAP credentials works with taiga. It is to something to do at reverse proxy side.

I have removed proxy server, now sometimes i get logged in with ldap credentials and sometime it says “something went wrong”"

I could collect followings

Jan 06 12:10:25 taigaserver gunicorn[2111269]: ERROR:2023-01-06 12:10:25,047: Internal Server Error: /api/v1/auth
Jan 06 12:10:25 taigaserver gunicorn[2111269]: Traceback (most recent call last):
Jan 06 12:10:25 taigaserver gunicorn[2111269]: File “/home/taiga/taiga-back/.venv/lib/python3.8/site-packages/taiga_contrib_ldap_auth_ext/connector.py”, line 135, in>
Jan 06 12:10:25 taigaserver gunicorn[2111269]: user_conn = Connection(server, auto_bind = auto_bind, client_strategy = SYNC,
Jan 06 12:10:25 taigaserver gunicorn[2111269]: File “/home/taiga/taiga-back/.venv/lib/python3.8/site-packages/ldap3/core/connection.py”, line 363, in init
Jan 06 12:10:25 taigaserver gunicorn[2111269]: self._do_auto_bind()
Jan 06 12:10:25 taigaserver gunicorn[2111269]: File “/home/taiga/taiga-back/.venv/lib/python3.8/site-packages/ldap3/core/connection.py”, line 412, in _do_auto_bind
Jan 06 12:10:25 taigaserver gunicorn[2111269]: raise LDAPBindError(error)
Jan 06 12:10:25 taigaserver gunicorn[2111269]: ldap3.core.exceptions.LDAPBindError: automatic bind not successful - invalidCredentials
Jan 06 12:10:25 taigaserver gunicorn[2111269]: During handling of the above exception, another exception occurred:
Jan 06 12:10:25 taigaserver gunicorn[2111269]: Traceback (most recent call last):
Jan 06 12:10:25 taigaserver gunicorn[2111269]: File “/home/taiga/taiga-back/.venv/lib/python3.8/site-packages/taiga_contrib_ldap_auth_ext/services.py”, line 58, in l>
Jan 06 12:10:25 taigaserver gunicorn[2111269]: username, email, full_name = connector.login(login = login_input, password = password_input)
Jan 06 12:10:25 taigaserver gunicorn[2111269]: File “/home/taiga/taiga-back/.venv/lib/python3.8/site-packages/taiga_contrib_ldap_auth_ext/connector.py”, line 140, in>
Jan 06 12:10:25 taigaserver gunicorn[2111269]: raise LDAPUserLoginError({“error_message”: error})
Jan 06 12:10:25 taigaserver gunicorn[2111269]: taiga_contrib_ldap_auth_ext.connector.LDAPUserLoginError: {‘error_message’: 'LDAP bind failed: automatic bind not succes>
Jan 06 12:10:25 taigaserver gunicorn[2111269]: During handling of the above exception, another exception occurred:
Jan 06 12:10:25 taigaserver gunicorn[2111269]: Traceback (most recent call last):
Jan 06 12:10:25 taigaserver gunicorn[2111269]: File “/home/taiga/taiga-back/.venv/lib/python3.8/site-packages/django/core/handlers/exception.py”, line 34, in inner
Jan 06 12:10:25 taigaserver gunicorn[2111269]: response = get_response(request)
Jan 06 12:10:25 taigaserver gunicorn[2111269]: File “/home/taiga/taiga-back/.venv/lib/python3.8/site-packages/django/core/handlers/base.py”, line 115, in _get_respon>
Jan 06 12:10:25 taigaserver gunicorn[2111269]: response = self.process_exception_by_middleware(e, request)
Jan 06 12:10:25 taigaserver gunicorn[2111269]: File “/home/taiga/taiga-back/.venv/lib/python3.8/site-packages/django/core/handlers/base.py”, line 113, in _get_respon>
Jan 06 12:10:25 taigaserver gunicorn[2111269]: response = wrapped_callback(request, *callback_args, **callback_kwargs)
Jan 06 12:10:25 taigaserver gunicorn[2111269]: File “/home/taiga/taiga-back/taiga/base/api/viewsets.py”, line 95, in view
Jan 06 12:10:25 taigaserver gunicorn[2111269]: return self.dispatch(request, *args, **kwargs)
Property: Invalid value for “CSS Level 2.1” property: 0.8rem 3rem [171:17: padding] File "/home/taiga/taiga-back/.venv/lib/python3.8/site-packages/taiga_contrib_ldap>
Jan 06 12:10:25 taigaserver gunicorn[2111269]: return get_auth_plugins()[FALLBACK]“login_func”
Jan 06 12:10:25 taigaserver gunicorn[2111269]: KeyError: ‘normal’
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [6:51: -webkit-text-size-adjust]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [6:82: -ms-text-size-adjust]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [7:23: mso-table-lspace]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [7:45: mso-table-rspace]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [8:17: -ms-interpolation-mode]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: ERROR Property: Invalid value for “CSS Level 2.1” property: 0.8rem 3rem [171:17: padding]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: ERROR Property: Invalid value for “CSS Level 2.1” property: 0.5rem [227:5: margin-left]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [247:55: -webkit-text-size-adjust]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name.
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [1:1: -webkit-text-size-adjust]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [1:31: -ms-text-size-adjust]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [1:1: -webkit-text-size-adjust]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [1:31: -ms-text-size-adjust]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [1:1: -webkit-text-size-adjust]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [1:31: -ms-text-size-adjust]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [1:1: -webkit-text-size-adjust]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [1:31: -ms-text-size-adjust]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [1:1: -webkit-text-size-adjust]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [1:31: -ms-text-size-adjust]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [1:1: mso-table-lspace]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [1:20: mso-table-rspace]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [1:1: mso-table-lspace]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [1:20: mso-table-rspace]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [1:1: -ms-interpolation-mode]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: ERROR Property: Invalid value for “CSS Level 2.1” property: 0.5rem [1:22: margin-left]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [1:1: -ms-interpolation-mode]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [1:1: -ms-interpolation-mode]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [1:1: -ms-interpolation-mode]
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [1:1: -ms-interpolation-mode]
Jan 06 18:05:40 taigaserver gunicorn[2111262]: [2023-01-06 18:05:40 +0000] [2111262] [INFO] Handling signal: term
Jan 06 12:10:25 taigaserver gunicorn[2111269]: data = auth_plugins[login_type]‘login_func’
Jan 06 12:10:25 taigaserver gunicorn[2111269]: File “/home/taiga/taiga-back/.venv/lib/python3.8/site-packages/taiga_contrib_ldap_auth_ext/services.py”, line 66, in l>
Jan 06 12:10:25 taigaserver gunicorn[2111269]: return get_auth_plugins()[FALLBACK]“login_func”
Jan 06 12:10:25 taigaserver gunicorn[2111269]: KeyError: ‘normal’
Jan 06 12:19:26 taigaserver gunicorn[2111268]: WARNING Property: Unknown Property name. [6:51: -webkit-text-size-adjust]
Jan 06 12:10:25 taigaserver gunicorn[2111269]: data = auth_plugins[login_type]‘login_func’

Please advice

If it sometimes works and sometimes doesn’t, and you always enter the same password, it seems like a problem with the LDAP server, to be honest: Sometimes, it just doesn’t accept the credentials. Maybe a network error, or a hardware problem, or something like that?

I am sorry I can’t give any more help, but I am also struggling to pinpoint this problem to a specific cause.

@TuringTux
I have read and followed the entire thread and we are getting a http 401 from POST auth and no ldap related messages in journalctl -u taiga. We are also using nginx on the same VM as reverse proxy for https. Any hints would be greatly appreciated. I can provide logs / config if required.

Thanks

Hi @Implosive1587,

I am not certain how much I will be able to help, but I can definitely try. Could you provide your configuration and an excerpt of your logs, please?

Regards
TuringTux

1 Like

Hi @TuringTux,

thanks, much appreciated. Here is the config:

config.py
## LDAP
#########################################
INSTALLED_APPS += ["taiga_contrib_ldap_auth_ext"]

# TODO https://github.com/Monogramm/taiga-contrib-ldap-auth-ext/issues/16
LDAP_SERVER = 'ldaps://s4dc.int.lab-dev.loc'
LDAP_PORT = 636

# Flag to enable LDAP with STARTTLS before bind
LDAP_START_TLS = False

# Support of alternative LDAP ciphersuites
#from ldap3 import Tls
#import ssl

#LDAP_TLS_CERTS = Tls(validate=ssl.CERT_NONE, version=ssl.PROTOCOL_TLSv1, ciphers='RSA+3DES')

# Full DN of the service account use to connect to LDAP server and search for login user's account entry
# If LDAP_BIND_DN is not specified, or is blank, then an anonymous bind is attempated
LDAP_BIND_DN = 'CN=ldap taigadevman,OU=TechUser,OU=vUser,DC=int,DC=lab-dev,DC=loc'
LDAP_BIND_PASSWORD = '***'

# Starting point within LDAP structure to search for login user
LDAP_SEARCH_BASE = 'DC=int,DC=lab-dev,DC=loc'

# Additional search criteria to the filter (will be ANDed)
LDAP_SEARCH_FILTER_ADDITIONAL = '(&(objectCategory=Person)(sAMAccountName=*)(|(memberOf=CN=G_TAIGA_ADMIN,OU=GitLab,OU=vGroups,DC=int,DC=lab-dev,DC=loc)(memberOf=CN=G_TAIGA_USER_ALL,OU=GitLab,OU=vGroups,DC=int,DC=lab-dev,DC=loc)))'

# Names of attributes to get username, e-mail and full name values from
# These fields need to have a value in LDAP 
LDAP_USERNAME_ATTRIBUTE = 'sAMAccountName'
LDAP_EMAIL_ATTRIBUTE = 'mail'
LDAP_FULL_NAME_ATTRIBUTE = 'displayName'

# Option to not store the passwords in the local db
LDAP_SAVE_LOGIN_PASSWORD = False

# TODO https://github.com/Monogramm/taiga-contrib-ldap-auth-ext/issues/15
# Group search filter where $1 is the project slug and $2 is the role slug
#LDAP_GROUP_SEARCH_FILTER = 'CN=$2,OU=$1,OU=Groups,DC=example,DC=net'

# TODO https://github.com/Monogramm/taiga-contrib-ldap-auth-ext/issues/15
# Use an attribute in the user entry for membership
#LDAP_USER_MEMBER_ATTRIBUTE = 'memberof,primaryGroupID'

# TODO https://github.com/Monogramm/taiga-contrib-ldap-auth-ext/issues/15
# Starting point within LDAP structure to search for login group
LDAP_GROUP_SEARCH_BASE = 'OU=vGroups,DC=int,DC=lab-dev,DC=loc'
# Group classes filter
#LDAP_GROUP_FILTER = '(|(objectclass=group)(objectclass=groupofnames)(objectclass=groupofuniquenames))'
# Group member attribute
#LDAP_GROUP_MEMBER_ATTRIBUTE = 'memberof,primaryGroupID'

# TODO https://github.com/Monogramm/taiga-contrib-ldap-auth-ext/issues/17
# Taiga super users group id
LDAP_GROUP_ADMIN = 'CN=G_GITLAB_ADMIN,OU=GitLab,OU=vGroups,DC=int,DC=lab-dev,DC=loc'

# Fallback on normal authentication method if LDAP auth fails. Uncomment to disable and only allow LDAP login.
#LDAP_FALLBACK = ""

# Function to map LDAP username to local DB user unique identifier.
# Upon successful LDAP bind, will override returned username attribute
# value. May result in unexpected failures if changed after the database
# has been populated.
# 
def _ldap_slugify(uid: str) -> str:
    # example: force lower-case
    #uid = uid.lower()
    return uid
    
# To enable the function above, uncomment the line below to store the function in the variable
LDAP_MAP_USERNAME_TO_UID = None

# Similarly, you can apply filters to the email and name by defining functions and specifying them here in the same way
#LDAP_MAP_EMAIL = _ldap_map_email```
conf.json
    "api": "https://taiga-dev.int.lab-dev.loc/api/v1/",
    "eventsUrl": "wss://taiga-dev.int.lab-dev.loc/events",
    "baseHref": "/",
    "loginFormType": "ldap",
    "eventsMaxMissedHeartbeats": 5,
    "eventsHeartbeatIntervalTime": 60000,
    "eventsReconnectTryInterval": 10000,
    "debug": true,
    "debugInfo": true,
    "defaultLanguage": "en",
    "themes": [
        "taiga"
    ],
    "defaultTheme": "taiga",
    "defaultLoginEnabled": true,
    "publicRegisterEnabled": true,
    "feedbackEnabled": true,
    "supportUrl": "https://community.taiga.io/",
    "privacyPolicyUrl": null,
    "termsOfServiceUrl": null,
    "maxUploadFileSize": null,
    "contribPlugins": [],
    "tagManager": {
        "accountId": null
    },
    "tribeHost": null,
    "enableAsanaImporter": false,
    "enableGithubImporter": false,
    "enableJiraImporter": false,
    "enableTrelloImporter": false,
    "gravatar": false,
    "rtlLanguages": [
        "ar",
        "fa",
        "he"
    ]
}```

I cannot provide any logs, because I am still unable to generate any ldap related messages… I have already set DEBUG = True in taiga-back config.py, but this did not change anything. What do I need to change and where should I look for a log?

Thanks

At first look, your configuration looks fine. I sadly also don’t know how to get more logs.

Have you tried installing ldap-utils (assuming you run Debian, on other distributions, the package might be named differently) and using ldapsearch to perform the LDAP connection manually. The command should probably look something like this:

ldapsearch -H ldaps://s4dc.int.lab-dev.loc -x -D 'CN=ldap taigadevman,OU=TechUser,OU=vUser,DC=int,DC=lab-dev,DC=loc' -W -b 'DC=int,DC=lab-dev,DC=loc'

If that works, try also applying the filter:

ldapsearch -H ldaps://s4dc.int.lab-dev.loc -x -D 'CN=ldap taigadevman,OU=TechUser,OU=vUser,DC=int,DC=lab-dev,DC=loc' -W -b 'DC=int,DC=lab-dev,DC=loc' '(&(objectCategory=Person)(sAMAccountName=*)(|(memberOf=CN=G_TAIGA_ADMIN,OU=GitLab,OU=vGroups,DC=int,DC=lab-dev,DC=loc)(memberOf=CN=G_TAIGA_USER_ALL,OU=GitLab,OU=vGroups,DC=int,DC=lab-dev,DC=loc)))'

My apologies for the pretty generic debugging attempt, but if both these commands return some users, we can at least eliminate connection issues (e.g. an overzealous firewall), and other LDAP server configuration problems.

Sure, both commands return results.

ldapsearch -H ldaps://s4dc.int.lab-dev.loc -x -D 'CN=ldap taigadevman,OU=TechUser,OU=vUser,DC=int,DC=lab-dev,DC=loc' -W -b 'DC=int,DC=lab-dev,DC=loc'

returns a long list, so just start and end:

# extended LDIF
#
# LDAPv3
# base <DC=int,DC=lab-dev,DC=loc> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# ldap taigadevman, TechUser, vUser, int.lab-dev.loc
dn: CN=ldap taigadevman,OU=TechUser,OU=vUser,DC=int,DC=lab-dev,DC=loc
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: ldap taigadevman
sn: taigadevman
givenName: ldap
instanceType: 4
whenCreated: 20230413154302.0Z
displayName: ldap taigadevman
uSNCreated: 1536791
name: ldap taigadevman
objectGUID:: uRD5m8oP+Ey1Imyd+6WOIg==
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAA44nDdvVkonJSeYvORwgAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: ldaptaigadevman
sAMAccountType: 805306368
userPrincipalName: ldaptaigadevman@int.lab-dev.loc
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=int,DC=lab-dev,DC=loc
userAccountControl: 66048
pwdLastSet: 133258742445332160
lockoutTime: 0
lastLogonTimestamp: 133258986491385590
whenChanged: 20230413223049.0Z
uSNChanged: 1541144
distinguishedName: CN=ldap taigadevman,OU=TechUser,OU=vUser,DC=int,DC=lab-dev
 ,DC=loc

...

# search reference
ref: ldaps://int.lab-dev.loc/CN=Configuration,DC=int,DC=lab-dev,DC=loc

# search reference
ref: ldaps://int.lab-dev.loc/DC=DomainDnsZones,DC=int,DC=lab-dev,DC=loc

# search reference
ref: ldaps://int.lab-dev.loc/DC=ForestDnsZones,DC=int,DC=lab-dev,DC=loc

# search result
search: 2
result: 0 Success

# numResponses: 526
# numEntries: 522
# numReferences: 3

and

ldapsearch -H ldaps://s4dc.int.lab-dev.loc -x -D 'CN=ldap taigadevman,OU=TechUser,OU=vUser,DC=int,DC=lab-dev,DC=loc' -W -b 'DC=int,DC=lab-dev,DC=loc' '(&(objectCategory=Person)(sAMAccountName=*)(|(memberOf=CN=G_TAIGA_ADMIN,OU=GitLab,OU=vGroups,DC=int,DC=lab-dev,DC=loc)(memberOf=CN=G_TAIGA_USER_ALL,OU=GitLab,OU=vGroups,DC=int,DC=lab-dev,DC=loc)))'

returns

# extended LDIF
#
# LDAPv3
# base <DC=int,DC=lab-dev,DC=loc> with scope subtree
# filter: (&(objectCategory=Person)(sAMAccountName=*)(|(memberOf=CN=G_TAIGA_ADMIN,OU=GitLab,OU=vGroups,DC=int,DC=lab-dev,DC=loc)(memberOf=CN=G_TAIGA_USER_ALL,OU=GitLab,OU=vGroups,DC=int,DC=lab-dev,DC=loc)))
# requesting: ALL
#

# search reference
ref: ldaps://int.lab-dev.loc/CN=Configuration,DC=int,DC=lab-dev,DC=loc

# search reference
ref: ldaps://int.lab-dev.loc/DC=DomainDnsZones,DC=int,DC=lab-dev,DC=loc

# search reference
ref: ldaps://int.lab-dev.loc/DC=ForestDnsZones,DC=int,DC=lab-dev,DC=loc

# search result
search: 2
result: 0 Success

# numResponses: 4
# numReferences: 3

If I interpret the second response correctly, your filter is not returning any accounts. This might be the reason why Taiga does not accept any login.

Have you tried adjusting the filter? I have no experience with Active Directory (I believe this is what you’re using, correct?), but is (objectCategory=Person) a valid filter or does it have to be (objectCategory=CN=Person,CN=Schema,CN=Configuration,DC=int,DC=lab-dev,DC=loc)?

It’s a samba server acting as a Active Directory controller. We use it successfully with other applications as well, the filters have been derived from these other applications.

Both groups were emtpy and I had an error in the search string. I fixed both, the search returns users now, but it still does not allow a login to Taiga and unfortunately still no logs.

# extended LDIF
#
# LDAPv3
# base <DC=int,DC=lab-dev,DC=loc> with scope subtree
# filter: (&(objectCategory=Person)(sAMAccountName=*)(|(memberOf=CN=G_TAIGA_ADMIN,OU=Taiga,OU=vGroups,DC=int,DC=lab-dev,DC=loc)(memberOf=CN=G_TAIGA_USER_ALL,OU=Taiga,OU=vGroups,DC=int,DC=lab-dev,DC=loc)))
# requesting: ALL
#

# Test Admin User, AktiveIntern, vUser, int.lab-dev.loc
dn: CN=Test Admin User,OU=AktiveIntern,OU=vUser,DC=int,DC=lab-dev,DC=loc
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Test Admin User
sn: Admin
givenName: Test
instanceType: 4
whenCreated: 20160501183837.0Z
displayName: Test Admin User
uSNCreated: 4081
name: Test Admin User
objectGUID:: zxa7t59fBkCpPhitvku4Fw==
codePage: 0
countryCode: 0
lastLogoff: 0
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAA44nDdvVkonJSeYvOVgQAAA==
accountExpires: 9223372036854775807
sAMAccountName: test-admin
sAMAccountType: 805306368
userPrincipalName: test-admin@int.lab-dev.loc
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=int,DC=lab-dev,DC=loc
pwdLastSet: 131066015190000000
userAccountControl: 66048
initials: TA
mail: test.admin@lab-dev.loc
memberOf: CN=Domain Admins,CN=Users,DC=int,DC=lab-dev,DC=loc
memberOf: CN=Enterprise Admins,CN=Users,DC=int,DC=lab-dev,DC=loc
memberOf: CN=Group Policy Creator Owners,CN=Users,DC=int,DC=lab-dev,DC=loc
memberOf: CN=Schema Admins,CN=Users,DC=int,DC=lab-dev,DC=loc
memberOf: CN=G_TAIGA_ADMIN,OU=Taiga,OU=vGroups,DC=int,DC=lab-dev,DC=loc
memberOf: CN=G_TAIGA_USER_ALL,OU=Taiga,OU=vGroups,DC=int,DC=lab-dev,DC=loc
memberOf:: Q049R2VzY2jDpGZ0c2bDvGhydW5nLE9VPXZHcm91cHMsREM9aW50LERDPXZlcnR1cml

...

lastLogon: 133256281119488500
logonCount: 11981
lastLogonTimestamp: 133256281119488500
whenChanged: 20230410192151.0Z
uSNChanged: 1526948
distinguishedName:: Q049UmFtcGVyIEvDvG5zY2hlcixPVT1Ba3RpdmVJbnRlcm4sT1U9dlVzZX
 IsREM9aW50LERDPXZlcnR1cmlzLERDPWRl

# search reference
ref: ldaps://int.lab-dev.loc/CN=Configuration,DC=int,DC=lab-dev,DC=loc

# search reference
ref: ldaps://int.lab-dev.loc/DC=DomainDnsZones,DC=int,DC=lab-dev,DC=loc

# search reference
ref: ldaps://int.lab-dev.loc/DC=ForestDnsZones,DC=int,DC=lab-dev,DC=loc

# search result
search: 2
result: 0 Success

# numResponses: 7
# numEntries: 3
# numReferences: 3

I just checked my logs and it seems there simply aren’t any entries related to LDAP. Probably one should patch the original plugin and add some logging statements (you could also do so yourself for testing by forking it, adding log statements and then installing your fork from Git).

Just to make sure: Have you restarted the Taiga application completely after making the changes to the filter? Only yesterday I also had an issue with LDAP login on an otherwise working instance, which was fixed by just restarting Taiga (in my case, the Docker containers).

Yes, I rebooted the sytem before each test.

Next I have to figure out, how to add logging.

Hi

How are you all team?

Our LDAP integration is working great since last 6 months.

I have question, we have a web link to reset LDAP password. In taiga login page there is option to click on “Forgot”. Can i set my web link to this forgot option? If no is there option to hide this forgot option?