I am working on transitioning our project management tool (PMT) to use LDAP authentication instead of native auth that's currently in use.

We also have some internal web-based tools that interface with the PMT, using a REST-based interface exposed by the PMT. Some of our internal stakeholders have a concern in regards to security of the LDAP authentication entered into these internal tools, because these tools are outsourced and developed by external companies.

The way I imagine this would work is this (all communication will be over TLS/SSL):

  1. User "X" enters their LDAP credentials into one of our internal tools.
  2. Internal tool passes these credentials on to the PMT, which then authenticates them against the LDAP server.
  3. Once successfully authenticated, the internal tool is able to exchange information with the PMT.

My management team has a security concern that when a user enters their LDAP credentials into an internal tool, the tool could abuse/misuse these credentials or log them into a file inadvertently, thus exposing someone's credentials.

Is there a way to prevent this scenario? Clearly, encrypting the credentials wouldn't help because the internal tool will need them to pass on the LDAP server for authentication. So how does one make sure that the internal tool does not see the credentials but still be able to authenticate the internal tool against the LDAP server?

  • 2
    Is this not a perfect candidate for Kerberos tickets? – Polynomial Mar 25 '19 at 20:59

So how does one make sure that the internal tool does NOT see the credentials but still be able to authenticate the internal tool against the LDAP server?

Many protocols exist to provide authentication without sharing user credentials with the application that's granting access. Several companies (Okta, Duo, One Login) provide tools to help implement using these where they are the application that sees user credentials and other applications get the identity information via whichever protocol is suitable for them.

It's definitely best to have users redirected via OAuth2, SAML, etc. than to provide their password directly to any application that may be used.


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)


If the attacker has access to your passwords before they are encrypted there is no way to be 100% safe, but if some unwanted software is storing your information, it would have to send it out if the attacker is not physically where the machine is. You can set your firewall to stop unwanted programs from sending info onto the network or internet.

Also, try to use some sort of physical security device, such as the RSA SecurID series of products.

You also need to have antivirus/security software to detect threats.

  • 1
    The threat model is not about an external, remote attacker, but internal disclosure. – schroeder Mar 25 '19 at 22:30
  • Thats why these methods are for internal threats. – user197001 Mar 25 '19 at 22:30
  • Unwanted software, "sending out", firewalls, anti-virus, these are all outside the threat model described. – schroeder Mar 25 '19 at 22:36
  • 1
    Nothing in your explanation deals with preventing a legitimate program from logging the credential. You are only dealing with a narrow range of vulnerabilities after the credentials are logged and accessed by unauthorised and malicious threat actors. I'm trying to tell you that you are tackling the wrong problem. – schroeder Mar 25 '19 at 22:49
  • 1
    user197001 must be really bold to say that @schroeder don't know how a firewall works... – ThoriumBR Mar 26 '19 at 1:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.