Microsoft published the 2020 LDAP channel binding and LDAP signing requirements for Windows article that states:

"LDAP channel binding and LDAP signing provide ways to increase the security for communications between LDAP clients and Active Directory domain controllers. A set of unsafe default configurations for LDAP channel binding and LDAP signing exist on Active Directory domain controllers that let LDAP clients communicate with them without enforcing LDAP channel binding and LDAP signing. This can open Active Directory domain controllers to an elevation of privilege vulnerability.

Microsoft recommends administrators make the hardening changes described in ADV190023."

In summary, after you complete the recommended steps, a simple bind to Active Directory without Transport Layer Security (TLS) fails whether the bind is anonymous or by a user name and password.

Contents:

• What Does This Mean for Your SAS Applications?
• How Do I Know Whether My Applications are Configured to Use LDAPS or startTLS?
  • SAS^®9 SAS Metadata Server
  • SAS^®9 Programs That Use the LDAP CALL Routine Interface, Including Sample Code for Active Directory (importad.sas)
  • SAS Viya
• Quick Loggers
  • SAS Metadata Server
  • SAS Program That Uses CALL LDAPS_OPEN
  • SAS Viya

What Does This Mean for Your SAS Applications?

SAS^®9 and SAS^® Viya^® support using encryption on the connection to your LDAP provider using either secure LDAP (LDAPS) or the Start TLS Operation (startTLS). SAS applications and jobs that are clients to Active Directory fail to connect to your Active Directory server if they are using a non-secure connection. These applications include the following:

• SAS^®9 Metadata Server Direct LDAP Authentication (also referred to as Direct Use of LDAP)
• SAS^®9 programs that use the LDAP CALL Routine Interface
• SAS^®9 Sample Code for Active Directory (importad.sas), and your customized programs that use the User Import Macros to add or synchronize metadata identities to LDAP. This sample program uses the LDAP CALL Routine Interface.
• SAS Viya

How Do I Know Whether My Applications are Configured to Use LDAPS or startTLS?

The default TLS-configured ports for Microsoft Active Directory are 636 and 3269. Using either of these ports in SAS^®9 connection properties, SAS^®9 programs, and SAS Viya is a good indication that LDAPS is in use, though it still depends on how the ports on your Active Directory server are configured. The default ports for non-secured LDAP are 389 and 3268.

The following sections describe:

• the configuration options for integration with Microsoft Active Directory
• the location of these options
• expected errors when an unsecure bind is attempted against a Microsoft Active Directory server with the security update

SAS^®9 SAS Metadata Server

The SAS Metadata Server supports LDAPS in its configuration for the Direct LDAP Authentication mechanism. Evaluate the configuration files on the metadata server to determine whether Direct LDAP Authentication is configured. The best practice is to provide the configuration options in the SAS-configuration-directory/SASMeta/MetadataServer/sasv9_usermods.cfg file. Here is an example: 

To comply with the Microsoft security update, make certain that the following are true:

• AD_PORT is a TLS-configured port on Active Directory.
• AD_TLSMODE is set to 1.

Here is an example message from SAS Management Console showing a failed authentication to a Microsoft Active Directory server that has the security update.

You can further confirm the protocol that is being used by enabling enhanced logging on the SAS Metadata Server, which writes messages to the metadata server log tracing the authentication process. Notice this connection is using a non-secured port (389):

Refer to the following documentation for more information:

• How to Configure Direct LDAP Authentication in SAS^® 9.4 Intelligence Platform: Security Administration Guide.
• How to Configure TLS between the Metadata Server and an LDAP Server in SAS^® 9.4 Intelligence Platform: Security Administration Guide.
• SAS Note 51911, "Troubleshooting SAS^® Metadata Server authentication issues in SAS^® 9.3 and later"
• The Quick Loggers section at the bottom of this note.

SAS^®9 Programs That Use the LDAP CALL Routine Interface, Including Sample Code for Active Directory (importad.sas)

The LDAP CALL Routine Interface in SAS^®9 supports LDAPS. The call routines allow a SAS program to make a connection to an LDAP server and to perform various actions on LDAP directory entries. Here are typical program uses of the LDAP CALL Routine Interface, which are all indicated by their use of the CALL LDAPS_OPEN routine:

• the Sample Code for Active Directory, importad.sas, which is used to add identities to metadata from an Active Directory source
• programs that query Active Directory to find person information, such as an email address, to distribute reports or other information
• any SAS program that uses the CALL LDAPS_OPEN routine

To comply with the Microsoft security update, make certain that all instances of the CALL LDAPS_OPEN routine in the SAS program specify a TLS-configured port and either of the following:

• The CALL LDAPS_OPEN routine specifies the session option: TLS_MODE_ON.
• The environment variable LDAP_TLSMODE has a value of 1.

Here is an example of the CALL LDAPS_OPEN routine:

Here is an example of setting the LDAP_TLSMODE environment variable on the SAS invocation command:

Here is an example message in the SAS Log showing a failed connection to a Microsoft Active Directory server that has the security update:

Additionally, if you enable TRACE or DEBUG level logging for the App.tk.LDAP logger for the SAS session, the program log also contains an error similar to the following:

Refer to the following documentation links for more information:

• CALL LDAPS_OPEN Routine in SAS^® 9.4 Integration Technologies: Directory Services Reference
• About the Sample Code for Active Directory in SAS^® 9.4 Intelligence Platform: Security Administration Guide, Third Edition
• The Logging Facility for SAS Programs in SAS^® 9.4 Logging: Configuration and Programming Reference, Second Edition
• The Quick Loggers section at the bottom of this note

SAS Viya

The identities and SASLogon services in SAS Viya 3.3 and earlier support LDAPS. In SAS Viya 3.4 and later, identities and SASLogon services support LDAPS and startTLS. The services use LDAP to determine which users can access SAS Viya web applications. The connection from the identities and SASLogon services to LDAP is determined by the properties under the sas.identities.providers.ldap.connection configuration instance for each service. Here is an example:

To comply with the Microsoft security update, make certain that either of the following are true:

• The port is a TLS-configured port and the URL specifies the ldaps protocol.
• The port is unsecured, the startTLS is simple, and the URL specifies the ldap protocol.

When the connection to Microsoft Active Directory is not secure, the identities service fails to connect to Active Directory. The Users page in SAS Environment Manager reports "No users were found" and "No groups were found" when you select the Users and Groups views, respectively.

Additionally, the identities service log contains the message:

Note: The identities service log is located in /opt/sas/viya/config/var/log/identities/default/.

In a full or visual-only deployment, the default authentication mechanism is LDAP. In this scenario, and when the the connection to Active Directory is not secure, the SASLogon service fails to connect to Active Directory. End users see the following message in their browser:

Additionally, the SASLogon log contains the following message:

Note: The SASLogon service log is located in /opt/sas/viya/config/var/log/saslogon/default/.

Refer to the following documentation links for more information:

• Encrypt LDAP Connections in Encryption in SAS^® Viya^® 3.5: Data in Motion.
• SAS KB0036450, "Troubleshooting identities and the identities service in SAS^® Viya^®"
• SAS Viya The Importance of LDAP Encryption
• The Quick Loggers section at the bottom of this note

Quick Loggers

Use this section to quickly enable enhanced logging. Logging can be important to capture bind failures to an LDAP directory server, including Microsoft Active Directory. Note that it is important to return loggers to their previous levels after you have collected the needed data. Otherwise, log files will grow rapidly in size, potentially consuming all available disk space.

SAS Metadata Server

1. Edit the following code by providing valid values for the HOST=, PORT=, USER=, and PASS= options in order to connect to the SAS Metadata Server:
   
   proc iomoperate;
       connect host='host-name'
            port=port-number
       user='user-ID'
       pass='password';
   
       list attributes category="Loggers" name="Audit.Authentication";
       list attributes category="Loggers" name="App.tk.LDAP";
            list attributes category="Loggers" name="App.tk.eam.ssl";
   
       set attribute category="Loggers" name="Audit.Authentication" value="Debug";
       set attribute category="Loggers" name="App.tk.LDAP" value="Debug";
       set attribute category="Loggers" name="App.tk.eam.ssl" value="Trace";
   quit;
    

2. Submit the step from within a Base SAS^® session. It is generally best to use a SAS session that is launched from the SAS Metadata Server, but it is not mandatory as long as the SAS session can connect to the SAS Metadata Server.
   
   Note: The LIST statement within the IOMOPERATE procedure generates a listing of logger levels before changing their value. This is a useful reference when returning logging levels to their previous level.
   
    
3. Return logger levels to their previous value by editing the above code. Change the value Trace to be the value that was written to the SAS log before setting the new value. Note that the value might be NULL. Submit the step.
   
   Note: Restarting the SAS Metadata Server reverts logging to the original levels. These levels are determined by the log configuration file.

SAS Program That Uses CALL LDAPS_OPEN

1. Insert the following lines at the top of your program. Edit the FILENAME to specify a valid path and name for the log file.

2. Submit your program in batch or in a standard SAS session. Because of conflicts with default logging for compute servers in an Intelligence Platform deployment, these statements do not enable logging in IOM compute server sessions.

In addition to the standard job log, you will have a separate file containing the trace data for the LDAP bind. The name and location of this second file is specified in the FILENAME statement in the example.

SAS Viya

For SAS Viya 3.4 and later, use the following commands to set loggers for the identities and SASLogon services. Each of these commands should be run as a single line from a shell prompt on the machine running the SAS^® Configuration Server, and should be run as the sas user (or a user with sudo privileges).

1. Determine whether loggers are already set, and if so, at which level:
   source /opt/sas/viya/config/consul.conf
   export CONSUL_HTTP_TOKEN=$(sudo cat /opt/sas/viya/config/etc/SASSecurityCertificateFramework/tokens/consul/default/client.token)
   /opt/sas/viya/home/bin/sas-bootstrap-config kv read --recurse config/identities/logging.level
   /opt/sas/viya/home/bin/sas-bootstrap-config kv read --recurse config/SASLogon/logging.level
    

   Note: These two read commands return logging levels for the identities and SASLogon services. This is a useful reference when returning logging levels to their previous level. If nothing is returned by the read command, then no logging level is explicitly set.
    

2. Set loggers for enhanced logging:
   /opt/sas/viya/home/bin/sas-bootstrap-config kv write --force config/identities/logging.level/com.sas.identities.provider.ldap "TRACE"
   /opt/sas/viya/home/bin/sas-bootstrap-config kv write --force config/identities/logging.level/org.springframework.security.ldap "TRACE"
   /opt/sas/viya/home/bin/sas-bootstrap-config kv write --force config/SASLogon/logging.level/org.springframework.ldap "DEBUG"
3. Return loggers to their previous value. If no data was returned by the read command in step 1, then you should delete the logger keys you created by the write command. Here is an example that shows how to delete each key that was created:
   /opt/sas/viya/home/bin/sas-bootstrap-config kv delete config/identities/logging.level/com.sas.identities.provider.ldap
   /opt/sas/viya/home/bin/sas-bootstrap-config kv delete config/identities/logging.level/org.springframework.security.ldap
   /opt/sas/viya/home/bin/sas-bootstrap-config kv delete config/SASLogon/logging.level/org.springframework.ldap

Operating System and Release Information