Problem

As a Jenkins admin, there is no way to validate my LDAP configuration without saving it. This means that the only way to check the configuration is to apply the configuration and potentially lock myself and everyone else out of Jenkins.

In the event of a lock-out the only solution is to login to the Jenkins server and edit the JENKINS_HOME/config.xml file by hand to disable security and continue.

With the new setup wizard in Jenkins 2.x this means that the Jenkins instance will be insecure while trying to fix the LDAP settings (the setup wizard will be using the "own" security realm when I am initially configuring LDAP, once we save the LDAP settings we have lost the "own" realm, so disabling security to fix the LDAP settings will leave the instance vulnerable)

Solution

Provide a means to validate the entire LDAP security realm configuration with trial username/password combinations without saving or applying the security settings.

This will not prevent me from saving broken configurations, but it will provide me the opportunity to validate without saving.

Acceptance Criteria

• There will be a button in the LDAP configuration that will allow validating the current LDAP configuration with a trial username/password combination. The button will be outside the "Advanced" section so that it is always visible. In order to reduce UI clutter, clicking the button will display a popup/modal dialog that prompts for the username and password as well as providing some guidance on how to test effectively.
• When the modal form has been submitted, the validation results will be displayed on the main configuration screen as the admin may need to copy some of the details when correcting their configuration.
• The following validations will be performed
  • Validate that the username / password combination can authenticate. Failure to authenticate will be reported as an error unless the password is empty (in which case it should be a warning).
  • Validate that the username can be found.
    • If the username cannot be found, hints will be provided:
      • Possibly incorrect filter
      • Possibly incorrect search base
      • Possible Root DN inference failure (when not specified by the user) or incorrect (when specified by the user)
      • Where the Manager DN is empty, the LDAP server may not support anonymous user search and a Manager DN may be required.
      • Manager DN may not have appropriate permissions to lookup the user (current server URL field validation already covers Manager password being incorrect)
    • If the username cannot be found but the username / password authenticated, this will be reported as an error.
    • If the username cannot be found and the username / password failed to authenticate, this will be reported as a warning (the admin may be testing an account that should not be reported to Jenkins)
  • When a user has been either authenticated or found through lookup, the groups that the user is a member of will be reported.
  • When a user has been either authenticated or found through lookup, the user details will be reported:

• • • DN
    • Display Name
    • Email Address
  • When a user has been both authenticated and found through lookup, the account details for both paths will be compared and any discrepancies reported:
    • Groups resolved differently
    • Display Name resolved differently
    • Email address resolved differently
  • Display name lookup will be validated. Where the display name is not retrieved for a user the available attributes will be displayed to enable the admin to correct typos
  • Email address resolver will be validated. Where the email address is not retrieved for a user the available attributes will be displayed to enable the admin to correct typos
  • Validate group lookup. When the user has either been authenticated or found through lookup and the user is a member of at least one LDAP group, the reverse lookup of each group that the user is a member of will be validated. Failure to reverse lookup any groups will be reported as an error and hints provided:
    • Possibly incorrect filter
    • Possibly incorrect search base
    • Possible Root DN inference failure (when not specified by the user) or incorrect (when specified by the user)
    • Where the Manager DN is empty, the LDAP server may not support anonymous user search and a Manager DN may be required.
    • Manager DN may not have appropriate permissions to lookup the user (current server URL field validation already covers Manager password being incorrect)
• The LDAP wiki page documentation should be refreshed to reflect the validate button and provide guidance on how to use it effectively.
• @JenkinsRule and unit tests will verify the individual validations
• The Acceptance Test Harness based tests will be augmented to validate a happy path validation and a sad path validation. The effectiveness of individual validations is out-of-scope for the Acceptance Test Harness as they are more efficiently verified through @JenkinsRule and unit tests  

On completion of this feature rtyler will be notified to include reference to this feature in the Jenkins Handbook.