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 happening there.
After that you want to learn about this:
authz-regexp "gidnumber=([0-9]+)\+uidnumber=([0-9]+),cn=peercred,cn=external,cn=auth" "ldap:///ou=schulung,dc=stroeder,dc=local??sub?(&(objectClass=posixAccount)(uidNumber=$2)(gidNumber=$1))"
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 ACLs.
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 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.
Another benefit of having a LDAP backend for the KDC is that it's more easy to sync user accounts.
Ciao, Michael.