Da Rock wrote:
On Wed, 2009-03-04 at 18:20 -0800, Howard Chu wrote:
> 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)?
I'm a rather practical guy. So let us leave theory aside here:
I'd suggest that you set up
slapd -h ldapi:///
and connect to it via ldapsearch -H ldapi:///.
Observe what's written in the syslog by slapd to get the idea what's
After that you want to learn about this:
This maps the Unix account data to an existing directory entry. This
could be e.g. the Unix service account of the KDC mapped to the
accompanying directory entry which gets the appropriate authorization by
First rule of sysadmin: don't leave open a door that
doesn't need to be open- even an internal one.
Be assured. People here like Howard are quite aware of that rule.
> 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
> 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.
Another benefit of having a LDAP backend for the KDC is that it's more
easy to sync user accounts.