Coder Social home page Coder Social logo

ctldap's People

Contributors

a-schild avatar dependabot[bot] avatar hubermat avatar milux avatar sscholl avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

ctldap's Issues

Doemon is always listening on 0.0.0.0

The ldap daemon is always listening on public internet 0.0.0.0, so the ldap server is open to all network requests.

By default it should only listen on 127.0.0.1, so the admin has to enable "public" access if required. (Secure defaults)

See patch for this in fork a-schild

Hosting

Wir verwenden das von ChurchTools administrierte Produkt. Gibt es eine Möglichkeit, deinen LDAP Wrapper damit zu verwenden oder sind wir gezwungen, wieder auf die self-hosted Variante umzusteigen?

Recursive Groups

First of all: thank you for the great and very useful tool.

Testing with JXplorer suggests that groups are listed recursively:
selection_404

As of now there is no urgent requirement to get this issue resolved.
Thank you for looking into it.

Cheers
Ulrich

Churchtools 3.100 sends a HTTP Response code 403 after Update

I used this Wrapper over Dockerhub successfully for the past 6 months. With the 3.1 Update I first got the now fixed 500 Error but I am still stuck with an 403 Response. I obviously didn't change any permissions and double checked the API Access Token.

I use the Wrapper for authenticating Windows machines via Pgina and Remote Access via Authelia. Pgina is surprisingly able to authenticate users but can't authorize via groups anymore, Authelia can't authenticate users.
I'm not Self-Hosting ChurchTools. Is this an open Problem with SaaS Churchtools or does anyone else has this problem with the wrapper?

Error Log for the Group Authorization:
2023-08-03T11:31:35.548Z [DEBUG] churchtools - SEARCH base object: cn=test, ou=groups, o=churchtools scope: base
2023-08-03T11:31:35.548Z [DEBUG] churchtools - Filter: (uniquemember=cn=ttest,ou=users,o=churchtools)
2023-08-03T11:31:35.548Z [DEBUG] churchtools - Search for groups
2023-08-03T11:31:35.549Z [DEBUG] churchtools - Wait on Promise for cache key "rawData".
2023-08-03T11:31:35.549Z [DEBUG] churchtools - Wait on Promise for cache key "groups".
2023-08-03T11:31:35.558Z [DEBUG] churchtools - Assumed 1 page(s) of data for /api/groups, but had to load 0.
2023-08-03T11:31:35.558Z [DEBUG] churchtools - fetchGroups done
2023-08-03T11:31:35.561Z [DEBUG] churchtools - fetchGroupTypes done
2023-08-03T11:31:35.594Z [DEBUG] churchtools - Assumed 1 page(s) of data for /api/persons, which was correct.
2023-08-03T11:31:35.594Z [DEBUG] churchtools - fetchPersons done
2023-08-03T11:31:35.769Z [ERROR] churchtools - Error while retrieving groups:
HTTPError: Response code 403 ()
at Request. (file:///app/node_modules/got/dist/source/as-promise/index.js:86:42)
at Object.onceWrapper (node:events:629:26)
at Request.emit (node:events:526:35)
at Request._onResponseBase (file:///app/node_modules/got/dist/source/core/index.js:726:22)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async Request._onResponse (file:///app/node_modules/got/dist/source/core/index.js:768:13)

Error Log for the User Authentication:
2023-08-03T11:41:33.712Z [DEBUG] churchtools - Admin bind DN: cn=root, ou=users, o=churchtools
2023-08-03T11:41:33.712Z [DEBUG] churchtools - Admin bind successful
2023-08-03T11:41:33.714Z [DEBUG] churchtools - SEARCH base object: ou=users, o=churchtools scope: sub
2023-08-03T11:41:33.714Z [DEBUG] churchtools - Filter: (&(|(uid=ttest)(mail=ttest))(objectclass=person))
2023-08-03T11:41:33.714Z [DEBUG] churchtools - Search for users
2023-08-03T11:41:33.715Z [DEBUG] churchtools - Wait on Promise for cache key "rawData".
2023-08-03T11:41:33.715Z [DEBUG] churchtools - Wait on Promise for cache key "users".
2023-08-03T11:41:33.980Z [DEBUG] churchtools - Assumed 1 page(s) of data for /api/groups, but had to load 0.
2023-08-03T11:41:33.980Z [DEBUG] churchtools - fetchGroups done
2023-08-03T11:41:33.984Z [ERROR] churchtools - Error while retrieving users:
HTTPError: Response code 403 ()
at Request. (file:///app/node_modules/got/dist/source/as-promise/index.js:86:42)
at Object.onceWrapper (node:events:629:26)
at Request.emit (node:events:526:35)
at Request._onResponseBase (file:///app/node_modules/got/dist/source/core/index.js:726:22)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async Request._onResponse (file:///app/node_modules/got/dist/source/core/index.js:768:13)
2023-08-03T11:41:33.984Z [DEBUG] churchtools - fetchGroupTypes done
2023-08-03T11:41:34.013Z [DEBUG] churchtools - Assumed 1 page(s) of data for /api/persons, which was correct.
2023-08-03T11:41:34.013Z [DEBUG] churchtools - fetchPersons done

Handling of http status 429 response codes from CT

We did migrate back from our own hosted churchtool to ChurchTool.

Since then, the rest api of CT returns a lot of 429 errors (Too many requests)
Even with caching enabled we get these errors, and then the logins fail in the LDAP.

Any way to improve handling of this?

Status as group

Hi.

It would be nice to share objects with all people with the same status, so it is possible to share a folder with all Members, Guests, etc.

What about to add virtual groups for every status, like 'STATUS_Mitglieder', 'STATUS_Gast', etc?

Any ideas? Is this possible with the CTS API?

Exclude archived persons

Currently, also archived persons are delivered by ctldap. They have to be excluded. In DB the field archive_yn is used for that. Maybe the API does not provide this information.

Retrieve LDAP Information with authenticated user

I have some apps which try to retrieve information by its authenticated user. So the ldap wrapper only allows this by the root dn. Could this somehow be extended to any user who is authenticated?

Paging

Hallo,
tolles Projekt! Leider kann ich das für eine Anbindung an Rocket.Chat nicht nutzen, da Rocket.Chat Paging erwartet. Kann das einfach erweitert werden?

Danke,
Simon Scholl

Response code 403 after upgrade to churchtools 3.101.0

Hello,

our setup did work with the 3.100.0 release.
On tuesday night the system did upgrade to churchtools 3.101.0 and now we can't login via ldap.
The ctldap is on 3.1.2 and here what we see in the log of the ctldap docker container.

Interesting to note:
Yesterday I did login as nextcloud admin (Without ldap authentication) and then I could verify the LDAP auth settings and then it did work for a few minutes.
Then afterward it stopped working.
I did the same again one more time, but then I could not get it working anymore...

Any ideas?
Perhaps someting related to #46 ? The error/behaviour looks the same.
Of course I did triple check the api_key
We are using a dedicated ct account for ldap requests, which is not used in any other way by users or systems.

2023-09-21T06:40:07.384Z [DEBUG] churchtools - SEARCH base object: cn=bwagner, ou=users, o=churchtools scope: base
2023-09-21T06:40:07.384Z [DEBUG] churchtools - Filter: (objectclass=*)
2023-09-21T06:40:07.384Z [DEBUG] churchtools - Search for users
2023-09-21T06:40:07.385Z [DEBUG] churchtools - Wait on Promise for cache key "rawData".
2023-09-21T06:40:07.387Z [DEBUG] churchtools - Wait on Promise for cache key "users".
2023-09-21T06:40:07.993Z [DEBUG] churchtools - Assumed 2 page(s) of data for /api/persons, which was correct.
2023-09-21T06:40:08.491Z [DEBUG] churchtools - fetchPersons done
2023-09-21T06:40:08.564Z [DEBUG] churchtools - fetchGroupTypes done
2023-09-21T06:40:08.711Z [DEBUG] churchtools - fetchGroups done
2023-09-21T06:40:09.279Z [DEBUG] churchtools - Assumed 2 page(s) of data for /api/persons, which was correct.
2023-09-21T06:40:09.801Z [DEBUG] churchtools - fetchPersons done
2023-09-21T06:40:09.865Z [ERROR] churchtools - Error while retrieving users:
HTTPError: Response code 403 (Forbidden)
    at Request.<anonymous> (file:///app/node_modules/got/dist/source/as-promise/index.js:86:42)
    at Object.onceWrapper (node:events:628:26)
    at Request.emit (node:events:525:35)
    at Request._onResponseBase (file:///app/node_modules/got/dist/source/core/index.js:726:22)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Request._onResponse (file:///app/node_modules/got/dist/source/core/index.js:768:13)
2023-09-21T06:40:09.880Z [DEBUG] churchtools - SEARCH base object: cn=bwagner, ou=users, o=churchtools scope: base
2023-09-21T06:40:09.880Z [DEBUG] churchtools - Filter: (objectclass=*)
2023-09-21T06:40:09.880Z [DEBUG] churchtools - Search for users
2023-09-21T06:40:09.881Z [DEBUG] churchtools - Wait on Promise for cache key "rawData".
2023-09-21T06:40:09.881Z [DEBUG] churchtools - Wait on Promise for cache key "users".
2023-09-21T06:40:10.062Z [DEBUG] churchtools - Assumed 2 page(s) of data for /api/groups, which was correct.
2023-09-21T06:40:10.209Z [DEBUG] churchtools - fetchGroups done
2023-09-21T06:40:10.281Z [DEBUG] churchtools - fetchGroupTypes done
2023-09-21T06:40:10.426Z [DEBUG] churchtools - Assumed 2 page(s) of data for /api/groups, which was correct.
2023-09-21T06:40:10.990Z [DEBUG] churchtools - Assumed 2 page(s) of data for /api/persons, which was correct.
2023-09-21T06:40:11.128Z [DEBUG] churchtools - fetchGroups done
2023-09-21T06:40:11.215Z [DEBUG] churchtools - fetchGroupTypes done
2023-09-21T06:40:11.287Z [ERROR] churchtools - Error while retrieving users:
HTTPError: Response code 403 (Forbidden)
    at Request.<anonymous> (file:///app/node_modules/got/dist/source/as-promise/index.js:86:42)
    at Object.onceWrapper (node:events:628:26)
    at Request.emit (node:events:525:35)
    at Request._onResponseBase (file:///app/node_modules/got/dist/source/core/index.js:726:22)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Request._onResponse (file:///app/node_modules/got/dist/source/core/index.js:768:13)
2023-09-21T06:40:11.863Z [DEBUG] churchtools - fetchPersons done

Case sensitivity for username login

First of all: thanks for this wrapper! Really great to have the integration with ChurchTools and (in our case) Nextcloud :)

We have the issue that the username is case sensitive. If the ChurchTools user has the cn TestUser, he cannot login with testuser, just with TestUser.

We have the following login filter defined:
(&(&(|(objectclass=CTPerson)))(|(uid=%uid)(|(mailPrimaryAddress=%uid)(mail=%uid))(|(cn=%uid))))

There seems to exist an LDAP syntax like cn:caseIgnoreMatch:%uid but the LDAP server crashes when using this kind of syntax.

The issue is also not on the ChurchTools side, as the casing of the username doesn't matter there. There is simply no LDAP search result if the casing does not match.

Is there any chance to define the LDAP attribute values in filters as case insensitive? A substring filter with * (which is case insensitive) doesn't help here, as the username must match exactly (aside from the casing).

How to use ctldap in Docker?

Hi,
there is a Docker container available, that's great! I could install it (in an environment with Portainer + Traefik). But there is nothing more than a single log item:

ChurchTools-LDAP-Wrapper listening @ ldap://0.0.0.0:1389

I have several questions:

  • config file: what do you mean with "virtual root"? is this the user I have to use later when another application (like NextCloud) will contact this LDAP server?
  • config file: the API user is a CT user - why do you use the real username/password and don't use the login token? this would make the password a little bit more "secret" ...
  • How can i check if the installation and the connection to CT really works? Should the log show any details about a successful connection?
  • How can I access the LDAP server in this container from another container (e.g. NextCloud)?

Regards,
Oliver

Error with new 3.0.0 release

Got the new version up and running, but upon issuing the test request with my login it throws this error

ldap_1  | 2023-02-18T14:53:45.076Z [DEBUG] root logger - Debug mode enabled, expect lots of output!
ldap_1  | 2023-02-18T14:53:45.088Z [DEBUG] root logger - ChurchTools-LDAP-Wrapper listening @ ldap://0.0.0.0:1389
ldap_1  | 2023-02-18T14:53:50.428Z [DEBUG] churchtools - Admin bind DN: cn=root, ou=users, o=churchtools
ldap_1  | 2023-02-18T14:53:50.428Z [DEBUG] churchtools - Admin bind successful
ldap_1  | 2023-02-18T14:53:50.436Z [DEBUG] churchtools - SEARCH base object: o=churchtools scope: sub
ldap_1  | 2023-02-18T14:53:50.437Z [DEBUG] churchtools - Filter: (&(&(objectclass=ctperson))(|(cn=*andre*)(mail=*andre*)))
ldap_1  | 2023-02-18T14:53:50.438Z [DEBUG] churchtools - Search for users and groups combined
ldap_1  | 2023-02-18T14:53:50.445Z [DEBUG] churchtools - Wait on Promise for cache key "rawData".
ldap_1  | 2023-02-18T14:53:50.445Z [DEBUG] churchtools - Wait on Promise for cache key "users".
ldap_1  | 2023-02-18T14:53:50.446Z [DEBUG] churchtools - Returning pending Promise for cache key "rawData".
ldap_1  | 2023-02-18T14:53:50.446Z [DEBUG] churchtools - Wait on Promise for cache key "rawData".
ldap_1  | 2023-02-18T14:53:50.447Z [DEBUG] churchtools - Wait on Promise for cache key "groups".
ldap_1  | 2023-02-18T14:53:50.775Z [DEBUG] churchtools - fetchGroupTypes done
ldap_1  | 2023-02-18T14:53:50.963Z [DEBUG] churchtools - fetchMemberships done
ldap_1  | 2023-02-18T14:53:51.221Z [DEBUG] churchtools - fetchGroups done
ldap_1  | 2023-02-18T14:53:51.540Z [DEBUG] churchtools - Admin bind DN: cn=root, ou=users, o=churchtools
ldap_1  | 2023-02-18T14:53:51.540Z [DEBUG] churchtools - Admin bind successful
ldap_1  | 2023-02-18T14:53:51.543Z [DEBUG] churchtools - SEARCH base object: cn=cvon wartburg, ou=users, o=churchtools scope: base
ldap_1  | 2023-02-18T14:53:51.543Z [DEBUG] churchtools - Filter: (objectclass=*)
ldap_1  | 2023-02-18T14:53:51.544Z [DEBUG] churchtools - Search for users
ldap_1  | 2023-02-18T14:53:51.544Z [DEBUG] churchtools - Returning pending Promise for cache key "users".
ldap_1  | 2023-02-18T14:53:51.544Z [DEBUG] churchtools - Wait on Promise for cache key "users".
ldap_1  | 2023-02-18T14:53:52.377Z [DEBUG] churchtools - fetchPersons done
ldap_1  | 2023-02-18T14:53:52.380Z [DEBUG] churchtools - Store cache entry for cache key "rawData".
ldap_1  | 2023-02-18T14:53:52.382Z [DEBUG] churchtools - Updated users: 61
ldap_1  | 2023-02-18T14:53:52.383Z [DEBUG] churchtools - Updated groups: 178
ldap_1  | 2023-02-18T14:53:52.384Z [DEBUG] churchtools - Store cache entry for cache key "users".
ldap_1  | 2023-02-18T14:53:52.384Z [DEBUG] churchtools - Store cache entry for cache key "groups".
ldap_1  | 2023-02-18T14:53:52.387Z [DEBUG] churchtools - MatchUser: cn=cvon wartburg,ou=users,o=churchtools
ldap_1  | file:///app/ctldap.js:637
ldap_1  |   const tv = helpers.getAttrValue(target, this.attribute, strictAttrCase);
ldap_1  |                                                ^
ldap_1  |
ldap_1  | TypeError: Cannot read properties of undefined (reading 'attribute')
ldap_1  |     at ldap.filters.SubstringFilter.matches (file:///app/ctldap.js:637:48)
ldap_1  |     at OrFilter.matches (/app/node_modules/ldapjs/node_modules/ldap-filter/lib/or_filter.js:49:25)
ldap_1  |     at AndFilter.matches (/app/node_modules/ldapjs/node_modules/ldap-filter/lib/and_filter.js:54:26)
ldap_1  |     at file:///app/ctldap.js:481:81
ldap_1  |     at Array.forEach (<anonymous>)
ldap_1  |     at file:///app/ctldap.js:480:11
ldap_1  |     at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
ldap_1  |
ldap_1  | Node.js v18.14.1

Deamon crash on parser error

When the ldap server receives unknown/unhandled packets/requests, the daemon might abort with a fatal error und the ldap service is dead.

Here the stack trace ejected when the daemon did stop.
I don't yet know what request was incomming to the server

Mar 13 11:47:05 rc19b0502 ctldap[9779]: events.js:174
Mar 13 11:47:05 rc19b0502 ctldap[9779]:       throw er; // Unhandled 'error' event
Mar 13 11:47:05 rc19b0502 ctldap[9779]:       ^
Mar 13 11:47:05 rc19b0502 ctldap[9779]: VError: Parser error for xx.xxx.xxx.xx:1287: Parser error for xx.xxx.xxx.xx:1287: Op 0x?? not supported
Mar 13 11:47:05 rc19b0502 ctldap[9779]:     at Parser.<anonymous> (/opt/ctldap-ms-master/node_modules/ldapjs/lib/server.js:442:26)
Mar 13 11:47:05 rc19b0502 ctldap[9779]:     at Parser.emit (events.js:189:13)
Mar 13 11:47:05 rc19b0502 ctldap[9779]:     at Parser.write (/opt/ctldap-ms-master/node_modules/ldapjs/lib/messages/parser.js:107:10)
Mar 13 11:47:05 rc19b0502 ctldap[9779]:     at Socket.<anonymous> (/opt/ctldap-ms-master/node_modules/ldapjs/lib/server.js:460:16)
Mar 13 11:47:05 rc19b0502 ctldap[9779]:     at Socket.emit (events.js:189:13)
Mar 13 11:47:05 rc19b0502 ctldap[9779]:     at addChunk (_stream_readable.js:284:12)
Mar 13 11:47:05 rc19b0502 ctldap[9779]:     at readableAddChunk (_stream_readable.js:265:11)
Mar 13 11:47:05 rc19b0502 ctldap[9779]:     at Socket.Readable.push (_stream_readable.js:220:10)
Mar 13 11:47:05 rc19b0502 ctldap[9779]:     at TCP.onStreamRead [as onread] (internal/stream_base_commons.js:94:17)
Mar 13 11:47:05 rc19b0502 ctldap[9779]: Emitted 'error' event at:
Mar 13 11:47:05 rc19b0502 ctldap[9779]:     at Parser.<anonymous> (/opt/ctldap-ms-master/node_modules/ldapjs/lib/server.js:442:12)
Mar 13 11:47:05 rc19b0502 ctldap[9779]:     at Parser.emit (events.js:189:13)
Mar 13 11:47:05 rc19b0502 ctldap[9779]:     [... lines matching original stack trace ...]
Mar 13 11:47:05 rc19b0502 ctldap[9779]:     at TCP.onStreamRead [as onread] (internal/stream_base_commons.js:94:17)


CT User with umlauts in cn not syncing

In the process of mapping preexisting NC users to newly synced ldap users from CT discovered no occ ldap:check-user --update USERID possible with ldap (CT) users containing umlauts in their cn.

Initial LDAP sync shows umlauts as white question marks on black rhombus in DB table oc_ldap_user_mapping but when doing the ldap:check-user after entering the oc_name and directory_uuid from the existing NC user I get
The user does not exists on LDAP anymore. Clean up the user's remnants by: ./occ user:delete "USERID"

Ist the wrapper coping with umlauts?

ext match implementation missing

First of all thanks for your work.

I tried to attach a gitlab-Server to the LDAP-Wrapper, but there seems to be a missing implementation accordings to the log:
missing-implementation.txt
As Reference also this Pull-Request, which is obsolet with your changes as it doesn't help anymore with version 3.0.1: churchtools#4
As there is the new version, I created here the Issue.

So today I tested it with the version 3.0.1 (commit 94aeab9) and it wasn't successfull.
When I add

ldap.ExtensibleFilter.super_.prototype.matches = function() {
}

it's working, but I'm pretty shure there is some implementation for that function missing. ;-)

Problem with Umlaut in Groups using Apache LDAP

Hi,

I'm trying to get several small web apps authenticated by Apache's LDAP to ctldap. For some reason the group membership seems to fail in case the group contains german Umlaut, perhaps any non-ascii characters.

The user is member in both groups. But authorization fails with groups like this:

[DEBUG] churchtools-test - Filter: (&(&(objectclass=*)(memberof=cn=Gemeindebüro,ou=groups,o=churchtools-test))(uid=xxx))
[DEBUG] churchtools-test - Search for users and groups combined
[DEBUG] churchtools-test - Performing request to API function getUsersData
[DEBUG] churchtools-test - Performing request to API function getGroupsData
[DEBUG] churchtools-test - CT session invalid, login and retry...
[DEBUG] churchtools-test - Performing CT API login...
[DEBUG] churchtools-test - CT session invalid, login and retry...
[DEBUG] churchtools-test - Return pending login promise
[DEBUG] churchtools-test - CT API login successful, fetching CSRF-Token...
[DEBUG] churchtools-test - Got CSRF-Token.
[DEBUG] churchtools-test - CT API login completed
[DEBUG] churchtools-test - Retry request to API function getUsersData after login
[DEBUG] churchtools-test - Performing request to API function getUsersData
[DEBUG] churchtools-test - Retry request to API function getGroupsData after login
[DEBUG] churchtools-test - Performing request to API function getGroupsData
[DEBUG] churchtools-test - Updated groups: 191
[DEBUG] churchtools-test - Updated users: 294

And succeeds with groups without Umlaut.

[DEBUG] churchtools-test - Admin bind DN: cn=root, ou=users, o=churchtools-test
[DEBUG] churchtools-test - Authentication success
[DEBUG] churchtools-test - SEARCH base object: o=churchtools-test scope: sub
[DEBUG] churchtools-test - Filter: (&(&(objectclass=*)(memberof=cn=it,ou=groups,o=churchtools-test))(uid=xxx))
[DEBUG] churchtools-test - Search for users and groups combined
[DEBUG] churchtools-test - Performing request to API function getUsersData
[DEBUG] churchtools-test - Performing request to API function getGroupsData
[DEBUG] churchtools-test - Updated groups: 191
[DEBUG] churchtools-test - Updated users: 294
[DEBUG] churchtools-test - MatchUser: cn=xxx,ou=users,o=churchtools-test
[DEBUG] churchtools-test - Bind user DN: %s
[DEBUG] churchtools-test - Performing request to API function authenticate
[DEBUG] churchtools-test - Authentication successful for cn=xxx, ou=users, o=churchtools-test

We also using nextcloud, which works just fine with any groups. But using apache doesn't seem to be too exotic as this could open the door for many small webapps.
All I could found was this issue in the past: #4

So far I also tried several options in Apache with no difference.
AddLanguage de .de
AddDefaultCharset utf-8

Also, I had apache configs with groups containing german umlaut connecting to MS AD which dint cause any issues.

Could this be fixed in ctldap, because there doesn't seem to be too much possibilities on apaches configuration to change its behavior:
The closest option seems to be the AuthLDAPCharsetConfig Directive. But there aren't many information on this.

My Auth in Apache look like this.
_<
AuthName "Auth"
AuthType Basic
AuthLDAPBindDN "cn=root,ou=users,o=churchtools-test"
AuthLDAPBindPassword "PW"
AuthLDAPURL "ldap://localhost:7777/o=churchtools-test?uid?sub?(&(objectClass=*)(memberof=cn=Gemeindebüro,ou=groups,o=churchtools-test))"
AuthBasicProvider ldap
Require valid-user

_

wrong password results in 400 (Bad Request)

Lately since version 3.0.2 and Chuchtools 3.100 we have an issue on Nextcloud login with wrong passwords. In this case Nextcloud ends up with an Internal Server Error.

Nextcloud Log shows:
version":"26.0.5.1","exception":{"Exception":"Exception","Message":"LDAP Operations error","Code":1,"Trace":[{"file":"/srv/nextcloud/nc/apps/user_ldap/lib/LDAP.php

ctldap log:

ctldap3  | 2023-08-11T06:53:59.316Z [ERROR] churchtools - Authentication error:
ctldap3  | HTTPError: Response code 400 (Bad Request)
ctldap3  |     at Request.<anonymous> (file:///app/node_modules/got/dist/source/as-promise/index.js:86:42)
ctldap3  |     at Object.onceWrapper (node:events:628:26)
ctldap3  |     at Request.emit (node:events:525:35)
ctldap3  |     at Request._onResponseBase (file:///app/node_modules/got/dist/source/core/index.js:726:22)
ctldap3  |     at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
ctldap3  |     at async Request._onResponse (file:///app/node_modules/got/dist/source/core/index.js:768:13)

Wrong users will fall back to login-page and therefore works. Also proper logins working fine.

Same on older Versions on Nextcloud 25, so it seems to be related to ctldap 3.0.2?

Churchtools 3.100 sends a HTTP Response code 500 back

With the latest Update of Churchtools today with the Version 3.100 the Wrapper is broken.
I had a look to the Logs (Debug enabled) and there I can see that the server sends an HTTP Response Code 500 back.
As far, as I understand the JavaScript Code, the request is to /api/persons and /api/groups
When I test the requests with Swagger from Churchtools (/api) the request for /api/persons does require really long but return successfully a result. The request to /api/groups returns an error back. Is there anyone else with this problem?

I used the latest Version of the Wrapper.

And here are the logs (redacted):

2023-07-10T09:09:00.305Z [DEBUG] root logger - Debug mode enabled, expect lots of output!
2023-07-10T09:09:00.309Z [DEBUG] root logger - ChurchTools-LDAP-Wrapper listening @ ldap://0.0.0.0:1389
2023-07-10T09:09:11.788Z [DEBUG] ORGANISATION - Admin bind DN: cn=root, ou=users, o=ORGANISATION
2023-07-10T09:09:11.788Z [DEBUG] ORGANISATION - Admin bind successful
2023-07-10T09:09:11.791Z [DEBUG] undefined - Empty request, return directory information
2023-07-10T09:09:11.838Z [DEBUG] ORGANISATION - SEARCH base object: o=ORGANISATION scope: sub
2023-07-10T09:09:11.838Z [DEBUG] ORGANISATION - Filter: (&(cn=USERNAME)(objectclass=ctperson)(memberof=cn=GROUP,ou=groups,o=ORGANISATION))
2023-07-10T09:09:11.838Z [DEBUG] ORGANISATION - Search for users and groups combined
2023-07-10T09:09:11.842Z [DEBUG] ORGANISATION - Wait on Promise for cache key "rawData".
2023-07-10T09:09:11.842Z [DEBUG] ORGANISATION - Wait on Promise for cache key "users".
2023-07-10T09:09:11.842Z [DEBUG] ORGANISATION - Returning pending Promise for cache key "rawData".
2023-07-10T09:09:11.842Z [DEBUG] ORGANISATION - Wait on Promise for cache key "rawData".
2023-07-10T09:09:11.842Z [DEBUG] ORGANISATION - Wait on Promise for cache key "groups".
2023-07-10T09:09:12.358Z [DEBUG] ORGANISATION - fetchGroupTypes done
2023-07-10T09:09:12.472Z [DEBUG] ORGANISATION - fetchMemberships done
2023-07-10T09:09:13.515Z [DEBUG] ORGANISATION - fetchPersons done
2023-07-10T09:09:15.758Z [ERROR] ORGANISATION - Error while retrieving users: 
HTTPError: Response code 500 (Internal Server Error)
    at Request.<anonymous> (file:///app/node_modules/got/dist/source/as-promise/index.js:86:42)
    at Object.onceWrapper (node:events:628:26)
    at Request.emit (node:events:525:35)
    at Request._onResponseBase (file:///app/node_modules/got/dist/source/core/index.js:726:22)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Request._onResponse (file:///app/node_modules/got/dist/source/core/index.js:765:13)
2023-07-10T09:09:15.758Z [ERROR] ORGANISATION - Error while retrieving groups: 
HTTPError: Response code 500 (Internal Server Error)
    at Request.<anonymous> (file:///app/node_modules/got/dist/source/as-promise/index.js:86:42)
    at Object.onceWrapper (node:events:628:26)
    at Request.emit (node:events:525:35)
    at Request._onResponseBase (file:///app/node_modules/got/dist/source/core/index.js:726:22)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Request._onResponse (file:///app/node_modules/got/dist/source/core/index.js:765:13)

iptables port forwarding is activated, even when line is commented out

If the config file holds a line with "iptables_port=xxx" in it anywhere, then the port forwarding is activated in iptables, even when the line is commented out.

Changing the regex to "(?<=^iptables_port=)\s*[1-9][0-9]+" solves this problem, and also allows blanks between the = and the port number.

See patch in a-schild fork

Trouble running container on Synology

Trying to run this on Synology DSM with Container Manager.

Built the image, ran with the following .env (replaced some stuff with <var>):

DEBUG=true
TRACE=true
# This is required for clients using lowercase DNs, e.g. ownCloud/nextCloud
IS_DN_LOWER_CASE=true
# This is required for clients that need lowercase email addresses, e.g. Seafile
IS_EMAIL_LOWER_CASE=true

# LDAP admin user, can be a "virtual" root user or a ChurchTools username (virtual root is recommended!)
LDAP_USER=root
# The static password to be used for the virtual ldapUser, i.e. if that one is NOT a CT account.
# Ideally, choose a LONG SECURE RANDOM password from a password generator like KeePass and hash it with argon2!
LDAP_PW=<ldap_pw>
# LDAP base DN, "o=<xxx>", e.g. "o=churchtools"
LDAP_BASE_DN="o=churchtools"

# LDAP server ip to listen on, change it to 0.0.0.0 when external access required
LDAP_IP=0.0.0.0
# LDAP server port, you may change this to the privileged default port 389.
LDAP_PORT=1389

# The URI pointing to the root of your ChurchTools installation
CT_URI=https://<ct_base>.church.tools
# This access token is used to authenticate against ChurchTools for API access.
# The backing user must be granted sufficient rights for the wrapper to work properly! Typically, these are:
# churchdb:{ view | view alldata(-1) | view grouptype(-1) | security level person(1,2*) | security level group(1*) }
# * = additional security levels might be required, depending on your ChurchTools settings.
# IMPORTANT: It is strongly recommended to use a LONG SECURE RANDOM password from a generator like KeePass for this user!
# You can obtain the API token from the API:
# - Login via https://your.ct.domain/api > "General" > "login" (copy your "personId" from the shown output!)
# - Get your token via "Person" > "/persons/{personId}/logintoken"
API_TOKEN="<my_personal_token>"

# This controls (in milliseconds) how old the user/group data can be until it is fetched from ChurchTools again
CACHE_LIFETIME_MS=300000

When I try to connect with

ldapsearch -H ldap://<synology>:1389 -x -w "<ldap_pw>" -D cn=root,ou=users,o=<ct_base> -b o=<ct_base>

I get: ldap_bind: No such object (32)

docker log shows:

2024/03/06 13:32:13	stdout	2024-03-06T12:32:13.321Z [DEBUG] root logger - ChurchTools-LDAP-Wrapper listening @ ldap://0.0.0.0:1389
2024/03/06 13:32:13	stdout	2024-03-06T12:32:13.312Z [DEBUG] root logger - Debug mode enabled, expect lots of output!

Not sure I got the users/pw all right.

Nextcloud group assignements get lost during ct upgrade

  • user is actively using nextcloud with the ldap integration

  • When ct is upgrading and the user is active in nextcloud during the upgrade, the group assignements in nextcloud of the active user get lost

  • After some time the group assignement in nextcloud are OK again

SSL doesn't seem to work

The options seems to be missing in const server = ldap.createServer();
So, ldaps doesn't work, even ldapCertFilename and ldapKeyFilename ist defined.

Could you change it for future release?

if (config.ldapCertFilename && config.ldapKeyFilename) {
  const ldapCert = fs.readFileSync(new URL(`./${config.ldapCertFilename}`, import.meta.url), { encoding: "utf8" }),
      ldapKey = fs.readFileSync(new URL(`./${config.ldapKeyFilename}`, import.meta.url), { encoding: "utf8" });
  options = { certificate: ldapCert, key: ldapKey };
}
const server = ldap.createServer(options);

Case-insensitive search missing

The search is case sensitiv. Users can't login with Test1, but with test1 if user is test1.

$ docker-compose run test ldapsearch -H ldap://ldap:1389 -x -D cn=root,ou=users,o=**** -w ^****************
-LLL -b o=**** '(&(&(objectclass=ctperson))(|(cn=*test1*)))'
dn: cn=test1.user,ou=users,o=****
cn: test1.user
displayname: Test1 User
id: 1507
uid: test1.user
nsuniqueid: u1507
givenname: Test1
sn: User
email: test@*****.de
mail: test@*****.de
objectclass: CTPerson
memberof: cn=it,ou=groups,o=****

$ docker-compose run test ldapsearch -H ldap://ldap:1389 -x -D cn=root,ou=users,o=****  -w ******************
-LLL -b o=**** '(&(&(objectclass=ctperson))(|(cn=*Test1*)))'

Support full LDAP Protocol for Apache Ldap Mod

I would like to use the Apache LDAP Module.
https://httpd.apache.org/docs/2.4/mod/mod_authnz_ldap.html

Currently it does not work. I think one reason is the missing support for a full ldaps URL with parameters.
Also maybe wrong implementation of finding groups of users.

Following configuration should work, if the adapter would support full ldap protocol:

<Directory /var/www/html/auth-ldap>
AuthName "LDAP Authentication"
AuthType Basic
AuthBasicProvider ldap
AuthLDAPBindDN cn=root,ou=users,o=<churchtoolsaccount>
AuthLDAPBindPassword SECRET
AuthLDAPURL ldaps://ldap.church.tools/o=<churchtoolsaccount>?uid?sub
AuthLDAPGroupAttributeIsDN off
Require ldap-group cn=<groupname>,ou=groups,o=<churchtoolsaccount>
</Directory>

groupname = Group name in Church Tools for you created group
churchtoolsaccount = Church Tools Accountname.

Umlaut

Hi,

Within our installation of ChurchTools, group titles can contain umlauts.
They can cause problems when connecting Apps like NextCloud to ctldap.

I've extended ctldap.sh by a function that converts umlauts to their replacements (e.g. "Ü" to "Ue").

Could that be useful for more users (maybe selectable with a config-toggle)?
If so, how would be the best way to contribute it? Using a pull request or just pasting the changes here?

Cheers
Ulrich

subschemaSubentry not working correctly

While trying to setup Synology with this LDAP wrapper, I got the hint that Synology can't connect to the LDAP server because the subschemaSubentry is not correctly set up.

This shows how to fetch schema information from an LDAP server: https://www.openldap.org/faq/data/cache/1366.html

The first command is ldapsearch -x -LLL -b dc=example,dc=com -s base subschemaSubentry

When I run this against my ctldap wrapper (ldapsearch -H ldap://<url>:389 -x -W -D cn=root,ou=users,o=<my_base_dn> -s base subschemaSubentry), I get the following output:

# extended LDIF
#
# LDAPv3
# base <> (default) with scope baseObject
# filter: (objectclass=*)
# requesting: subschemaSubentry 
#

#
dn:

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

According to the docs, the result should be something like:

  dn: dc=Example,dc=COM
  subschemaSubentry: cn=Subschema

In the ctldap server I see log ouput like this:

ctldap_1  | 2024-04-26T06:20:16.777Z [DEBUG] leuchtturm - Admin bind with DN "cn=root,ou=users,o=leuchtturm"
ctldap_1  | 2024-04-26T06:20:16.777Z [DEBUG] leuchtturm - Admin bind successful
ctldap_1  | 2024-04-26T06:20:16.796Z [DEBUG] undefined - Empty request, return directory information

Connect ctldap over docker network

I conntect the ctlap to an other docker container with an docker network.
I get this error by testing the ldap with ldapsearch.

ChurchTools-LDAP-Wrapper listening @ ldap://0.0.0.0:1389
[DEBUG] churchtools - Admin bind DN: cn=root, ou=users, o=churchtools
[DEBUG] churchtools - Authentication success
[DEBUG] churchtools - SEARCH base object: ou=users, o=churchtools scope: sub
[DEBUG] churchtools - Filter: (objectclass=*)
[DEBUG] churchtools - Search for users
[DEBUG] churchtools - Performing request to API function getUsersData
[ERROR] churchtools - Error while retrieving users:
TypeError: Cannot read property '0' of undefined
    at /app/ctldap.js:263:28
    at tryCatcher (/app/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/app/node_modules/bluebird/js/release/promise.js:547:31)
    at Promise._settlePromise (/app/node_modules/bluebird/js/release/promise.js:604:18)
    at Promise._settlePromise0 (/app/node_modules/bluebird/js/release/promise.js:649:10)
    at Promise._settlePromises (/app/node_modules/bluebird/js/release/promise.js:725:18)
    at _drainQueueStep (/app/node_modules/bluebird/js/release/async.js:93:12)
    at _drainQueue (/app/node_modules/bluebird/js/release/async.js:86:9)
    at Async._drainQueues (/app/node_modules/bluebird/js/release/async.js:102:5)
    at Immediate.Async.drainQueues [as _onImmediate] (/app/node_modules/bluebird/js/release/async.js:15:14)
    at processImmediate (internal/timers.js:456:21)

Can you help me ?

Error with Churchtools 3.56.0 "CSRF-Token is invalid"

Nach dem Update auf Churchtools 3.56.0 kommt eine neue Einstellung als default. Diese verhindert, dass ctldap läuft. Ich habe gesehen, das CT @hubermat schon dran arbeitet.
https://github.com/churchtools/ctldap-ms/commits/master

Unser temporärer Fix ist, die Option wieder auszustellen...

Weiteres:

ldap_1  | Error: StatusCodeError: 401 - {"message":"A server error ocurred","translatedMessage":"server.error","messageKey":"server.error","args":[],"errors":[{"message":"CSRF-Token is invalid"}]}
ldap_1  |     at /app/ctldap.js:134:17
ldap_1  |     at tryCatcher (/app/node_modules/bluebird/js/release/util.js:16:23)
ldap_1  |     at Promise._settlePromiseFromHandler (/app/node_modules/bluebird/js/release/promise.js:517:31)
ldap_1  |     at Promise._settlePromise (/app/node_modules/bluebird/js/release/promise.js:574:18)
ldap_1  |     at Promise._settlePromise0 (/app/node_modules/bluebird/js/release/promise.js:619:10)
ldap_1  |     at Promise._settlePromises (/app/node_modules/bluebird/js/release/promise.js:695:18)
ldap_1  |     at _drainQueueStep (/app/node_modules/bluebird/js/release/async.js:138:12)
ldap_1  |     at _drainQueue (/app/node_modules/bluebird/js/release/async.js:131:9)
ldap_1  |     at Async._drainQueues (/app/node_modules/bluebird/js/release/async.js:147:5)
ldap_1  |     at Immediate.Async.drainQueues [as _onImmediate] (/app/node_modules/bluebird/js/release/async.js:17:14)
ldap_1  |     at processImmediate (internal/timers.js:439:21)
ldap_1  | Unhandled rejection TypeError: Cannot read property 'users' of undefined
ldap_1  |     at /app/ctldap.js:176:30
ldap_1  |     at tryCatcher (/app/node_modules/bluebird/js/release/util.js:16:23)
ldap_1  |     at Promise._settlePromiseFromHandler (/app/node_modules/bluebird/js/release/promise.js:517:31)
ldap_1  |     at Promise._settlePromise (/app/node_modules/bluebird/js/release/promise.js:574:18)
ldap_1  |     at Promise._settlePromise0 (/app/node_modules/bluebird/js/release/promise.js:619:10)
ldap_1  |     at Promise._settlePromises (/app/node_modules/bluebird/js/release/promise.js:699:18)
ldap_1  |     at _drainQueueStep (/app/node_modules/bluebird/js/release/async.js:138:12)
ldap_1  |     at _drainQueue (/app/node_modules/bluebird/js/release/async.js:131:9)
ldap_1  |     at Async._drainQueues (/app/node_modules/bluebird/js/release/async.js:147:5)
ldap_1  |     at Immediate.Async.drainQueues [as _onImmediate] (/app/node_modules/bluebird/js/release/async.js:17:14)
ldap_1  |     at processImmediate (internal/timers.js:439:21)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.