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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/