Quite urgent: Accessing Cloudron LDAP from an external instance of EspoCRM

[marcusquinn]

Due to the total failure to diagnose and resolve these silent total failure issues, we are forced to build an external non-Cloudron server to host our production copy of EspoCRM:

• https://forum.cloudron.io/topic/3209/timeout-in-espocrm-need-to-restart-webservice
• https://forum.cloudron.io/topic/5214/errors-logs-to-identify-issues
• https://forum.cloudron.io/topic/5177/add-espocrm-api-to-cloudron-health-checks
• https://forum.espocrm.com/forum/general/71485-unexplained-system-freezes-not-showing-in-error-logs-with-the-api-not-responding

We are working on this now with great urgency.

A BIG issue we might have, without support, is the loss of ability to use LDAP integration.

After many months of user training to understand the concepts of LDAP and their username (Espo doesn't support email logins, and browser auto-fill by default is by the domain and not the host, so that also causes issues), we REALLY need to NOT lose the LDAP connection!

What do we do?

I am afraid the continual finger pointing in either direction and lack of conclusive evidence-based debate has forced this situation. Business just cannot wait for two separate lesser-motivated or directly affected parties to decide which has the fault to fix.

It would at least help us to recover some more developer time to diagnose the problems for all, that neither support has been able to still, if we have a way to continue to use the same LDAP server from an external service.

I only post these requests if there's a genuine need and exponential costs for not solving. Your help in this would be greatly appreciated!

[nebulon]

@marcusquinn the LDAP on the Cloudron will only serve to localhost, so there is no way currently to expose it to the public internet. Even if we patch it to listen to 0.0.0.0 it will not be secure and you will leak passwords.

Since you linked all those forum issues, what exactly is the issue? Apache simply stops responding at some point and you don't see the logs?

In similar environments like passenger through apache, this usually means that some requests take too long, exhausting the pool of request handlers or they get even stuck indefinitely. Could this be the issue?

[vladimir.d]

Managed to expose LDAP to VPN by amending iptables on the cloudron host:

$ iptables -I CLOUDRON 4 -s 10.100.10.0/16 -i tun0 -p tcp -m tcp --dport 3002 -j ACCEPT

But when I try to connect to ldap using ldapsearch, it returns an error.

ldapsearch -x -b "ou=users,dc=cloudron" -D "cn=0111a111b-111-1111-1111-1111111,ou=apps,dc=cloudron" -W${CLOUDRON_LDAP_BIND_PASSWORD} -H ldap://10.100.10.1:3002

Error:

# extended LDIF
#
# LDAPv3
# base <ou=users,dc=cloudron> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 1 Operations error
matchedDN: ou=users, dc=cloudron
text: App not found

# numResponses: 1

The same DN and password work well in the application.

[marcusquinn]

@nebulon And herein lies another layer of blockage we have to circumnavigate.

It is business-critical these issues are solved, and the costs of not solving them are astronomical.

So, for every can't or won't, we have to find a can and will, we simply have no option but to solve this.

Now, what I need to know is who can or is willing to persevere through to a resolution.

For the many things people have commented in guesswork, we are still lacking evidence, the lack of evidence encourages further speculation and the merry-go-round continues without a solution.

So what can we do? And, what will anyone do?

[marcusquinn]

@vladimir-d Good thinking and progress!

@nebulon & @girish we have the need, appetite and commitment to solve this, will you help with that please?

Every and any solutions we find or create, we willingly share with the community, there's a lot of investment on the line for our commitments to share here, whatever you can help with is highly appreciated. If you need something for this time, please do let me know.

[nebulon]

@marcusquinn so the ldap server will also validated the source IP address to verify that it actually comes from the docker container of the app as well as identifying the app for access control checks. See https://git.cloudron.io/cloudron/box/-/blob/6.3/src/ldap.js#L32

Not sure how to easily solve this there without hardcoding IP addresses in that function. Especially patching your local version just leads to problems on updates of course.

[luckow]

Our current workaround for a multi-cloudron setup is to use an external LDAP for the user base and external LDAP-connected Cloudrons. We use UCS for this purpose. Because of the complexity of UCS, this is not ideal. Therefore, we are working on an identity provider based on Drupal to connect other applications via oauth, openID and later id4me.
Do you know if EspoCRM is able to use any of these protocols?

[vladimir.d]

@nebulon could you suggest a workaround of App not found to connect to LDAP?

Could you amend the code so it reads the allowed IPs from a config file or Cloudron console?

[nebulon]

@vladimir-d is this happening on your instance I have SSH access to? If so, can you send me the IPs via support@cloudron.io, then I can see if I can hack this. However really this is only a temporary solution, as in we wont add support for that case into the platform like a config option or such.

[vladimir.d]

@nebulon Yes, it's the instance you have SSH access.
We understand it's a temporary workaround and there could be upgrade issues (re-applying the patch), just need this done as soon as possible.
Later we can look at packaging of some LDAP proxy app or using external LDAP or wait when you implement a solution in the mainstream.

Thanks a lot!
ps. just sent details by email.

[marcusquinn]

@luckow Sounds fun! Espo currently only offers self-auth or LDAP.

We still need to look into UCS more as well and might have more questions on that. SSO is still quite a leap of endeavour more than is should be. I'd be very happy if we can solve all of that with open-source.

[marcusquinn]

@nebulon Never say never! We wouldn't be jumping through all these obstacles if it weren't that we are forced to for lack of practical alternatives. These are very valuable solutions for everyone to have both reliable and debuggable apps, and LDAP across multiple servers where one server stack cannot fulfil needs.