Active Directory – platformadmin.com

SAS Viya 4 (2021.1.2) with LDAPS to Windows 2012 R2

I recently installed a local copy of SAS Viya 4 (2021.1.2) in our Kubernetes lab environment and was trying to configure it to work with a test AD server, Windows 2012 R2. The AD server had been configured to only allow TLS (LDAPS) connections and so after the initial installation of SAS Viya I configured the SAS Identities service to use LDAPS, as explained in the SAS documentation.

Unfortunately it didn’t work at first. I was getting errors that turned out to be a TLS cipher mismatch between the client (SAS Identities service) and the server (Windows 2012 R2 AD). I was able to fix it using two methods:

Re-enabling LDAP connections to AD and switching back from LDAPS to LDAP connections for the SAS Identities service (not preferred)
Tweaking the configuration of the SAS Identities service to support a cipher that worked with Windows 2012 R2 AD (preferred)

Of course I could have also upgraded AD from Windows 2012 R2 to a more recent version, but that is a project for another day as I still want to continue working with the older version for the time being.

For future reference, and in case it helps anybody else, here are my notes Continue reading “SAS Viya 4 (2021.1.2) with LDAPS to Windows 2012 R2”

Metacoda Identity Sync and Microsoft Security Advisory ADV190023

Those of you who use Metacoda Identity Sync may have already heard about Microsoft Security Advisory ADV190023. You may have heard about it from Stuart Rogers’ post on SAS Communities: SAS Viya The Importance of LDAP Encryption. Stuart’s article is about SAS Viya, but the Microsoft changes may have an impact on those sites that do LDAP-based identity synchronization with their SAS 9 platforms too. This includes Metacoda customers that use Metacoda Identity Sync. Naturally, this is something we have been getting some questions about recently – “How will it impact on the identity sync process?”

I think a good place to start would be to read the linked articles above, then discuss with your domain admins. They will be able to tell you if they plan on making the recommended changes and, if so, when they plan to make them. This might require you to change the way you configure your LDAP connection.

There has been some confusion about what changes Microsoft will make and when. It also looks like the extent and timing of those changes has evolved over time too. Quoting some of the sections of the advisory, as of today: Continue reading “Metacoda Identity Sync and Microsoft Security Advisory ADV190023”

Reviewing SSL/TLS Certificate Chain for Active Directory Server

Sometimes when I am setting up, or helping someone setup, identity synchronisation between the SAS® platform and Microsoft Active Directory (AD), I run into SSL/TLS certificate validation issues. I am usually using Metacoda Identity Sync, but it can also happen when doing a sync with custom Base SAS code. Often the underlying cause is that the AD server’s CA certificate is not in the SAS Private JRE Trusted CA Bundle (see Did I add that CA Certificate to the SAS Trusted CA Bundle?). When troubleshooting this, one of the first things I will do is look at the certificate that the AD server is providing, and I mostly use an OpenSSL s_client command for this. There are 4 command variations I use depending on whether I am trying to use the main directory or the global catalog, and with LDAP plus STARTTLS, or just LDAPS.

For connecting to the main directory on the unencrypted LDAP port 389 with an upgrade to encrypted using STARTTLS:

echo "Q" | openssl s_client -connect dc.example.com:389 -starttls ldap -showcerts

For connecting to the main directory on the encrypted LDAPS port 636:

echo "Q" | openssl s_client -connect dc.example.com:636 -showcerts

For connecting to the global catalog on the unencrypted port 3268 with an upgrade to encrypted using STARTTLS:

echo "Q" | openssl s_client -connect gc.example.com:3268 -starttls ldap -showcerts

For connecting to the global catalog on the encrypted port 3269:

echo "Q" | openssl s_client -connect gc.example.com:3269 -showcerts

If you want to examine the returned certificate in more detail then you can also pipe it to an OpenSSL x509 command e.g.

echo "Q" | openssl s_client -connect dc.example.com:389 -starttls ldap -showcerts | openssl x509 -noout -text

If you have questions, or any other tips for troubleshooting SSL/TLS certificates with AD, then please leave a comment below.

Auto Creation of Linux Home Directories for SAS Users

In a previous post I’ve described a method for configuring Active Directory Authentication for SAS® on Linux (with realmd). One of the packages that’s installed is oddjob-mkhomedir. This package normally handles any requirement for auto-creating home directories for those AD users on Linux. Unfortunately it doesn’t seem to get used by the SAS Object Spawner. I ran into this issue again today when logging into SAS Studio 4.2 as an AD user on the SAS Viya™ 3.2 platform. I wasn’t able to login because the AD user’s Linux home directory didn’t exist and hadn’t been auto created. After manually creating the home directory the login succeeded. I would rather get auto-creation working so I wouldn’t need to manually create home directories for each SAS user that was likely to use SAS Studio. Thankfully I was able to find a solution that I’ll describe in this post. Continue reading “Auto Creation of Linux Home Directories for SAS Users”

Identity Sync: Finding Your Keys

Using the Metacoda Identity Sync Plug-in with a new SAS installation is easy. All of the defaults are based on common practices for synchronizing Active Directory users and groups with a SAS metadata server. Using the plug-in with an existing installation, where users and groups have already been synchronized using custom code, takes a little more planning. One of the ‘key’ things to do is to configure the plug-in to use the same external identity key id attribute that was used in the custom code. If you have the custom code, you can find the prior key choice in that code. This post is about helping you find and recognize those external identity keys without necessarily having to study the code.

An external identity key is a unique identifier for a user or group in an external identity source (e.g. Active Directory). It connects users within SAS metadata to the equivalent external user, so changes to the external user (including name changes) can be applied to the SAS user at some later date/time. In choosing a key from the external source, it is best to choose one that will stay constant over time, even after user name changes, directory reorganisation etc. There are a few different key choices available, and some are more likely to remain constant over time than others. Later in this post I will show examples of some common external identity key id attributes. The key that is chosen for groups doesn’t have to be the same as the one chosen for users either. I often see sAMAccountName being used for users and distinguishedName being used for groups. At Metacoda we recommend using objectGUID for both users and groups (as explained below). Once a Key Id Attribute has been chosen it is important to continue to use the same one over time. Switching the key choice after it has already been used for a synchronization is not an easy thing to do, so it is good to carefully consider the initial choice before deciding to synchronize users and groups. Of course, sometimes you inherit the process and have no choice in the matter.

When switching from one synchronization process to another, such as custom code to the Metacoda Identity Sync plug-in, it is important to continue to use the same key choice as before. If the key choices are different you might see something like this in the Identity Sync Plug-in, where every user or group looks like it will be (tag) deleted and re-added, and there are associated validation errors that prevent the sync from proceeding.

In the screenshot above, Continue reading “Identity Sync: Finding Your Keys”