Re: Openldap, kerberos backend, and SASL

[Da Rock <rock_on_the_web@comcen.com.au>]

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
> > 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.
> 

Thats the answer I'm looking for, then.

> > 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.
> 
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
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.
> 

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... :)

Cheers