SAS Viya supports using encryption on the connection to your LDAP provider. Using either LDAPS or startTLS, remember startTLS support was introduced with SAS Viya 3.4. SAS has always recommended that this communication is secured to prevent network snooping of domain credentials. However, in March 2020 Microsoft will push a security update that disables non-TLS simple LDAP binds. In this article we’ll look at this security update and remind you of the prerequisites and configuration steps you’ll need to make your environment work correctly.
Microsoft has published the following information: 2020 LDAP channel binding and LDAP signing requirement for Windows. In this they state:
LDAP channel binding and LDAP signing provide ways to increase the security of network communications between an Active Directory Domain Services (AD DS) or an Active Directory Lightweight Directory Services (AD LDS) and its clients. There is a vulerability in the default configuration for Lightweight Directory Access Protocol (LDAP) channel binding and LDAP signing and may expose Active directory domain controllers to elevation of privilege vulnerabilities. Microsoft Security Advisory ADV190023 address the issue by recommending the administrators enable LDAP channel binding and LDAP signing on Active Directory Domain Controllers. This hardening must be done manually until the release of the security update that will enable these settings by default.
Microsoft intends to release a security update on Windows Update to enable LDAP channel binding and LDAP signing hardening changes and anticipate this update will be available in March 2020.
Microsoft Support provides details on manually enabling LDAP signing as well as details on enforcing LDAP channel binding. Both can be enabled through the Windows registry and do not require a restart of either Active Directory Domain Services (AD DS), or Active Directory Lightweight Directory Services (AD LDS), or the host. The March 2020 update from Microsoft was originally going to automatically apply these settings on any server running either AD DS or AD LDS. However, a recent statement from Microsoft indicates that the March 2020 update will not make any changes, but they still recommend that administrators Audit and Fix to be ready for the new update scheduled for mid/late 2020.
Once enabled a simple bind to Active Directory without TLS will fail, whether that is a username & password or anonymous bind. Additional logging can be configured to provide details of the systems and users attempting such connections. Microsoft documents the logging configuration required. The Logger "16 LDAP Interface Events" should be set to "2 (Basic)" to capture attempts to use a simple bind without TLS.
This means that your SAS Viya environment must use TLS on the connection to Active Directory, either through LDAPS or startTLS. Otherwise the default logon to SAS Viya, leveraging LDAP, will fail. You will see messages like the following in the SAS Logon Manager log file:
2020-02-14 05:30:54.550 ERROR 1053 --- [-auto-1-exec-10] w.a.UsernamePasswordAuthenticationFilter : service [79814c8579ad583d] An internal error occurred whi
le trying to authenticate the user.
org.springframework.security.authentication.InternalAuthenticationServiceException: [LDAP: error code 8 - 00002028: LdapErr: DSID-0C090256, comment: The serv
er requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v3839^@]; nested exception is javax.naming.Authe
nticationNotSupportedException: [LDAP: error code 8 - 00002028: LdapErr: DSID-0C090256, comment: The server requires binds to turn on integrity checking if S
SL\TLS are not already active on the connection, data 0, v3839^@]
Also, the connection from the Identities microservice to Active Directory will also fail. If LDAP channel binding and LDAP signing is enabled, you will see message like the following in the Identities microservice logs for the failure:
2020-02-14 05:30:46.911 WARN 23773 --- [1-auto-1-exec-6] c.s.i.p.l.LdapIdentityQueryRepository : sas.logon [ea18881e7a89a0d0] [IDENTITY_FETCH_LDAP_ERROR] Error occurred while fetching identity: Failed to borrow DirContext from pool.;
nested exception is
org.springframework.ldap.AuthenticationNotSupportedException: [LDAP: error code 8 - 00002028: LdapErr: DSID-0C090256, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v3839];
nested exception is javax.naming.AuthenticationNotSupportedException: [LDAP: error code 8 - 00002028: LdapErr: DSID-0C090256, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v3839]
The Encryption in SAS Viya 3.5: Data in Motion Guide covers this configuration steps required to enable the use of LDAPS or startTLS. Here we will again call out the prerequisites and configuration you need to complete.
Prerequisites
To be able to use either LDAPS or startTLS your Active Directory domain controllers must have a private key and signed TLS certificate. Microsoft has documented the process to configure this. The Active Directory domain controller will require a restart as part of the process of enabling TLS.
The TLS certificate used by the AD DS or AD LDS server(s) must be trusted by the SAS Viya environment. If the certificate is purchased from a third-party Certificate Authority, it will most likely already be included in the Mozilla bundle of trusted CA certificates used by SAS Viya. Otherwise the CA certificate will need to be added to the SAS Viya truststores. Always follow the documented procedure to manage the truststores.
You can use OpenSSL to confirm that the certificate presented by your AD DS or AD LDS server(s) is trusted. For example, to validate LDAPS on port 636 use the following command:
echo x |openssl s_client -connect gellabdc1.gellab.net:636 -CAfile /opt/sas/viya/config/etc/SASSecurityCertificateFramework/cacerts/trustedcerts.pem
You should see the following at the end of the output:
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 7B4A0000298E529BA34CB1E6DA8B5D47101FFD2FA8AC5AD56F2C1E0D81E8C4D4
Session-ID-ctx:
Master-Key: 1B496041DB64C57AE420C14BC6E23E947CF9DF8276D9B169EE0CE578337E4AFD08C792A6CF032BFCD944A6A595836381
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1581698567
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
DONE
Which shows the protocol used (TLSv1.2), the cipher suite negotiated, and that the certificate is trusted since the return code is 0.
While to validate startTLS use the following:
echo x |openssl s_client -connect gellabdc1.gellab.net:389 -starttls ldap -CAfile /opt/sas/viya/config/etc/SASSecurityCertificateFramework/cacerts/trustedcerts.pem
Again, you should see the following at the end of the output where the return code shows that the certificate presented by the server is trusted by the OpenSSL client:
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 49490000006BEFE5E0F2A5EC9F2029D11FD67FDB245210B32F545C6D7DFA39E2
Session-ID-ctx:
Master-Key: 1197FD3A3019815E85A65B4E30790C56074D8FBAFAF9DF265F1774C9983C878F453B59E22B0B19776464186BFDA792A0
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1581698751
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
DONE
This means that the certificate is trusted, and you can move onto configuring your SAS Viya environment.
Configuration
As documented the configuration is straight forward. To configure LDAPS you must change the port and url. To configure startTLS you change the property from "none" to "simple." Both changes can be made in SAS Environment Manager, remember you can always log in with the sasboot account if your LDAP accounts are locked out. Both LDAPS or startTLS are configured by updating the sas.identities.providers.ldap.connection settings. It is recommended that both SAS Logon Manager and the Identities microservice are restarted after making changes.
Conclusion
SAS has always recommended that you should secure the connection to your LDAP provider by using TLS. Either by connecting with LDAPS or using startTLS. The security update from Microsoft makes this a required change for Active Directory Domain Services (AD DS) or Active Directory Lightweight Directory Services (AD LDS). The configuration changes for SAS Viya are relatively minor, the most important part is to ensure the certificate that is presented is correctly trusted by SAS Viya. If your AD DS or AD LDS does not yet provide LDAPS or startTLS then enabling TLS can be a disruptive change since a restart is required.
