Uploaded image for project: 'OpenDJ'
  1. OpenDJ
  2. OPENDJ-6387

Doc: Clarify DS proxy requirements, configuration and usage

    Details

    • Type: Improvement
    • Status: Dev backlog
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 6.5.1
    • Fix Version/s: None
    • Component/s: proxy
    • Labels:
      None

      Description

      Some clarifications and more detail would be useful on the following:

      1) Requirement for support for proxied auth on the remote LDAP server - this is a showstopping prerequisite, and it's not obvious from the docs that most other LDAPv3 servers do not support it, notably including AD. It would be helpful to include a compatibility list. A reference to RFC 4370 and other related documentation might also be useful. Note: With AD as the counterpart, an attempt to set up DS proxy with route-all enabled results in obscure error messages that are hard to track down:

      [18/Jun/2019:12:45:15 +0000] category=BACKEND severity=ERROR msgID=-1 msg=Unwilling to Perform: Unable to register base DN CN=Configuration,CN={<some unknown GUID>} with the Directory Server for backend proxyRoot because that backend already contains another base DN CN=Schema,CN=Configuration,CN={<some unknown GUID>} that is within the same hierarchical path

      Not sure if this should be fixed in docs or in the product. It would be nice if DS could detect whether or not its counterpart supports the required control.

      2) More info and examples should be added on how the proxied connection is actually used in terms of usage of local vs. remote credentials, and how to troubleshoot it. Specifically, it is unclear what bind credentials should be used against the proxy, whether these need to be cloned from the remote, and whether any additional config is required. I was only able to get back a meaningful error response from the proxy after disabling the local access control handler, disabling bind-with-dn-requires-password and enabling return-bind-error-messages.

       3) Impact of misaligned schemas: The docs state clearly that schemas must match, but it is unclear what the impact is if they don't. Sometimes it might not be possible to get the full schema documentation for the target server, is this a road to guaranteed failure, or does it only mean that the proxy can't see what it doesn't know about ? What's the exposure if once-aligned schemas get out of sync ?

      4) In general, there is a daunting amount of information in the proxy chapters, which makes this feature appear complex and hard to configure and operate. Consider perhaps to start off with a 'quick start' example that illustrates how to get a basic proxy up and running in a given example scenario, and how to check that it works.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                tim.vogt Tim Vogt
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated: