February 27, 2020 – Advisory: LDAP Active Directory Connections |

InterSystems Official

Pete Greskoff · Feb 27, 2020

#Alerts #Caché #Ensemble #HealthShare #InterSystems IRIS #InterSystems IRIS for Health #InterSystems Official

Starting in March 2020, Microsoft plans to release a series of security updates that will cause Windows Active Directory (AD) servers to reject unencrypted simple binds. For more details on the changes to Active Directory, see Microsoft’s Security Advisory ADV190023.

Instances of all InterSystems products using LDAP with Windows AD servers for user login can be impacted if they are not already properly configured to use TLS/SSL. The impact is not limited to instances running on Windows versions. The potential impact exists whether instances perform LDAP authentication directly or via the Delegated Authentication mechanism.

Based on InterSystems testing using updated AD servers with the default security policies, it is recommended that you configure all LDAP AD connections to use TLS/SSL prior to applying the relevant Microsoft patches to your AD servers. See the note at the end of this advisory for guidance on configuration.

Additionally, prior to updating any AD servers, you must install Microsoft patch CVE-2017-8563 on all Windows servers that connect to these AD servers. Otherwise, the AD servers will reject connections from the Windows servers, even if they use TLS/SSL.

If you have any questions regarding this advisory, please contact the Worldwide Response Center.

Note on configuration:

If you are using LDAP configurations, select the Use TLS/SSL encryption for LDAP sessions checkbox, as described in the “Using LDAP” chapter of the Security Administration Guide.
If you are using the %SYS.LDAP class, call the StartTLSs() method, as described in the Class Reference Documentation. The Init() and SetOption() methods are also relevant.

Both LDAP configurations and the %SYS.LDAP class must have all certificate(s) necessary to validate the AD server’s certificate used in the TLS handshake, including the Certificate Authority root certificate and any intermediate certificates. Contact your Windows Active Directory administrator to obtain a copy of the required certificate(s). Install these as appropriate:

For Windows clients, in the Windows local computer certificate store
For non-Windows clients, in a file accessible by the instance in PEM format. If exporting the certificate from Windows using the Certificate Export Wizard, this format will be called "Base-64 encoded X.509".

For more information on certificate locations, see the “Using LDAP” chapter of the Security Administration Guide

Craig Regester · Mar 4, 2020

In our research with the security team and Windows server team, the advisory indicates that there are additional options provided to require the TLS/SSL bind but it is not automatically turned on for existing servers. The InterSystems advisory above (and what was sent out via email) makes it sound like this will cause immediate failure on all existing configurations, but that doesn't appear to be the case after review. Is this correct?

We are based on AIX 7.2 so the other challenge is that we use a round-robin DNS hostname to access the AD LDAP servers (ldap.ourdomain.example) but the certs for the servers the round-robin passes off to are 3 different servers. InterSystems only provides a single field for a PEM cert. Will it accept a concatenated PEM cert containing the info for all three servers? We have had to use this approach previously for Java keystores authenticating through LDAP.

0 0

Jon Sue-Ho · Mar 27, 2020

Howdy!

1. InterSystems has tested the new settings related to these Microsoft changes (signing and channel binding) and seen that simple binds to Active Directory servers from InterSystems instances will fail if not using TLS. Enforcement of these settings is up to Microsoft and subject to change by them, so knowing how and when such changes might be made without manual intervention would be a question best addressed to Microsoft.

2. Regarding your particular set up, a CA file should be able to contain multiple CA certificates. I’ve tested putting the right CA certificate for the server I was connecting to after a different CA certificate in the file and found that the connection still worked, so it appears capable of going through more than one.

What might be a concern is that hostname checking is done by the LDAP connection, so the subject name for the certificate the server presents needs to match the hostname the client is configured to connect to. If your three different AD machines have three different certificates (which would be the case if they were signed by three different CAs), then you might want to check that the subject names for the certificates all match the actual configured hostname in the LDAP configuration on the instance. I’m fairly certain that a match for the subject alternative name extension for the certificate (instead of the subject name field itself) would suffice, but I have not tested it.

If you’d like to explore this in more depth, we encourage you to open a WRC case.