When OpenLDAP (or any other LDAP Directory) is used to log in, that often means that the IP addresses are available on the Open Internet. Which is as it needs to be.
BUT remember that having the addresses open gives attackers/hackers an opportunity to discover the open port(s) and to mount an attack. It is easy enough.
All too many sites follow the examples. Setting up a suffix with (using 'facebook.com' as an unlikely example) something like "cn=Manager,dc=facebook,dc=com" (what you'd expect from the OpenLDAP Project's docs) sets you up for an easy attack. Junior High School Science.
Everything about that suffix is COMMON. "dc=facebook,dc=com" is the most obvious suffix possible. Yes, the LDAP community believed in the Global Directory. Yes that (kind of) depended on that particular pattern of suffix creation.
Oh, the good old days before ransomeware and serious black, gray, and white hackers.
There is no reason to make the suffix OBVIOUS. "o=facebook" or "o=facebook.com" are less likely for the suffix. Symas does the "dc=symas,dc=com" thing just like everyone else. I took a lot of criticism when was drafting a book and chose "o=symas" for the example suffix.
It's shorter and less repetitive typing. It's a (relatively) uncommon approach to suffixes. It's semantically correct ... it just doesn't tie neatly back to DNS. As if tying back to DNS in a non-Global-Directory world mattered. Fortunately for all the book went nowhere. But when designing a new directory, try to avoid the "dc=" pattern if the directory is going to be visible on the open internet.
Likewise, consider alternatives to "cn=manager" for the 'rootdn'. Same reason. This is an opportunity for self-expression and creativity. And another opportunity to make it hard for outsiders to "crack" the credentials of the directory.
Finally, NEVER, EVER, EVER store the 'rootpw' (root directory user's password) in the configuration metadata. EVER, EVER! 'ldappasswd' is HAPPY to provide a nice secure hash so nobody can stumble on this OH SO CRITICAL bit of security data.
PLEASE!