"Justin Ryan" justizin@vongogo.org writes:
Using LDAP as the data store for your KDC reduces its' security.
I respect that the OpenLDAP community works hard that OpenLDAP is a secure solution for centralized authentication on its' own, but respectfully, it would scare me if the OpenLDAP community was not aware that LDAP was not intended to be an authentication store. LDAP's job is Authorization.
This is a really bad argument against using OpenLDAP as a KDC data store. LDAP has a very rich security and authorization model and has been used to store secure data, such as password hashes, for many years. The server is most certainly designed to support this. In fact, LDAP directories often store data that from a regulatory perspective is even more sensitive than passwords (such as social security numbers or HIPAA/FERPA data).
You can very legitimately argue that putting the KDC data store in an LDAP server increases the overall complexity of your Kerberos KDC. It does do that; it introduces many thousands of lines of additional code into your environment, and LDAP replication is a lot more complex (and hence more could go wrong) than simple full kprop replication, and probably more complex even than hprop incremental replication. In return for that additional complexity, you get a lot of additional features (including richer fine-grained access control and other security features), which may or may not be of interest to you. You have to make that tradeoff based on the needs of your site, and if none of the features of an LDAP backend are useful to you, it's always better to default to minimizing complexity.
But this is not because OpenLDAP is somehow insecure. It's only a general point about complexity in security systems, and a general principle that, all other things being equal, running fewer lines of code is better. The OpenLDAP code, line for line, is probably just as secure as your existing KDC code. (And I only don't say something stronger because I have a great deal of respect for the security design of Heimdal.)