3 Replies Latest reply on Nov 4, 2016 1:18 AM by markbenson

    Anonymous LDAP Binds on View Connection Server

    sconley Novice

      We recently went through a security audit and one of the findings was the fact that our connection servers support anonymous LDAP binding.  A couple of questions:

       

      1. What sort of information could be gained by exploiting this?
      2. Is there a way to disable anonymous binding?
      3. Is this something to be overly concerned with?

       

      Thanks

        • 1. Re: Anonymous LDAP Binds on View Connection Server
          markbenson Master
          VMware Employees

          1. None. Anonymous binds on rootDSE are required as part of the LDAP v3 specification to determine the list of supported LDAP SASL bind methods. An Anonymous LDAP bind to Connection Server doesn't allow any Connection Server configuration to be accessed. You can try this with LDP.exe.

          2. No. LDAP v3 binds would not work if we did this.

          3. No.

           

          Mark

          • 2. Re: Anonymous LDAP Binds on View Connection Server
            cswaseem Lurker

            Hi Mark,

             

            We have the same situation in our organization. Is it possible for you to help us with some VMware docs that explains this.

            I would really appreciate it.

            • 3. Re: Anonymous LDAP Binds on View Connection Server
              markbenson Master
              VMware Employees

              Sure. View Connection Server LDAP has 3 base DNs. One for LDAP configuration, one for the schema and one for the Horizon View specific configuration. These are:

               

              • CN=Configuration,CN={<GUID>}
              • CN=Schema,CN=Configuration,CN={<GUID>}
              • DC=vdi,DC=vmware,DC=int

               

              Horizon View Connection Servers require LDAP SASL binds to all three. Anonymous logins are not permitted. This means that data from all three cannot be written or read by an anonymous user.

               

              In addition, LDAP v3 servers support a base level called "root DSE" where base information such as the list of SASL bind methods (supportedSASLMechanisms) is obtained as part of the authentication (bind) process.

               

              You can try this with LDP.EXE on any Horizon View Connection Server. From the menu, select Connection > Connect and specify localhost and port 389. Don't select Connection > Bind (i.e. be anonymous) and then attempt access to any of the 3 LDAP base DNs. You can do this by selecting View > Tree then hitting the down-arrow button and selecting each base DN in turn. You should get an error on each which be something like:

               

              Server error: 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection.

               

              You will be denied any sort of access. You can then try a non anonymous bind by selecting Connection > Bind, repeating the test and you will then be able to access those three trees.

               

              None of this is Horizon View specific, but is part of the standard LDAPv3 spec. So the docs you want are actually the standard LDAP specification RFCs covering the LDAPv3 protocol and the SASL bind mechanism. See RFC 4511 - Lightweight Directory Access Protocol (LDAP): The Protocol

               

              The relevant section is:

               

              https://tools.ietf.org/html/rfc4513#section-5.2.1.55.2.1.5. Determination of Supported SASL Mechanisms

               

              Clients may determine the SASL mechanisms a server supports by

                 reading the 'supportedSASLMechanisms' attribute from the root DSE

                 (DSA-Specific Entry) ([RFC4512], Section 5.1).  The values of this

                 attribute, if any, list the mechanisms the server supports in the

                 current LDAP session state.  LDAP servers SHOULD allow all clients --

                 even those with an anonymous authorization -- to retrieve the

                 'supportedSASLMechanisms' attribute of the root DSE both before and

                 after the SASL authentication exchange.