LDAP not exposing outside

[vladimir.d]

Hi,

It doesn't seem that a long waited feature - the ability to expose LDAP outside is working in our environment after the recent upgrade to 7.1.3.

For some reason 636 port doesn't get available even locally.
netstat -tulpn | grep 636 shows nothing, but 3002 port is still there though.

Also wondering if there is an ability to expose LDAP to a local network only on a specific network interface, e.g. 192.168.10.0/24.

[girish]

@vladimir-d said in LDAP not exposing outside:

For some reason 636 port doesn't get available even locally.
netstat -tulpn | grep 636 shows nothing, but 3002 port is still there though.

This is expected. We use a NAT rule to rewrite queries from 3002 to port 636 (we do this so that the LDAP server can run as non-root for security purposes).

Are you not able to connect to port 636 by IP address (telnet <cloudron-server-ip> 636) ? Have you opened 636 on the firewall ? When you try to telnet make sure that your PC/Mac is on the IP whitelist.

Also wondering if there is an ability to expose LDAP to a local network only on a specific network interface, e.g. 192.168.10.0/24.

Not at an interface level but providing the IP block like you did should work (so you have entered things correctly in the UI AFAICT).

[vladimir.d]

@girish well, telnet <cloudron-server-ip> 636 started to work today, probably another reboot helped.

Now I cannot get anything via ldapsearch neither by a local ip nor by <cloudron-server-domain>.

# ldapsearch  -x -b "ou=users,dc=cloudron" -D "cn=admin,ou=system,dc=cloudron" -W -H ldap://<cloudron-server-domain>:636
ldap_initialize( ldap://<cloudron-server-domain>:636/??base )
Enter LDAP Password: 
ldap_result: Can't contact LDAP server (-1)

[girish]

@vladimir-d said in LDAP not exposing outside:

ldap://<cloudron-server-domain>:636

the above has to be ldaps:// . Do you get the same error with that?

[girish]

@vladimir-d can confirm this works:

$ ldapsearch  -x -b "ou=users,dc=cloudron" -D "cn=admin,ou=system,dc=cloudron" -W -H ldap://my.cloudron.space:636
Enter LDAP Password: 
ldap_result: Can't contact LDAP server (-1)

$ ldapsearch  -x -b "ou=users,dc=cloudron" -D "cn=admin,ou=system,dc=cloudron" -W -H ldaps://my.cloudron.space:636
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <ou=users,dc=cloudron> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# uid-0cfbd3d8-6547-4332-9415-dadfe8b78ac4, users, cloudron
dn: cn=uid-0cfbd3d8-6547-4332-9415-dadfe8b78ac4,ou=users,dc=cloudron
objectclass: user
objectclass: inetorgperson
objectclass: person
objectcategory: person
....

[vladimir.d]

@girish said in LDAP not exposing outside:

@vladimir-d said in LDAP not exposing outside:

ldap://<cloudron-server-domain>:636

the above has to be ldaps:// . Do you get the same error with that?

Yes, this works for ldaps://<cloudron-server-domain>:636 but not for local IP ,e.g.
ldaps://192.168.10.10:636

By <cloudron-server-domain>:

# ldapsearch  -v -c -x -b "ou=users,dc=cloudron" -D "cn=admin,ou=system,dc=cloudron" -W -H ldaps://<cloudron-server-domain>:636
ldap_initialize( ldaps://<cloudron-server-domain>:636/??base )
Enter LDAP Password: 

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

# uid-0430c072-331b-4280-8a95-e92029fd16af, users, cloudron
dn: cn=uid-0430c072-331b-4280-8a95-e92029fd16af,ou=users,dc=cloudron
objectclass: user
objectclass: inetorgperson
objectclass: person
objectcategory: person
...

By local IP:

# ldapsearch  -v -c -x -b "ou=users,dc=cloudron" -D "cn=admin,ou=system,dc=cloudron" -W -H ldaps://192.168.10.10:636 "cn=uid-13f9d18f-afd2-4c41-b78d-f2a32c0a3e18,ou=users,dc=cloudron"
ldap_initialize( ldaps://192.168.10.10:636/??base )
Enter LDAP Password: 
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Wrong cert for the local IP?

Also I noticed that if I save Directory Server configuration several times, multiple duplicate rules added to iptables:

-A PREROUTING -p tcp -m tcp --dport 636 -j REDIRECT --to-ports 3004
-A PREROUTING -p tcp -m tcp --dport 636 -j REDIRECT --to-ports 3004
-A PREROUTING -p tcp -m tcp --dport 636 -j REDIRECT --to-ports 3004
-A PREROUTING -p tcp -m tcp --dport 636 -j REDIRECT --to-ports 3004

[nebulon]

@vladimir-d certs are issued for domain names, in this case for your my.domain.com and not the IP address. So depending on if your client accepts a mismatch in connecting hostname and the hostname mentioned in the cert, using the raw IP will fail.
Is there any specific reason to use the IP (and also the intranet one apparently) instead of the domain name?

[girish]

@vladimir-d said in LDAP not exposing outside:

Yes, this works for ldaps://<cloudron-server-domain>:636 but not for local IP ,e.g.
ldaps://192.168.10.10:636

As @nebulon said, IP addresses cannot have a valid certificate. But (for whatever reason), you really want to use an IP, you can export LDAPTLS_REQCERT=never which disables the cert check for ldapsearch and friends.

[vladimir.d]

@girish said in LDAP not exposing outside:

@vladimir-d said in LDAP not exposing outside:

Yes, this works for ldaps://<cloudron-server-domain>:636 but not for local IP ,e.g.
ldaps://192.168.10.10:636

As @nebulon said, IP addresses cannot have a valid certificate. But (for whatever reason), you really want to use an IP, you can export LDAPTLS_REQCERT=never which disables the cert check for ldapsearch and friends.

Yes, sorted that with passing a flag to switch the cert validation off to ldapsearch.

LDAPTLS_REQCERT=never ldapsearch  -v -c -x -b "ou=users,dc=cloudron" -D "cn=admin,ou=system,dc=cloudron" -W -H ldaps://192.168.10.10:636

In fact, we need to connect various services to ldap not just ldapsearch, so apparently there is only one way out - we have to use a domain name.

Thank you @girish and @nebulon

[girish]

@vladimir-d said in LDAP not exposing outside:

Also I noticed that if I save Directory Server configuration several times, multiple duplicate rules added to iptables:

I was able to reproduce this, thanks for reporting. It's fixed in the next release - https://git.cloudron.io/cloudron/box/-/commit/d13905377c375823e7b6fd66bd248421544a1d2c .

The duplicate rules are harmless nevertheless.