Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrating OpenSearch with LDAP #567

Open
mkrnbk23 opened this issue Oct 23, 2023 · 2 comments
Open

Integrating OpenSearch with LDAP #567

mkrnbk23 opened this issue Oct 23, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@mkrnbk23
Copy link

I've been trying to integrate OpenSearch with our LDAP-catalog, in order to not have the whole team logging in as "admin", but I can't quite make it work.

I tried changing the settings in viya4-monitoring-kubernetes/logging/opensearch/securityconfig/config.yaml based on the documentation from OpenSearch which is linked to in the security settings menu in the default SAS OpenSearch installation, i.e. this https://opensearch.org/docs/latest/security/authentication-backends/ldap/

But when I re-apply my installation after updating and adding all required values OpenSearch does not change, and if I go back and login again with my local account and go to securit> settings > the LDAP expression is still the local one
{
"enable_ssl": false,
"enable_start_tls": false,
"enable_ssl_client_auth": false,
"verify_hostnames": true,
"hosts": [
"localhost:8389"
],
"userbase": "ou=people,dc=example,dc=com",
"usersearch": "(sAMAccountName={0})"
}

Is this because I cannot modify the settings after first installation, will it help if I do a complete uninstall and then reinstall ?

Is there a way to do this with settings in the viya4-monitoring-userdir config files instead ?

@gsmith-sas
Copy link
Member

@mkrnbk23 Integrating with a site's LDAP is something we have on our radar but, unfortunately, we haven't had a chance to focus on it yet. I think you are probably correct: you will need to make your changes prior to the initial deployment. Looking over the OpenSearch documentation, I see references to two different files: config/opensearch-security/config.yml and config.yaml. Although those names are very similar, I believe they are in fact two different files. And, as I recall, we have run into cases where the same changes need to be made in both files.

Rather than making changes directly to the files in your copy of our project repo, I suggest you follow our preferred customization process which makes use of a USER_DIR directory. This is a directory located outside of the project repo with a specific set of sub-directories and files with specific names. You point to this directory by setting the environment variable USER_DIR prior to running our scripts. This will ensure you can update your copy of our project repo in the future without wiping out any changes you have made. Please refer to the Customization Process section of our documentation for full details.

In this case, your USER_DIR might be structured like this:
~/myviya4monitoring
~/myviya4monitoring/logging
~/myviya4monitoring/logging/user-values-opensearch.yaml
~/myviya4monitoring/logging/securityconfig/config.yaml

Any customizations you need to make to the OpenSearch config.yaml file would go in the appropriate section within the myviya4monitoring/logging/user-values-opensearch.yaml file. And, any customizations you need to make to the config/opensearch-security/config.yml file would go in the appropriate section of the myviya4monitoring/logging/securityconfig/config.yaml file. Before calling the logging/bin/deploy_logging.sh script, you would set the USER_DIR environment variable to "~/myviyamonitoring".

Please let us know how it goes. As I said, this is something we would like to document but haven't been able to look into due to other priorities. If you are successful, your fellow users could benefit from you experience.

@gsmith-sas
Copy link
Member

@mkrnbk23 We're you ever able to successfully integrate OpenSearch with LDAP? If so, please provide details so other users can see how you did it. As I mentioned last year, this is something we would like to document but haven't been able to look into due to other priorities.

@gsmith-sas gsmith-sas added the enhancement New feature or request label Mar 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants