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:

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 is addressing this vulnerability by providing recommendations for administrators to harden the configurations for LDAP channel binding and LDAP signing on Active Directory domain controller …
…
Important The March 10, 2020 and updates in the foreseeable future will not make changes to LDAP signing or LDAP channel binding policies or their registry equivalent on new or existing domain controllers.

In short, Microsoft are providing some features so that domain admins can find clients that are using LDAP connections in an unsafe way, and giving them options to enforce safer LDAP connections: i.e. to require LDAP Signing and LDAP Channel Binding.

At this stage it looks like there will not be an automatic switch from non-enforcment to enforcment. However, your domain admins may proactively follow this advisory and implement changes that could potentially disrupt your identity sync process, so this blog post is about what you can do to fit in with those changes and recognizing any errors you may encounter. Ideally you make any required changes before the domains admins turn on enforcment.

What this means for SAS platform admins using Metacoda Identity Sync is that, if you are using an unencrypted LDAP connection, you should move to using one of the connection types that uses encryption: e.g. LDAP+STARTTLS on port 389 or LDAPS on port 636. You really should do this anyway, even if it is not being enforced at your site. Encryption will ensure protection of the LDAP bind credentials as they pass over the network. Of the two encrypted options, we recommend LDAPS for reasons explained later in this post.

So how do you know what type of LDAP connection you are currently using?

The connection type is usually configured initially with the Identity Sync Profile Wizard Active Directory Connection page:

Metacoda Identity Sync Profile Wizard Connection Page

… where you can choose from LDAP (not encrypted), LDAP with STARTTLS (encrypted), and LDAPS (encrypted). The first option is the easiest to use (but also least secure) as the other two usually require the AD server’s CA certificate to be added to the SAS Private JRE Trusted CA Bundle – see my earlier post Reviewing SSL/TLS Certificate Chain for Active Directory Server.

You can review the configured connection by opening and editing the Identity Sync Profile (IDSP) using the Metacoda Identity Sync plug-in, or alternatively open and review the IDSP file’s XML in a text editor.

LDAP (not encrypted)

For an LDAP (not encrypted) connection, you will see something like this in the IDSP XML:

...
<LDAPConfig
    protocol="ldap"
    host="example.com"
    port="389"
    useStartTLS="false"
    authMethod="simple"
    bindUser="metacodaidsyncsvc"
    bindPassword="{sas002}..."
...

… the key items here are protocol=ldap, port=389 and useStartTLS=false. i.e. LDAP on port 389 with no STARTTLS so credentials will be passed in clear text over an unencrypted connection. This is the type of unsafe use that the Microsoft Security Advisory recommendations will help domain admins to find and reject.

With this type of connection, when LDAP Signing is enforced (with HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\ldapserverintegrity = 2 on the domain controller) you should see an error similar to this:

ERROR: 03Mar2020:15:38:40.863 (2,702,834ms) Thread-79 [com.metacoda.smc.idsync.IdSyncView] Source Identity Upload has failed
com.metacoda.smc.n.k: Failed to upload Active Directory identity data to the SAS Workspace Server instance: Failed to query AD for domains: [LDAP: error code 8 - 00002028: LdapErr: DSID-0C090257, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v2580]
...
Caused by: javax.naming.AuthenticationNotSupportedException: [LDAP: error code 8 - 00002028: LdapErr: DSID-0C090257, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v2580]; remaining name 'CN=Partitions,CN=Configuration,DC=corp,DC=example,DC=com'
...

… to indicate that simple authentication over a non-encrypted connection has been rejected. This can be resolved by using one of the other LDAP connection types below.

LDAP with STARTTLS (encrypted)

For an LDAP with STARTTLS (encrypted) connection, you will see something like this in the IDSP XML:

...
<LDAPConfig
    protocol="ldap"
    host="example.com"
    port="389"
    useStartTLS="true"
    authMethod="simple"
    bindUser="metacodaidsyncsvc"
    bindPassword="{sas002}..."
...

… the key items here are protocol=ldap, port=389 and useStartTLS=true. i.e. LDAP on port 389 with STARTTLS so credentials will be passed over a connection (initially unencrypted) that has been upgraded to encrypted using the STARTTLS extension. This is a safer usage that should generally work after implementing the Microsoft Security Advisory recommendations with simple domains. However, it is not a good LDAP connection type to use for more complex multi-domain environments where LDAP referrals are involved. This is because the automatic following of LDAP referrals done by the JRE will use a new unencrypted LDAP connection without the STARTTLS extension. If that other AD server also enforces LDAP Signing then you will get a similar error to that seen above from the other AD server when processing that referral like so:

...
WARNING: 03Mar2020:15:51:14.613 (3,456,584ms) Thread-98 [com.metacoda.smc.idsync.ActiveDirectorySourceHandler] Failed to get object with DN 'CN=Vegas Enterprises: Finance / EU (Global),CN=Users,DC=corp2,DC=example,DC=com'.
javax.naming.AuthenticationNotSupportedException: [LDAP: error code 8 - 00002028: LdapErr: DSID-0C090257, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v2580]
...
ERROR: 03Mar2020:15:51:14.613 (3,456,584ms) Thread-98 [com.metacoda.smc.idsync.ActiveDirectorySourceHandler] A required AD identity was not found (with DN 'CN=Vegas Enterprises: Finance / EU (Global),CN=Users,DC=corp2,DC=example,DC=com').
...

… notice that this error occurs later in the identity sync process when attempting to follow a referral to a nested identity in a different domain (in corp2.example.com vs corp.example.com).

Alternatively, if the other AD server is not configured to enforce LDAP Signing then you will not get an error but the LDAP connection for the referral will be unencrypted. You could argue that is a worse, and silent, failure. It is for these reasons that we instead recommend the LDAPS connection type described below and avoid using STARTTLS.

LDAPS (encrypted)

For an LDAPS (encrypted) connection, you will see something like this in the IDSP XML:

...
<LDAPConfig
    protocol="ldaps"
    host="example.com"
    port="636"
    useStartTLS="false"
    authMethod="simple"
    bindUser="metacodaidsyncsvc"
    bindPassword="{sas002}..."
...

… the key items here are protocol=ldaps, and port=636 (the useStartTLS attribute is ignored with LDAPS). i.e. LDAPS on port 636 so credentials will be passed over an always encrypted connection. This is a safe usage that should work after implementing the Microsoft Security Advisory recommendations. This is the connection type that we recommend, although it may require some initial work to add the correct CA certificate to the SAS Private JRE Trusted CA Bundle.

Summary

So, in summary, if you are not already doing so, it is best to use an LDAPS (encrypted) connection with Metacoda Identity Sync so that if, and when, your domain admins implement the recommendations of the Microsoft Advisory, and block the use of simple authentication over unencrypted connections, your identity sync process keeps running as normal.

I hope you’ve found this post useful. Please leave a comment and let me know if you have any questions or feedback based on your experiences. If you’d like to find out more about the Metacoda Identity Sync Plug-in you can contact me or visit the Metacoda web site (where you can also request a free evaluation).