Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


    Cloudron Forum

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular

    Solved LDAP not exposing outside

    Support
    directory
    4
    10
    348
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • vladimir.d
      vladimir.d last edited by girish

      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.

      Screenshot 2022-03-19 at 22.04.33.png

      girish 1 Reply Last reply Reply Quote 0
      • girish
        girish Staff @vladimir.d last edited by

        @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 1 Reply Last reply Reply Quote 0
        • vladimir.d
          vladimir.d @girish last edited by

          @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 2 Replies Last reply Reply Quote 0
          • girish
            girish Staff @vladimir.d last edited by

            @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?

            vladimir.d 1 Reply Last reply Reply Quote 0
            • girish
              girish Staff @vladimir.d last edited by

              @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
              ....
              
              1 Reply Last reply Reply Quote 1
              • Topic has been marked as a question  girish girish 
              • vladimir.d
                vladimir.d @girish last edited by 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 girish 3 Replies Last reply Reply Quote 0
                • nebulon
                  nebulon Staff @vladimir.d last edited by

                  @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?

                  1 Reply Last reply Reply Quote 2
                  • girish
                    girish Staff @vladimir.d last edited by 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 1 Reply Last reply Reply Quote 1
                    • vladimir.d
                      vladimir.d @girish last edited by

                      @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

                      1 Reply Last reply Reply Quote 1
                      • girish
                        girish Staff @vladimir.d last edited by

                        @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.

                        1 Reply Last reply Reply Quote 2
                        • Topic has been marked as solved  girish girish 
                        • First post
                          Last post
                        Powered by NodeBB