Sometimes I forget whether I’ve added our internal site root and intermediate CA certificates to the Trusted CA Bundle that SAS® Software applications use. Sometimes I also forget the command I can use to find out whether I did! 😉 As is often the case with my blog posts, by jotting things down here, I can find them again either by searching this blog, or more likely, by remembering I wrote it when I see it turn up in Google search results!
If you use site-signed certificates from your own internal CA in your SAS platform installations then you’re probably already familiar with adding them to the Trusted CA Bundle using the SAS Deployment Manager (see the Manage Certificates in the Trusted CA Bundle Using the SAS Deployment Manager section in the Encryption in SAS® 9.4 book for more info).
If you want to find out what CA certificates are already in that bundle you can use the Java keytool command like so:
/opt/sas94m5/sashome/SASPrivateJavaRuntimeEnvironment/9.4/jre/bin/keytool -list -keystore /opt/sas94m5/sashome/SASSecurityCertificateFramework/1.1/cacerts/trustedcerts.jks -storepass changeit
It generates a long list of CA certs, so I pipe it through grep to look for the ones I want:
/opt/sas94m5/sashome/SASPrivateJavaRuntimeEnvironment/9.4/jre/bin/keytool -list -keystore /opt/sas94m5/sashome/SASSecurityCertificateFramework/1.1/cacerts/trustedcerts.jks -storepass changeit | grep -i metacoda
If you want more details on the certificates you can Continue reading “Did I add that CA Certificate to the SAS Trusted CA Bundle?”
This is just a very quick post to jot down the location of a SAS reference that I keep losing! I have the SAS Audit, Performance and Measurement (APM) package installed in my older SAS 9.4 M0 dev/test environment. The APM package is now deprecated as the functionality has moved into SAS Environment Manager (from 2.4). One of the effects of having APM installed is that my SAS Workspace Server logs have a huge number of lines that look like this:
NOTE: MVA_DSIO.OPEN_CLOSE| _DISARM| STOP| _DISARM| 2016-07-31T15:44:27,279+10:00| _DISARM| WorkspaceServer| _DISARM| |
_DISARM| | _DISARM| | _DISARM| 9854976| _DISARM| 12| _DISARM| 12| _DISARM| 320| _DISARM| 1840| _DISARM| | _DISARM| | _DISARM|
| _DISARM| | _DISARM| | _DISARM| | _ENDDISARM
NOTE: PROCEDURE| _DISARM| STOP| _DISARM| 2016-07-31T15:44:27,279+10:00| _DISARM| WorkspaceServer| _DISARM| | _DISARM| |
_DISARM| | _DISARM| 9854976| _DISARM| 12| _DISARM| 12| _DISARM| 728| _DISARM| 1840| _DISARM| | _DISARM| | _DISARM| | _DISARM|
| _DISARM| | _DISARM| | _ENDDISARM
Sometime I want to suppress those lines (without uninstalling SAS APM). I then remember there’s a SAS page that contains instructions on how to do it, and spend several minutes trying to find it. I keep looking for a SAS Usage Note, but instead it’s a gem at the end of the SAS APM FAQ page: “Why do the Enterprise Guide SAS logs contain messages related to MVA_DSIO.OPEN_CLOSE and _DISARM? How can these messages be eliminated from the SAS log for EG users?”.
Essentially you edit the workspace server’s logconfig.apm.xml and change the Threshold of the WSLogAppender to Error.
You’ll want to pay attention to the note in the FAQ that says it will disable the SAS DI Studio Job Statistics features. I don’t use that feature in this environment, but you might!
This is another post in the series about configuring a SAS platform on Linux to use Integrated Windows Authentication (IWA), in this post I’m going to jot down some notes on steps 1-7 – configuring the Linux server for Active Directory (AD) Authentication.
Some time has passed since I wrote the original post, and a few things have changed. I’m now running SAS 9.4 M3, but this post should equally apply to SAS 9.4 M2. I have also switched the Linux distribution from Debian to CentOS 7.1. I am also using a much simpler method of joining the Linux server to the AD domain, using the realmd package (previously there were lots of individual steps using the underlying packages but realmd automates most of this). In this post I’m going to outline the simpler method using realmd of course.
Here goes … Continue reading “Active Directory Authentication for SAS on Linux (with realmd)”
Continuing on the theme of configuring a SAS 9.4 M2 platform on Linux to use Integrated Windows Authentication (IWA), in this post I’m going to jot down some notes on steps 12-15 – configuring the SAS mid-tier on a Linux server for IWA with fallback to form-based authentication (when IWA is not available). This includes delegation, so that IWA users of mid-tier apps like SAS Studio are able to get IWA access to a SAS Workspace Server (and avoid having to store their passwords in metadata or switch to using SAS Token Authentication).
If you’re wondering what happened to steps 1-11, I’ll try get to those earlier steps in future posts. I’m starting at step 12 because someone recently asked me a question about configuring an IWA mid-tier and so it seemed like a good idea to get this blog post done first. Of course, when actual implementing, it’s always good to start at the beginning, building up the foundations, and verifying those first steps are working well before moving on to the next steps. So these steps assume you already have a working implementation where SAS desktop applications (like SAS Management Console & SAS Enterprise Guide) are able to connect to the SAS metadata server using IWA, and also to get IWA access to an appropriately configured SAS Workspace Server.
I have found the best mid-tier related documentation resources for this type of configuration are these ones:
… and there are a few others listed in a previous blog post.
One of the reasons I’m writing this post is to get down some notes on a config that worked for me. The documents referenced above cover a variety of scenarios including plain basic web authentication with an XML file-based UserDatabaseRealm, an LDAP JNDIRealm, IWA (SPNEGO) without fallback, as well as fallback to form-based SAS authentication. Getting the right mix of settings, that didn’t conflict with each other, took me a long time to determine (my mid-tier takes about 20 minutes to restart whenever I want to test a modified config). Along the way I encountered pop-up basic web authentication dialogs when IWA should have worked, and infinite browser-refresh loops for the SAS Logon Manager when IWA was disabled in the browser and I was expecting fallback to SAS authentication. This post is about the final config that worked for me. I know I’ll be referring to this post again, and I hope it proves helpful to others too.
Here goes … Continue reading “Config Notes: SAS Mid-Tier (Linux) IWA with Fallback”
Yesterday I wrote a post about configuring a SAS® 9.4 M2 installation on Linux for Integrated Windows Authentication (IWA) with mid-tier fallback form-based authentication to handle situations where IWA was not available or was disabled. I also repeated this configuration with a SAS Visual Analytics 7.1 installation (based on SAS 9.4 M2). This means that domain users within an organisation, who can participate in IWA, can simply open a browser, navigate to SAS Visual Analytics, and be logged in automatically using their Windows login. Other users without a domain account, on a machine that is not in the domain, or who have deliberately disabled IWA in their browser, will see the familiar SAS Logon Manager login form where they can manually provide a user id and password.
One of the other reasons I built this configuration was to find out what happened with SAS Visual Analytics Guest Access in an IWA fallback configuration like this. Essentially, I wanted to find out if I could get maximum flexibility by supporting IWA users, form-based authentication users, and guest/anonymous access all at the same time.
One of the reasons I wanted to test this was a reference I remembered seeing in the SAS documentation. The Web Authentication section of the SAS 9.4 Intelligence Platform: Security Administration Guide, Second Edition, lists one of the limits of Web Authentication as “Not compatible with anonymous access”. This is also repeated in the PUBLIC Access and Anonymous Access section too.
It makes sense that anonymous access is not compatible with web authentication in a standard non-fallback configuration. If authentication is automatic and it fails then access is denied. An IWA fallback configuration is slightly different though – you have a choice whether to do web authentication or SAS authentication (e.g. IWA or non-IWA). If you choose SAS authentication then perhaps anonymous access might still be available as an option. I decided to test it out.
I ran 4 test scenarios to see how they were handled in an IWA with fallback configuration:
Continue reading “SAS Visual Analytics Guest Access with IWA Fallback”