Microsoft, ONTAP, and the LDAP Channel Binding Apocalypse

Howdy Folks!  I'm sure that everyone has heard and is panicking about the patch that Microsoft announced around LDAP communication and channel binding.  For those of you that are living under a rock with an early 2000's flip phone, here's the link: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

Well, let me be your guide around what this means when it comes to ONTAP.  Buckle up, and here we go.
                              

FIRST OFF:  LDAP CHANNEL BINDING TOKENS
The MS update (when it comes out.  as of this writing, it is now pushed to 2H CY2020) will require channel binding tokens(CBT) only if the client supports it.  That is the default registry setting of 1 that the patch will set.  So, when you install the patch and do nothing else, there will be no effect on ONTAP since ONTAP does not support CBT.   At some point, Microsoft may change the default setting to 2, or your AD team or security team may require a setting of 2, but until ONTAP supports CBTs, a setting of 2 is not compatible with ONTAP.   The default setting of 1 or a setting of 0 (never required) is compatible with ONTAP.
NOTE:  ONTAP above includes all releases of Cluster Mode and 7-Mode ONTAP and Data ONTAP.

NEXT:  THE REAL PROBLEM.....   LDAP SIGNING REQUIRED
The MS update will change the behavior of the settings for LDAP signing required.  This means that if you have never touched the setting, it will now behave as if LDAP signing is required in your environment.  Here's a little cheat matrix to help you.



If you explicitly set the LDAP Signing Requirement to "OFF" in your environment, you will have no impact after the patch.  Nothing will change.  The patch will not modify the setting.  Remember though, this will need to have been EXPLICITLY SET TO OFF either in a GPO or registry setting on the DCs.

If you are currently using "Signing required" in your environment (setting of 2), then you have already done everything in your environment necessary to support it.  The patch will not modify, enhance or change that setting.  You will have no impact after the patch.  Remember, you will have had to set this EXPLICITLY in a GPO or registry setting on the DCs.

For everything else, you need to do some changes.

I have an SVM with a CIFS server
If you are already using StartTLS, LDAPS, or signing/sealing for the CIFS security, you do not have to do anything.  Any of those settings will meet the requirements of the patch.  Here's an example SVM with none of the 3 set properly:

If you are like the above and have none of the possible settings set, the easiest setting to modify is the signing & sealing (client session security) option. This is because StartTLS and LDAPS both require certificates and if you don't have a certificate infrastructure in your environment, well...  its complicated.  In order to set signing use the following command:
 vserver cifs security modify -vserver svm0 -session-security-for-ad-ldap sign
Replace "svm0" with your vserver name.  That's it for the CIFS server.

This will only work for ONTAP 9 and higher.  For Data ONTAP 7-mode, the connection automatically upgrades to sign when it encounters an AD where signing is required.  There is nothing additional needed to do for 7-mode.  For ONTAP cluster-mode versions older than 9, you'll need to set up StartTLS.  There's plenty of documentation and resources on how to set up StartTLS for the CIFS server.  I'm not going to go into it here.

I have and SVM with a UNIX LDAP client
Here's where it gets a little complicated due to the amount of permutations of the LDAP config there are.  Now, what I can say is that the same rules apply for UNIX LDAP connections as the CIFS server security settings.  If you are already using StartTLS, LDAPS or signing/sealing for the configuration, then you are in the clear and you are meeting the requirements of the patch.  Here's a screenshot of a client config with none of the 3 set properly"

NOTE:   As of ONTAP 9.5, if you use "636"  for the LDAP Server Port, LDAPS will be used automatically

Now, I am not going to go through all the iterations of possible configurations and what their outcomes are, but I will point you to the best practice and what is the easiest; use the AD-Domain setting, use the bind-as-cifs-server setting, and use the signing & sealing (Client Session Security) option.  Using the AD-Domain setting will automatically discover AD DCs and attach to the closest one using sites and services.  Using the bind-as-cifs-server setting will guarantee a sasl bind and enable the ability to sign or seal.  Then using at least signing for that configuration will use signing for the LDAP connection similar to the CIFS server operation I explained above and satisfy the requirement.

Want to read the official NetApp KB article?  Click on this:  https://kb.netapp.com/app/answers/answer_view/a_id/1103575

**Whew**  Now that we've muddled though alot of the muck on this, I hope you followed me through the configurations and now you know what you need to do to stay operational once the patch hits and gets applied to your DCs.  Apocalypse.....  carry on!