On Wed, 2009-03-04 at 20:13 +0100, Michael Ströder wrote:
Da Rock wrote:
Sorry to barge in straight away with a question like this, but my time
is running out and I have not been able to get a straight answer out of
google.
I'm going through the hypotheticals for using ldap as the backend for
kerberos, and I've hit a chicken and egg problem with SASL- can someone
untangle my mind?
IF kerberos is using ldap as a backend store for keys, users, etc, and
one can set the rootdn and leave the rootpw for later entry in the
database itself, and the password can use SASL auth- what happens if you
use kerberos as the auth mechanism?
According to the book, slapd needs to set up the access to the key from
startup, and kerberos in this scenario will need ldap up to provide the
key. Is ldap up enough that kerberos can provide this? Or does ldap
retry or something so that this problem is overcome?
Which KDC are you going to use? Why do you want to use Kerberos as authc
mech for the connection between the KDC and the LDAP backend server?
Usually one stashes the password at the KDC which does a simple bind.
There's nothing wrong with that. Also I wouldn't use the rootdn as
bind-DN for the KDC. I'd rather recommend to create service accounts and
define appropriate ACLs.
Another possibility is to use SASL/EXTERNAL for a ldapi:/// connection
(Unix domain socket) and map the Unix user to a service account for the
KDC. In this case the service account does not need a password at all.
But KDC and LDAP server have to run on the same machine for this to work.
I'm not sure you quite understand what I mean here- at least I'm not
sure I get your point (if you care to clarify). Although maybe my
mention of rootdn has confused the matter...?
To be precise Heimdal offers an option to use the ldap as a backend
store for all of its data (keytabs, user profiles, etc). Obviously ACLs
need to reflect this so although ladpi:/// socket is used, one should
use ACLs that allow only the Heimdal to access the database (at least
the keys anyway).
Openldap, in turn, offers the use of Kerberos (Heimdal in this case) to
provide authentication through SASL. In the docs it says slapd needs to
setup the key with kerberos at the start, so services need to be
registered with kerberos through kadmin.
Now, IF Heimdal Kerberos is using ldap as its backend store and the user
info for itself is in the database, and IF ldap is using SASL for auth,
then ldap needs to register with Heimdal as a service to authenticate
Heimdal which is using ldap as its backend service (Typing it out like
this is kinda helping to clear the picture in my own mind... :) ). A
chicken and egg scenario if I ever saw one.
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).