We have to setup a central auth for PCI compliance and I'm wondering if it's ok to allow anonymous bind or should I create a user to do the bind for the services needing ldap?
I'm not sure if it's a requirement, but two questions that arise: "is the data contained confidential?" and "Considering the rest you have seen how rigorous PCI Compliance is, what do you think personally?"– Lucas KauffmanJan 2, 2014 at 15:30
really we are using it for things like network devices login and internal webapp.. it's not storing login info for anything with card holder data databases.– MikeJan 2, 2014 at 15:48
anonymous write or anonymous read? Regardless this info is already considered valuable for an attacker so I certainly wouldn't allow anonymous read. Regardless if it's a PCI DSS requirement or not.– Lucas KauffmanJan 2, 2014 at 16:35
anonymous bind != anonymous read– gowenfawrJan 2, 2014 at 17:00
Allowing anonymous bind might permit an unauthorized host to perform authentication attempts if it has access to the LDAP port. This really only opens a brute-force attack vector, which should be mitigated by the account lockout requirements of PCI DSS 8.5.13 and 8.5.14. In addition, you can presumably document the network segmentation to show that only relatively trusted networks have the access required to take advantage of LDAP. You should be able to demonstrate that your PCI DSS 10.2.5 controls are sufficient to detect attempted misuse of the LDAP authentication channel. You must, of course, use LDAPS (LDAP-over-SSL, 636/tcp) instead of LDAP (unencrypted LDAP, 389/tcp) to be compliant with PCI DSS 8.4.
With those four mitigations in mind, you can probably make a good case for anonymous bind. Frankly, the alternative is having to store and protect bind credentials on all your endpoints, which in my opinion is more of a problem than anonymous bind.
As with all things, your QSA may disagree, and that's who you have to convince. Documenting controls and reasoning behind your decision should help.