LDAPS is dead! Long live LDAPS!

So, as a TME for NFS, Name Services and SMB, I always get the question...

Does ONTAP support LDAPs??

StartTLS is insecure compared to LDAPS, right?

Well, let me tell you something........

LDAPS is sooo 90's.  There!  I said it!  90's?  really?   Yep!   RFC1777 was published in 1995!  And guess what?  There was no standard written for LDAP over SSL!  This was just assumed and taken from HTTPS at the time. The LDAP vendors took it, and rolled with it.

Enter LDAPv3.

RFC2251 was started and completed in 1997.  That didn't have any additional verbiage for on-the-wire encryption, but when RFC2830 was written in 2000, it made an extension for LDAPv3 specifically for StartTLS.  RFC4511 combined them into one LDAP v3 standard in 2006.  Once LDAP v3 was ratified and made it into mainstream in the early 2000's, LDAP vendors started to deprecate the LDAPS encryption method for StartTLS.

Deprecate.   That's a big word.   But what that means is that to "be usable but regarded as obsolete and best avoided, typically due to having been superseded."  Don't believe me?   Check it out:
https://www.openldap.org/faq/data/cache/605.html
https://directory.apache.org/api/user-guide/5.1-ldaps.html
https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol#Protocol_overview
I can go on....  Just do a Google search for LDAPS deprecated and see.

Clustered Data ONTAP started without any LDAPS support in favor of StartTLS because of the above reasons.  All LDAP vendors had to support the StartTLS extension because it was part of the standard.  Also, because LDAPS was deprecated, it could be yanked at any time.

But....  StartTLS is not as secure as LDAPS!!  It runs over a plaintext port!

Well, if you leave your LDAP install wide open, sure.  Your LDAP is still insecure.  But there are countermeasures that you can deploy to make sure StartTLS is secure.

1.  Make sure that StartTLS is enabled.  DUH.
   This requires certificates.   Certificates are hard, but learn them.  They make things secure.  For internal, self-signed certs are OK as long as the domains and permutations of them are accounted for.
2. Prevent queries without StartTLS.
   Now that StartTLS is enabled, you can set up LDAP servers to prevent LDAP commands unless the connection is StartTLS upgraded.  This can be done on a DIT (directory information tree) basis. 
3. Prevent LDAP binds without StartTLS
   There is also a way to prevent BINDs from happening in plaintext.  Consult your LDAP vendor's documentation on how to do this.
4. Prevent LDAP clients to send plaintext creds
   You still want to prevent your clients from sending their credentials in plaintext.  This means setting the minimum bind level at SASL.  The credentials passed will also be encrypted.

Doing all this will ensure that the LDAP communication is always secure.

How do you configure LDAP to work with StartTLS in ONTAP?  Easy.  Install the root certificate for the LDAP server's enterprise and then change the LDAP client config for -use-start-tls true and you are set to go.
Here's how your traffic looks: 

I don't see any holes in there.  Application data means its encrypted and is all buttoned up!  

What about ONTAP and LDAPS?   Well...  low and behold......   9.5 introduced the ability to do LDAPS.   Even though its deprecated and there are alternatives, the ability to do LDAPS was granted.
How do we do it?
Change the port in the ldap config to port 636.  Make sure -use-start-tls is turned to false and the same enterprise root cert is installed into ONTAP.  Is this more secure? Less secure?  Who knows.  Not my debate.
Here's what your traffic looks like:

You decide.  They look almost identical to me except for the LDAP START_TLS packets at the beginning.