Installation Guide › JBoss Version › High Availability Provisioning Installation › Connector Servers › Connector Server Framework

Connector Server Framework

The use of several Connector Servers is called the Connector Server Framework. The Connector Server Framework has two important characteristics:

• Scalability - multiple connector servers may share the load of working on a set of endpoints.

  For example, a lengthy exploration of an endpoint on one connector server does not influence the ability to operate on an endpoint that is being controlled by another Connector Server

• Communication channel security - communication between Provisioning Server and connector server is encrypted using TLS.

  If an endpoint type uses a proprietary protocol to communicate between the connector server and endpoints of that protocol, the extent of use of the proprietary protocol may be limited to a local network, or even to just local communication inside one server.

When deciding on an implementation strategy, consider these factors so that you protect the Connector Servers in your organization against unauthorized access:

• The Connector Server may be configured to disclose passwords in clear text.

  Any person with access to the system running the Connector Server and with sufficient privileges to modify the configuration of the Connector Server and to restart the Connector Server can make the Connector Server log passwords appear in clear text.

  The Connector Server is based on the open source slapd process. The instructions to make a slapd process log incoming passwords in clear text are in the public domain, for example, by looking at the manual pages at http://www.openldap.org

• The Connector Server is only protected by a bind password.

  The Connector Server trusts any client who connects to it and is able to provide the proper credentials, such as Bind DN and Bind Password. The Connector Server does not know if the connection comes from a Provisioning Server or not. Any user with internal access may disclose the bind password, then connect to the Connector Server from another server, and so have administrator privileges over the endpoints controlled by the Connector Server.

• The Connector Server is not protected against brute force attacks on the bind password

  Unlike the Provisioning Server, the Connector Server is not protected against repeated attempts at binding with different passwords. An attacker may therefore try to guess the password by brute force attack. Should an attacker succeed in guessing the bind password, then the road is open for the attacker to control the endpoints under control of the Connector Server.

For these reasons you are advised to design your implementation such that

• The same organizational unit is responsible for administrative access to all Provisioning Servers and connector servers.
• Your connector servers are suitably protected by firewalls or similar such that the ports may not be reached by unauthorized means.
• The ability to connect to Provisioning Servers and connector servers on non-TLS ports should be disabled in your production environments.