2 things you should REALLY do just after your Viya deployment (LDAPS, HTTPS)
In our "Viya workshop" classes, we always stress out the fact that seeing all the "failed=0" values in the Viya installation ansible playbook output is not enough and is not the last step of your deployment work. There still a fair amount of work to make your environment available for the end-users, for example:
- Change the default password for RabbitMQ
- Assign a password to sasboot
- Connect as sasboot
- Configure LDAP information
- Define more admins
- Secure LDAP communications (LDAPS)
- Prevent further creation of the password reset URL
- Restrict access to port 80 (only let access to port 443)
- Swap out the TLS certificate for the customer's
In this article, let's "zoom in" on two of the post deployment activities that will make the customer's IT security administrator happier: Secure LDAP communications (LDAPS) and Swap out the TLS certificate for the customer's.
Note: the examples and documented configuration steps here are for Viya 3.2. However the principles remain the same with the latest Viya version (3.3).
Secure the LDAP communications
Why?
With the default LDAP authentication model, if you are using standard LDAP protocol, then, each time a user will logon in a Viya Visual interface, then:
- The LDAP binding account credentials will be sent in clear-text on the network from the Viya machine (where SAS Logon Manager application sits) to the LDAP server
- The user password will be sent in clear-text on the network from the Viya machine (where SAS Logon Manager Application sits) to the LDAP server
Scary, right?
Moreover here, we are not talking about some "sasdemo" account but about your real domain account...yes the password which usually allows you to log in your Windows session every morning... Sometimes additional hardening is "nice to have", but this time, LDAP secure is really a "must have", otherwise your Viya environment will become a large security hole.
We will see how to configure Viya with LDAPS protocol to encrypt the communications when the SAS Logon Manager binds to the LDAP server.
Once again, ansible will be our friend to implement that easily in a distributed environment.
What do I need?
All that you need is the certificate for use with SSL and TLS that is configured in LDAP and the LDAP secure port information. For example in our test collection, the LDAP server has been configured for LDAPS and the associated certificate is stored as a PEM format file in "etc/pki/tls/certs/gelldap.pem" (At a customer site, the customer would be responsible for providing you with the right files.)
As an example we can with a simple “ldapsearch” query, check that the LDAP server can talk on the secure protocol and port:
How do I do it?
Now what we need to do is to configure SAS Viya to Connect to LDAPS Provider. As explained in the official documentation it is a 3 steps process:
- Add the certificate to the trustedcerts files (.pem and .jks)
- Update the Identities configuration in EV (LDAP port and protocol)
- Restart Identities and SASLogon Microservices
Note: the first step is not required if the LDAPS provider’s CA certificate is already included in the Mozilla bundle of trusted CA certificates is using (https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport)
Here is an example on how it was done in one of our test collection:
1) Backup the "SASSecurityCertificateFramework" folder, on all machines:
ansible all -i $HOME/sas_viya_playbook/hosts -m shell -a "cp -R /opt/sas/viya/config/etc/SASSecurityCertificateFramework/cacerts /opt/sas/viya/config/etc/SASSecurityCertificateFramework/cacerts.backup" -b
2) Make the LDAP server certificate available on the Viya machines
3) Add the root certificate to the trustedcerts.pem file (on all machines), just include the root certificate at the end of the trustedcerts.pem file:
4) Add the root certificate to the trustedcerts.jks file (on all machines), import the file using the "keytool" command Trusted store:
5) Open SAS Environment Manager and update the Identities configuration
6) Restart identities & SAS Logon services:
and
That’s it!
If you still can still log into SAS Environment Manager with your LDAP account, then it means it is working! If not, investigate what's wrong and if needed use the sasboot account to fix or restore the LDAP configuration.
Notes:
- We used ansible commands in the above example to be faster and more efficient, but of course you can do that with shell and scp commands on each machine.
- To completely secure the LDAP communications (to ensure that programming interfaces such as SAS Studio or the REST API are not sending credentials in clear text), the customer should also ensure that, on the SAS programming interface and CAS Controller machines, PAM is configured with LDAPS.
Swap out the self-signed TLS certificate for the customer's
Why?
By default, just after your deployment, the Apache HTTP Server (note that is it not called "SAS Web Server" anymore...), has been already configured to serve as a reverse proxy to connect to the Viya Web Application.
In addition, as explained in the official documentation the SAS Viya 3.2 installation provides self-signed certificates and configures TLS options in the HTTP server configuration (with the "mod_ssl" security module enabled by default).
It means that, right after the Viya deployment, you can already access your Viya applications using an "https" URL (which encrypt the communications between your browser and the HTTP server).
However, this configuration which rely on a "self-signed certificate" is not recommended for production environment and your browser will also warn you that the communication is insecure, as the provided certificate is not in the list of trusted certificates of the computer.
So we will see how to swap the default self-signed certificate with the customer’s one, that will be trusted in the client computer system.
What do I need?
A customer site-signed or third-party-signed certificate and a key.
- The certificate file needs to be a Base-64 PEM encoded file with the extension ".crt" or ".cer".
- The key file needs to be a Base-64 PEM encoded file with the extension ".key".
In the example we will pretend to be a Certification Authority and create a site-signed certificate and pretend that is a real customer certificate.
Anyway the steps to replace the default self-signed SAS certificate with a real customer certificate in the Apache HTTP Server used for Viya 3.2 will remain the same.
Note: The site-signed certificate that we will use here was created with openssh commands in a test collection. But in the real life, when working in the field, it is something that your customer will have to provide to you.
How do I do it?
Once you have your certificate and key files in the PEM format, it is very simple and well documented in the official documentation. Let’s see an example:
1) Upload the customer provided certificate and key files on the Apache HTTP server
2) Place the certificate and the key files respectively in /etc/pki/tls/certs and /etc/pki/tls/private
3) Set the appropriate permissions, both files must be only readable by root for example:
4) Create a backup copy of /etc/httpd/conf.d/ssl.conf, then update the certificate and key file directives to point to your new certificates and key.
5) Restart Apache HTTP server and test with your browser
Now open your browser and type: https://<webserverhostname>/SASHome/
Assuming your CA certificate is listed in the browser trust store, you should be able to see this screen (with the nice little green lock):
Last considerations
An Unexpected Journey (like in the movie)
Ok now you are happy because you are using TLS/SSL with the customer certificate and you don’t see the ugly warning message in your browser. But...your HTTP server access still unsecure.
If the user forgets the little "s" and open http://webserverhostname instead of https://... then the communications will go through the standard HTTP port (80) and appear in clear text on the network.
To avoid that, you should recommend the customer to close the port 80 from the outside, so your server can only be accessed with the HTTP secure port (443 by default) from the outside.
However be careful: with the default configuration if you do not have a trailing slash on the URL then the web server does an automatic redirect to add a trailing slash and the HTTPS is changed to HTTP!
For example if you type in your browser URL "https://webserverhostname/SASHome" without the trailing slash, then Apache will redirect you to the unsecure "http://webserverhostname/SASHome/" (which, obviously will fail if you have blocked the 80 port).
Note: to avoid such unexpected redirection, an URL rewrite rule can be configured in the Apache HTTP server configuration and, once again it is documented in the public administration guide.
Converting certificates
The SSL/TLS certificate format needed for the SAS Security Certificate Framework is a human-readable format called "PEM" (Privacy Enhanced Mail). However the customer might provide you a certificate in a different format or in a Keystore file.
If the certificate is only available in a java keystore, then you can use the Java "keytool" command and OpenSSL's openssl command can be used to convert one to the other.
For example, to extract the certificate out of a Java keystore into a DER (Distinguished Encoding Rules) format file:
Now the file can be converted from DER to PEM using the openssl command:
Never, ever use a web site online tool when you are converting formats, exporting certificate or private keys from other certificate formats, otherwise you are running the risk to expose and compromise a private key associated to a certificate that the customer has provided.
Conclusion and credits
If you followed the instructions, you environment should now look like the very simple drawing below with secure, encrypted communications between the Web browser and the Web Server (HTTPS) and also between the SAS Logon application and the LDAP server (LDAPS).
I'd like to thank Stuart Rogers for his help and guidance in the documentation and in the testing of this setup in my test collection and also Thomas Wittemer, from SAS France (who attended our Viya workshop a few weeks ago and suggested the idea to share the step by step instructions to ease those post-installation tasks). Thanks for reading!
SAS INNOVATE 2024
Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.
If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website.
