Re: Openldap, kerberos backend, and SASL

Da Rock wrote: > On Wed, 2009-03-04 at 17:27 -0800, Howard Chu wrote: >> You're missing the obvious fact that GSSAPI/Kerberos is not the only secure >> SASL mechanism available in this picture, and it is obviously not the one the >> KDC uses to talk to LDAP. > I'm aware that SASL GSSAPI is not the only SASL auth on offer, but I'm > not sure of the latter part of your statement: do you mean that the ldap > used as a backend cannot use the kdc using the ldap as the backend for > authentication? The slapd can use SASL/Kerberos to authenticate everyone *except* requests from the KDC itself, because that would cause the chicken'n'egg loop that you already alluded to. The Heimdal code always uses SASL/EXTERNAL to talk to ldap, for this very reason.

> You have awoken an alternative in my mind, though. I'll just go and > stick my head back in my Openldap doc under SASL for a bit- I'll > probably come back with another stupid question shortly... :) > >>> A couple of points of interest come to mind: >>> >>> 1. Security of the ldapi socket needs to be paramount. Permission should >>> be as tight as can be allowed so that only access is as necessary for >>> use. On top of this, ACLs should only allow heimdal itself to access at >>> least the keys (users and passwords could be changed by other means (?) >>> such as secure web or script as the keys are what allows a user to do >>> what they want and are what could be stolen or targeted at any rate). >> No, security of the ldapi socket is irrelevant since the identity of the >> client connecting to the socket is what's actually used for the LDAP server's >> authentication/authorization purposes. > Surely at least some form of protection from say bruteforce or other > form of attack should be implemented here? Stands to reason that only > users or services that need something should be allowed access to it. > Why leave a hole in the wall when a door could be used to keep out the > nasties? There is no hole in this wall. An LDAP server is designed to securely process requests from multiple disparate clients. If your KDC and its host machine are secure, and the ACLs in your slapd are correct, then the issue is closed. You cannot bruteforce SASL/EXTERNAL over ldapi://. You can only fool it if you already have superuser access on the host system, and in that case, you were lost already anyway.

You can of course choose to dedicate one LDAP server to back your KDC, but if you're going to isolate it from any other usage in this manner, then you're no longer getting any special benefit from using LDAP.