While you should only permit secure access to the server, many environments might still allow access to unencrypted communication. Unencrypted communication is potentially dangerous for any kind of client because it could be observed and altered by a malicious third party, but it's especially dangerous for administrative accounts. Even if the server is configured to allow some clients to issue insecure requests, you should ensure that administrative accounts always use secure communication.

The best way to require that a user only be permitted to communicate with the server over a secure connection is to include the ds-auth-require-secure-connection operational attribute in that user’s entry with a value of true. Although the password policy configuration includes require-secure-authentication, and require-secure-password changes properties, those properties can only guarantee the safety of authentication credentials. They don't guarantee secure communication for other operations processed by that user. This is because it's possible to authenticate in a manner that the server considers secure, without exposing credentials to an observer, without using a secure connection such as using a SASL mechanism like GSSAPI.

Note:

CRAM-MD5 and DIGEST-MD5 also currently fall into this category, but for this purpose they are no longer considered secure.

Although it's possible to enable this by default for root users and topology administrators, you shouldn't do so at the risk of affecting backward compatibility with existing deployments that expect to be able to use insecure communication for these accounts. If the server is configured to only accept secure connections, or to reject insecure requests, then this setting is not as necessary.