Switch LDAP plugin from Adldap2 to LdapRecord #2206
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This PR lays the groundwork for #1983. That work is expected to follow in the coming weeks. |
zackgalbreath
approved these changes
May 22, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Our current LDAP provider, Adldap2, is no longer maintained, and has been superseded by LdapRecord, which is maintained by the same author and contains similar functionality to Adldap2. This PR makes the changes required to move our existing LDAP features from Adldap2 to LdapRecord.
A major change in this upgrade is the way LDAP is configured. I have made an attempt to keep the user-facing environment variable API the same, but there may be slight differences on some systems. CDash administrators should take care when applying this upgrade on systems with LDAP integration.
Setting up a local environment with LDAP has historically been a major pain point for developers. A significant amount of work remains to be done, but this PR lays the groundwork by including a basic LDAP container in the development environment, against which tests are run. Running tests against an actual live LDAP server provides a more complete end-to-end test of our LDAP integration than the previous mock-based approach. OpenLDAP is used in our test environment, and is the primary target for our LDAP integration. ActiveDirectory support is provided on a best-effort basis only.