How to configure PASOE or the OpenEdge Authentication Gateway to use AD authentication after the Microsoft March 2020 update.

Progress Software is sending this alert to warn OpenEdge customers who use Active Directory for authentication.  Microsoft has published a March 2020 security notice named LDAP Channel Binding and LDAP Signing Requirements.   

The Microsoft update advisory targets its customers who use Active Directory in their enterprise that a security vulnerability exists with LDAPv3 clients who use Anonymous or Simple LDAP bind connections.   Sometime later in the year 2020 new distributions of the Microsoft Active Directory product will have the default value for LDAP Signing and Channel Signing configurations set to TRUE.   It further advises customers with existing installations of Active Directory to set those configuration values to the more secure settings.

Microsoft is responding to identified Common Vulnerability and Exposure CVE-2017-8563 which is a CWE Enumeration for CWE-281 and having a Base Score of 8.1.  Their important decision to remediate this problem has the following implications for OpenEdge customers using AD authentication.
 
OpenEdge configurations that connect to Active Directory using the LDAP URL scheme ‘ldap’ will begin failing with rejected connection attempts after the enterprise enables their AD server’s secure configuration.

You will need to reconfigure your application’s AD/LDAP URL configuration property to use the scheme ‘ldaps’ and configure the Active Directory server’s ROOT certificate to verify the [TLS] LDAPS bind connection.

OpenEdge accesses Active Directory authentication via the Java distribution’s JNDI service plug-in.   While some Java vendor’s JNDI support includes the SASL authentication method that can arbitrate the LDAP bind connection’s signing, it is not currently available via the OpenEdge configuration.  Without the ability to create a bind connection to the enterprise’s Active Directory server, your application will be unable to login users and access your business application.  

Not all enterprises configure their Active Directory servers to accept LDAPS (LDAP over TLS) requests.  If your enterprise does not enable the recommended Microsoft LDAP server signing feature your application may not be able to operate.  Should this situation arise, you will have to work with the enterprise’s Active Directory administrators to enable LDAP bind connections.  If this step cannot be achieved or if the certificates to perform LDAPv3 connections over TLS to Active Directory cannot be obtained from an ITOPs administrator, remediation may not be possible.

If you can acquire the certificates, you will also need to ensure that your PASOE or Authentication Gateway servers have access to the Root CA (and any intermediate CA) certificates required by the Active Directory configuration.

Ultimately, the correct ROOT/intermediate public key certificate must be found in the Java distribution’s default truststore.  The Java distribution’s default truststore may, or may not, distribute public CA ROOT certificates, and may vary per platform.  You may find that the AD server’s certificate can be validated with the distributed ROOT certificates and sometimes you may have to add them yourself.  

Because the ROOT certificates used to validate the AD server’s certificate are obtained from the Java default truststore, caution must be taken to ensure that exposing additional CA ROOT certificates at the JVM level does not impact other Java products.  You should refer to the Java distribution’s documentation to determine the proper way to add any missing ROOT/intermediate public key certificates so they are not lost during an OS or Java distribution update.  

You have the option of controlling which truststore is used by AD server’s LDAPS configuration in the event that changing the Java distribution’s default is not allowed.  This private truststore is possible by adding the ‘javax.net.ssl.trustStore’ property to PASOE or Authentication Gateway instance’s “conf/jvm.properties” file and specifying a fully qualified file system path to where your private Java truststore can be found.  More information on using custom Java truststores can be found in the Java distribution’s JSSE documentation.       

Customers should avoid creating a private Java truststore in the OpenEdge installation’s DLC/servers/pasoe directory space in order to expose the required AD server ROOT certificates to the OpenEdge implementation. Customers might consider exposing certificates at the PASOE instance level but should be aware of the administrative overhead that instance-level management of certificates might incur. 

Once you have an Active Directory configuration that has its AD connection URL reconfigured to use LDAPS-it makes sense to first use a java TLS client tool such as sslj to test your TLS connectivity to the AD server.  This will ensure that the Java distribution’s JSSE TLS support is operable prior to attempting further troubleshooting within the OpenEdge stack.

Once you are ready to attempt TLS connectivity to Active Directory from within the OpenEdge stack, any number of configurable items could complicate success from selecting the proper IP address and port for TLS connections for Active Directory, to TLS versioning, cipher suite selection incompatibilities, or the proper exchange of credentials.   Use the Java JSSE TLS debugging support to discover the cause of the AD server connection problem.

Steps to Reproduce:

Configuration properties associated with an LDAP connection to an AD server look something like the following:

Current PASOE Authentication:
Current LDAP connection configuration properties are:
Current Authentication Gateway Authentication:
Once your PASOE or Authentication Gateway configuration has changed the TLS LDAP connection to an AD server, you will need to test it for correct user authentication.  If binding to the AD server using a TLS connection by a Java Client Tool was successful, but fails in your PASOE or Authentication Gateway product fails you have a configuration problem in your OpenEdge product

Remediation requires configuring your OpenEdge product to have the correct enterprise-distributed Root certificates and to use the proper LDAP bind URL:  ldaps://xx.yy:636

The full range of remediation specifics will need to be discovered as you go.

What follows are general considerations for configuring PASOE or the Authentication Gateway to utilize the LDAPS scheme (LDAP over SSL/TLS).
  
Step 1 - Configuring CA ROOT certificates:  

Your Java distribution must already contain the CA & any optional intermediate CA certificates necessary to validate and complete a TLS connection to the AD server.   When those required certificates are not already available, you will have to obtain them and add them to the OpenEdge server product’s Java truststore using the Java ‘keytool’ utility.

You may be required to contact the enterprise’s AD admin to discover what certificates are required and how to obtain them.   Those CA and intermediate CA certificates may be in the PEM or DER file encoding, which may require adjusting the Java ‘keytool’ import operation’s command line options to specify the correct file type.

%DLC%\jdk\bin\keytool -importcert -file xxxxxx.cer -keystore cacerts -storetype JKS -trustcacerts -storepass password

%DLC%\jdk\bin\keytool -list -v -keystore cacerts -storetype JKS -storepass password

Many examples are available online to help you.

Step 2 – Select a protocol and cipher suite:

Optionally you may need to use a specific protocol and/or a cipher suite from your Java vendor that is compatible with the Active Directory configuration.  Refer to your Java vendor’s documentation for JSSE (TLS) for detailed information.

The following Microsoft article explains the new requirements for 2020 LDAP channel binding and the LDAP signing requirement for Windows:
https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows

Additional References:
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-2020/ba-p/921536