Closed bek-afs closed 4 months ago
Please read the information about LDAP in the docs here: https://github.com/sassoftware/viya4-deployment/blob/main/docs/CONFIG-VARS.md#miscellaneous If needed turn off the internal openLDAP and simply supply the correct credentials for the LDAP server you'd like to control user access into the SAS software.
Hi @thpang, I did not supply the V4_CFG_EMBEDDED_LDAP_ENABLE
value, so by default the internal OpenLDAP was not deployed. I'm referring to V4_CFG_SITEDEFAULT
in the BASE section, which has a note that "When not set, sitedefault is used." Therefore, that viya_admin user is defined as the admin even when V4_CFG_EMBEDDED_LDAP_ENABLE
is not set to true.
I am supplying my own LDAP server credentials via the SAS Environment Manager, and the presence of the viya_admin
user caused issues with fetching from the LDAP as noted in the logs above.
Marking as a bug. This will get picked up and an internal JIRA story will be created to track this issue. Thx.
Hey @bek-afs,
Are you still running into this? If you are configuring your own LDAP server by setting V4_CFG_EMBEDDED_LDAP_ENABLE
to false and not making use our default onem you will also need to supply your own sitedefault.yaml
that has the connection info, groups, and users applicable for your open LDAP instance.
Hi @jarpat, I'm not running into the issue anymore. I think it would be helpful to have a callout in the V4_CFG_EMBEDDED_LDAP_ENABLE
variable doc that the sitedefault.yaml
is the default, especially because V4_CFG_EMBEDDED_LDAP_ENABLE
is false by default. It's any easy mistake to assume that it's fine to use the sitedefault.yaml
as a starting point and then manually update the LDAP configuration in the Environment Manager UI after deploying SAS. But this assumption is indeed false because the viya_admin
user in the sitedefault.yaml
causes issues in updating the LDAP and you have to run commands to first delete that user before being able to update the LDAP configuration.
Hey @bek-afs,
I agree, the doc could include a note about users needing to define their own sitedefault.yaml
if they are opting not to use the default embedded LDAP that is set up by this repo. Converting this into a doc ticket for this addition.
Hi,
I've used this viya4-deployment project to deploy SAS Viya 4 version 2023.08 stable on AWS EKS. I'm now trying to configure LDAP via the SAS Environment Manager, and see logs that indicate a successful connection to the LDAP:
{"version":1,"timeStamp":"2023-08-30T15:39:20.748Z","level":"debug","source":"sas-identities","message":"Got Ldap context on server 'ldap://10.212.48.175:3890'","properties":{"logger":"org.springframework.ldap.core.support.AbstractContextSource","thread":"bootstrap-3"}}
but I've been having issues with the Users and Groups populating. I specifically am seeing this error:
{"version":1,"timeStamp":"2023-08-31T15:14:34.497Z","level":"error","source":"sas-identities","message":"[GET_IDENTITY_MEMBER_ERROR] Cannot add viya_admin member to SASAdministrators group because the USER could not be found.","properties":{"logger":"com.sas.identities.config.DefaultMembershipLoader","thread":"configWatchTaskScheduler-1"},"messageKey":"com.sas.identities.LogMessages.GET_IDENTITY_MEMBER_ERROR","messageParameters":{"0":"viya_admin","1":"SASAdministrators","2":"USER"}}
and I notice that the
viya_admin
user is the one being used to perform the fetch of the LDAP users and groups:It appears that the
viya_admin
user is coming from the sitedefault.yaml file in this repo.I deleted that user with a command like
kubectl -n sas-viya exec sas-consul-server-0 -- bash -c "export CONSUL_HTTP_ADDR=https://localhost:8500 && /opt/sas/viya/home/bin/sas-bootstrap-config kv delete config/identities/sas.identities/administrator"
(FYI that command took 20+ tries to go through - that was problematic...) and I finally saw healthy looking trace logs in the sas-identities pod.It successfully fetched 2 groups (as expected by the objectFilter I supplied):
It successfully fetched 1 user (as expected by the objectFilter I supplied):
The problem is that these groups and users are still not showing up in the SAS Environment Manager Users page. Which doesn't make sense because I'm seeing the sas-identities pod successfully fetch them and there are no errors in the logs. I'm logged in as the
sasboot
user (because I'm not aware of any other way to log in as a different user without first connecting LDAP).So this situation raises two serious issues:
viya_admin
user defined in thesitedefault.yaml
(which is included in the deployment as default if no other file is supplied) explicitly causes errors with fetching LDAP users and groups.sasboot
. If it does, then that seems really problematic because I don't know how to log in as a different user without first setting up LDAP.sasboot
user not having permissions to view the users and groups in the SAS Environment Manager. It still seems to be an issue of the users and groups being fetch successfully but then not actually populated in the SAS Environment Manager, and yet not producing any logs about it..)