docs: (IAC-1294) viya_admin in sitedefault.yaml breaks LDAP

[bek-afs]

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:

{"version":1,"timeStamp":"2023-08-31T15:14:34.495Z","level":"debug","source":"sas-identities","message":"Could not find identity with filter '(&(uid=viya_admin)(cn=bkoehler))': Incorrect result size: expected 1, actual 0","properties":{"logger":"com.sas.identities.provider.ldap.LdapIdentityQueryRepository","thread":"configWatchTaskScheduler-1"},"messageParameters":{"0":"(&(uid=viya_admin)(cn=bkoehler))","1":"Incorrect result size: expected 1, actual 0"}}
{"version":1,"timeStamp":"2023-08-31T15:14:34.495Z","level":"trace","source":"sas-identities","message":"Invoking fetch query against provider 'scim': identity=viya_admin","properties":{"logger":"com.sas.identities.IdentityQueryProcessor","thread":"configWatchTaskScheduler-1"},"messageParameters":{"0":"scim","1":"viya_admin"}}

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):

{"version":1,"timeStamp":"2023-08-31T15:41:44.449Z","level":"trace","source":"sas-identities","message":"Executing paged search: baseDN='ou=sas_Groups,dc=ldap-govwest1,dc=com', filter='(&(cn=*)(objectClass=posixGroup))'","properties":{"logger":"com.sas.identities.provider.ldap.LdapIdentityQueryRepository","thread":"bootstrap-1"},"messageParameters":{"0":"ou=sas_Groups,dc=ldap-govwest1,dc=com","1":"(&(cn=*)(objectClass=posixGroup))"}}
.
.
.
{"version":1,"timeStamp":"2023-08-31T15:41:44.452Z","level":"trace","source":"sas-identities","message":"Fetch returned 2 identities","properties":{"logger":"com.sas.identities.provider.ldap.LdapIdentityQueryRepository","thread":"bootstrap-1"},"messageParameters":{"0":"2"}}

It successfully fetched 1 user (as expected by the objectFilter I supplied):

{"version":1,"timeStamp":"2023-08-31T15:41:44.339Z","level":"trace","source":"sas-identities","message":"Executing paged search: baseDN='ou=Users,dc=ldap-govwest1,dc=com', filter='(&(uid=*)(cn=bkoehler))'","properties":{"logger":"com.sas.identities.provider.ldap.LdapIdentityQueryRepository","thread":"bootstrap-1"},"messageParameters":{"0":"ou=Users,dc=ldap-govwest1,dc=com","1":"(&(uid=*)(cn=bkoehler))"}}
.
.
.
{"version":1,"timeStamp":"2023-08-31T15:41:44.446Z","level":"trace","source":"sas-identities","message":"Fetch returned 1 identities","properties":{"logger":"com.sas.identities.provider.ldap.LdapIdentityQueryRepository","thread":"bootstrap-1"},"messageParameters":{"0":"1"}}

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:

1. The viya_admin user defined in the sitedefault.yaml (which is included in the deployment as default if no other file is supplied) explicitly causes errors with fetching LDAP users and groups.
2. Even after sas-identities successfully fetches users and groups, they aren't populating in the SAS Environment Manager. I'm not sure if this has anything to do with the fact that I'm logged in as 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.
   1. EDIT: I did try logging in as the user that was successfully fetched above and that returned "The user ID or password is not valid", so I don't think it's just an issue of the 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..)

[thpang]

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.

[bek-afs]

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.

[thpang]

Marking as a bug. This will get picked up and an internal JIRA story will be created to track this issue. Thx.

[jarpat]

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.

[bek-afs]

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.

[jarpat]

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.