Obviously LDAP is a commonly used protocol and one would assume the PMT server does not store or hold on to the information entered by the user. You are right that Most LDAP authentication processes are just passing username/password combination to LDAP service "as is". The LDAP query will return a true/false result and once the systems knows the user/pass combination is correct. It may do further "ismember" lookups to see if a user has the correct role access requirements (aka group membership).
The TLS encryption applied (LDAPS) is only in transit, so these passwords cannot be intercepted by a third party. It is possible (and likely) that they are capturing your entered string values and then passing username text field string "as is" to LDAP server. This is the only intercept point and unles they are storing these (in log files, or a failed/success logon database table (!!!!).
Any system using authentication (bar multi-factor) could be made to harvest username/passwords in bulk from its users. To me it sounds like the concern from your management is not driven by technology, but rather a lack of faith in the software provider. Was any due diligence done on them? (a requirement of infosec)
If the relationship with the provider is good, you can ask them if they hold/store any of the credentials or do they simply pass this through and expect true/false responses. You may also be able to ask them if they use a standardised library/component to handle authentication in the application.
You can (slightly) mitigate the risk exposure/consequence by making a rule that staff with administrative network access should not use those credentials to authenticate on the PMT server. This can be enforced by the LDAP binding for the user lookups. An LDAP bind "DistinguisedName" (DN) is usually a user controlable setting when setting up LDAP (usually named something like base/root binding or "user binding"). Staff with Administrative level access could be stored outside this branch of your LDAP directory structure and the lookup will fail to find them (return false)... but this control will only go so far.
If you are highly dubious about the software and felt the harvesting of passwords is a real concern, you could create another branch in your LDAP Tree (e.g. an Active directory "Organisational Unit" (OU)) holding PMT user/service accounts. Then create a secondary "zero priviledge" account for each PMT user and store them in that node. Then set your PMT LDAP binding point to be that specific branch of the tree. If they harvest these credentials they would essentially have no access to network resources and you can even deny them logon priviledge to workstations/servers. This however will require staff to maintain two logon/passwords for the network. Also worth noting that this does not stop a user from entering their normal user/password combination (it will happen).
Previous poster correctly indicated using MF authentication/SSO techniques would remove this risk completely - but asking your software provider for that level of change might be a big ask. A quick roll-out will (and should) create new security concerns. As an example OAuth is often misunderstood by developers to be an authentication mecanism and its an Authorisation mechanism. Not saying its not suitable in this setup. But a poorly developed security system based on these technologies is an often seen outcome - if you are concerned about their ability to securely handle LDAP credentials - its unlikely that you will have faith in a correct implimentation of these. (There are other more complex security risks with these - password harvesting, not so much)