Re: Openldap, kerberos backend, and SASL

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

On Wed, 2009-03-04 at 17:27 -0800, Howard Chu wrote:
> Da Rock wrote:
> > 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.
> 
> 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?

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?

> > 2. rootdn should not be allocated a password in the config (no matter
> > what form is used (slapd.conf or slapd.d/cn=config). Since rootdn can
> > change anything in the database on a whim, access to the details of this
> > should be left out of anything that an intruder could gain access to
> > (even though IF root on the host is compromised all hope could well be
> > lost anyway- keep as secure as possible)
> 
> That's generally true.
> 
> > 3. Obviously SASL should be used as authentication (thats why its being
> > setup isn't it?).
> 
> Yes. But SASL != Kerberos.
> 

Sorry, I should have said SASL GSSAPI there. But given my above
statement I'm starting rethink my stratagem... :)

At this point would like to thank for this experienced input as you have
all been a very good sounding board in comparison to rambling to myself
and twisting my mind around this many variables and scenarios ;)