As you know SAS Cloud Analytic Services can be configured to use SSSD to validate credentials. These credentials could be sent by direct connections from third-party programming languages, although SSSD isn’t required for these connections just optional. Or these credentials could be credentials that you have stored in DefaultAuth either individually for users or for groups. In my last post we talked about the change in enabling host-launched sessions. If you have followed this, you might find that SSSD is no-longer working for you and you are getting authentication failures.
What is the problem
You might be updating an existing SAS Viya environment to SAS Viya 2021.1.3 or even deploying a new SAS Viya 2021.1.3 environment. You want to use SSSD and you’re fairly certain you have the correct SSSD configuration. This SSSD configuration could either be automatically generated from the LDAP properties for the Identities microservice. Or you might be loading your own custom SSSD configuration. You expect SSSD to authenticate your users correctly – but instead your CAS Controller logs just show:
pam_authenticate failed: Authentication failure (7)
Even if you use your own custom SSSD configuration file and increase the debug_level you still do not see any clear error messages from the SSSD side-car container.
Why does it happen
You have made your environment too secure. Remember last time we talked about the security constraints that the cas-enable-host.yaml file applies to your environment. With these security constraints applied the SSSD authentication will fail.
In fact the file sas-bases/overlays/cas-server/cas-sssd-sidecar.yaml which you include in your kustomization.yaml specifically needs to relax these constraints for SSSD to work correctly. The cas-sssd-sidecar.yaml sets the following in the security context:
- readOnlyRootFilesystem = false
- adds all capabilties
You can review my previous article to understand what these settings mean.
So you have included in your kustomization.yaml two different files that are both attempting to change the security context of the CAS controller template. Therefore, the order in which you add those file references in your kustomization.yaml becomes very important. If the cas-enable-host.yaml file is listed later, it will tighten the security context and SSSD will fail.
How to resolve the issue
So now that you understand the issue and why it is happening it is easy to resolve. You just need to ensure the correct ordering of the transformers section of your kustomization.yaml. You should add the relative path of the cas-enable-host.yaml file to the transformers block of the kustomization.yaml file before the reference to the sas-bases/overlays/required/transformers.yaml file and any SSSD transformers. For example, the transformers section of your kustomization.yaml might look like:
transformers:
- site-config/cas-enable-host.yaml
- sas-bases/overlays/cas-server/cas-sssd-sidecar.yaml
- site-config/cas-sssd-example.yaml
...
- sas-bases/overlays/required/transformers.yaml
...
As long as the cas-enable-host.yaml appears before your SSSD transformers the security context for the CAS controller template will be set correctly and SSSD will work as expected.
Conclusion
The order in which you specify files in your kustomization.yaml is important. Putting these files in certain orders can cause unexpected results like the failure of SSSD to authenticate users. Looking through the files to understand what they are doing can help you understand the correct order to place them in the kustomization.yaml.
