On Wed, 2009-03-04 at 18:20 -0800, Howard Chu wrote:
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
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.
Thats the answer I'm looking for, then.
> You have awoken an alternative in my mind, though. I'll just
> 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
>> 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
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.
What about pretending to be a user with access to the socket (like ldap
or the kdc users)? First rule of sysadmin: don't leave open a door that
doesn't need to be open- even an internal one. But if you're talking
about only superuser access on the socket then you're doing this
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.
I'm not sure exactly what I'm doing yet, but I am researching the
possibilities. One possibility is user management, another is
replication for other kdc's, not sure about any of these yet.
Thank you all for your input and experience here- this is exactly the
info I needed to resolve the dilemma I was binding myself into... :)