As xyzzy123 said, this is the app doing LDAP wrong. To provide a more complete answer to your question: there's really nothing special about a password field a

As xyzzy123 said, this is the app doing LDAP wrong. To provide a more complete answer to your question: there's really nothing special about a password field as far as an LDAP server is concerned. It's just a field like any other; it can have rules applied to it, as well as processes, to alter what data is ultimately stored but it depends on people implementing the rules. There are standards, etc., but it's rare anyone follows them properly. Having worked with it extensively at one point in my career my impression is that few people really understand how LDAP works at its core. People associate it with authentication because that's mostly what they use it for but it can effectively work as a data store for anything you want to keep a directory of. Another common use is device registrations and ownership (in AD this is Machine accounts). It's a very flexible system that could be used to replace any kind of structured data store if you want it to. This all leads back to the fact that while you can apply some rules to the structure of the LDAP and to individual fields, it's not as though the LDAP knows or cares that an attribute called "password" should have special treatment when it comes to querying if you don't tell it that. Ultimately the software should be performing a bind (authentication) to the LDAP as the user, rather than trying to look the user up using queries while bound as a superuser or some other high-privilege user.