The comment is there as a generic disclaimer and to address a deficiency in FreeRADIUS.
In the majority of cases you don't know what the user's DN is to perform the bind. So first, you need to bind as an anonymous user, or with a set of privileged credentials to perform that search and find the DN.
FreeRADIUS doesn't maintain separate connection pools for different purposes, so the connection must be rebound as the authenticating user.
This means in order to authenticate a user in LDAP you end up performing three operations:
- Bind as a privileged/anonymous user.
- Search for the User's DN.
- Bind as the user.
If the latency is high between the LDAP server and the RADIUS server this can severely limit throughput (in terms of auth/s) as FreeRADIUS in versions <= v3.0.x implements synchronous I/O.
There's absolutely no good reason not to use bind operations to authenticate users, especially where the LDAP server is using a specialised backend authentication plugin to perform the authentication. It doesn't matter what LDAP was designed for. The RADIUS protocol certainly wasn't designed for international roaming confederations and tunnelling TLS in multi-layered authentication schemes, yet it fills those roles reasonably well.
The document you linked is confusing. It seems to be talking about using a service account to bind via Kerberos (GSSAPI) to the LDAP server, and because of deficiencies in 389DS, GSSAPI can't be combined with StartTLS or LDAPS, which means when the user's credentials would be submitted in the clear during that second bind operation.
Or it could be saying that because you can't use GSSAPI with StartTLS or LDAPS with 389DS, then the credentials would be submitted in the clear if you used Kerberos to perform the user binding operation.
In either case, I'm fairly sure this is a limitation in 389DS only, and that the majority of other LDAP servers would support GSSAPI over TLS encrypted LDAP connections.
Whatever the case, you should NEVER submit or retrieve credentials to an LDAP directory without using StartTLS or LDAPS as the article says:
Today the only secure, guaranteed way to protect your accounts is TLS. You should use LDAPS, and this guarantees all communication will be secure. It’s simpler, faster, and better.
If communication with the directory server is in the clear, then an attacker could easily snoop on either the plaintext password being submitted to the directory server, or the NTPassword coming back. The NTPassword is just the 16bit little endian encoding of the password, hashed with MD4, it's pretty much as good as plaintext.